kernel/linux.git/drivers/leds/trigger/ledtrig-netdev.c, branch v7.0-rc7

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

Revert "leds: trigger: netdev: Configure LED blink interval for HW offload"

2025-07-18T13:26:32+00:00

This reverts commit c629c972b310af41e9e072febb6dae9a299edde6. While .led_blink_set() would previously put an LED into an unconditional permanently blinking state, the offending commit now uses same operation to (also?) set the blink timing of the netdev trigger when offloading. This breaks many if not all of the existing PHY drivers which offer offloading LED operations, as those drivers would just put the LED into blinking state after .led_blink_set() has been called. Unfortunately the change even made it into stable kernels for unknown reasons, so it should be reverted there as well. Fixes: c629c972b310a ("leds: trigger: netdev: Configure LED blink interval for HW offload") Link: https://lore.kernel.org/linux-leds/c6134e26-2e45-4121-aa15-58aaef327201@lunn.ch/T/#m9d6fe81bbcb273e59f12bbedbd633edd32118387 Suggested-by: Andrew Lunn Cc: stable@vger.kernel.org Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/6dcc77ee1c9676891d6250d8994850f521426a0f.1752334655.git.daniel@makrotopia.org Signed-off-by: Lee Jones

leds: trigger: netdev: Configure LED blink interval for HW offload

2025-02-10T16:56:53+00:00

In case a PHY LED implements .blink_set callback to set LED blink interval, call it even if .hw_control is already set, as that LED blink interval likely controls the blink rate of that HW offloaded LED. For PHY LEDs, that can be their activity blinking interval. The software blinking is not affected by this change. With this change, the LED interval setting looks something like this: $ echo netdev > /sys/class/leds/led:green:lan/trigger $ echo 1 > /sys/class/leds/led:green:lan/brightness $ echo 250 > /sys/class/leds/led:green:lan/interval Signed-off-by: Marek Vasut Link: https://lore.kernel.org/r/20250120113740.91807-1-marex@denx.de Signed-off-by: Lee Jones

leds: trigger: netdev: Check offload ability on interface up

2024-12-17T13:10:48+00:00

The trigger_data->hw_control indicates whether the LED is controlled by HW offload, i.e. the PHY. The trigger_data->hw_control = can_hw_control() is currently called only from netdev_led_attr_store(), i.e. when writing any sysfs attribute of the netdev trigger instance associated with a PHY LED. The can_hw_control() calls validate_net_dev() which internally calls led_cdev->hw_control_get_device(), which is phy_led_hw_control_get_device() for PHY LEDs. The phy_led_hw_control_get_device() returns NULL if the PHY is not attached. At least in case of DWMAC (STM32MP, iMX8M, ...), the PHY device is attached only when the interface is brought up and is detached again when the interface is brought down. In case e.g. udev rules configure the netdev LED trigger sysfs attributes before the interface is brought up, then when the interface is brought up, the LEDs are not blinking. This is because trigger_data->hw_control = can_hw_control() was called when udev wrote the sysfs attribute files, before the interface was up, so can_hw_control() resp. validate_net_dev() returned false, and the trigger_data->hw_control = can_hw_control() was never called again to update the trigger_data->hw_control content and let the offload take over the LED blinking. Call data->hw_control = can_hw_control() from netdev_trig_notify() to update the offload capability of the LED when the UP notification arrives. This makes the LEDs blink after the interface is brought up. On STM32MP13xx with RTL8211F, it is enough to have the following udev rule in place, boot the machine with cable plugged in, and the LEDs won't work without this patch once the interface is brought up, even if they should: " ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:green:wan", ATTR{trigger}="netdev", ATTR{link_10}="1", ATTR{link_100}="1", ATTR{link_1000}="1", ATTR{device_name}="end0" ACTION=="add", SUBSYSTEM=="leds", KERNEL=="stmmac-0:01:yellow:wan", ATTR{trigger}="netdev", ATTR{rx}="1", ATTR{tx}="1", ATTR{device_name}="end0" " Signed-off-by: Marek Vasut Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20241216104826.6946-1-marex@denx.de Signed-off-by: Lee Jones

leds: trigger: netdev: Add support for tx_err and rx_err notification with LEDs

2024-08-01T12:40:01+00:00

This patch provides support for enabling blinking of LEDs when RX or TX errors are detected. Approach taken in this patch is similar to one for TX or RX data transmission indication (i.e. TRIGGER_NETDEV_TX/RX attribute). One can inspect transmission errors with: ip -s link show eth0 Example LED configuration: cd /sys/devices/platform/amba_pl@0/a001a000.leds/leds/ echo netdev > mode:blue/trigger && \ echo eth0 > mode:blue/device_name && \ echo 1 > mode:blue/tx_err Signed-off-by: Lukasz Majewski Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20240710100651.4059887-1-lukma@denx.de Signed-off-by: Lee Jones

leds: trigger: netdev: Remove not needed call to led_set_brightness in deactivate

2024-04-12T08:47:14+00:00

led_trigger_set() is the only caller of the deactivate() callback, and it calls led_set_brightness(LED_OFF) anyway after deactivate(). So we can remove the call here. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/8dc929e7-8e14-4c85-aa28-9c5fe2620f52@gmail.com Signed-off-by: Lee Jones

leds: trigger: netdev: Fix kernel panic on interface rename trig notify

2024-03-07T08:48:08+00:00

Commit d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") in the various changes, reworked the way to set the LINKUP mode in commit cee4bd16c319 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function. This changed the logic where, in the previous implementation the dev from the trigger event was used to check if the carrier was ok, but in the new implementation with the generic function, the dev in trigger_data is used instead. This is problematic and cause a possible kernel panic due to the fact that the dev in the trigger_data still reference the old one as the new one (passed from the trigger event) still has to be hold and saved in the trigger_data struct (done in the NETDEV_REGISTER case). On calling of get_device_state(), an invalid net_dev is used and this cause a kernel panic. To handle this correctly, move the call to get_device_state() after the new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER case) and correctly parse the new dev. Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20240203235413.1146-1-ansuelsmth@gmail.com Signed-off-by: Lee Jones

leds: trigger: netdev: Display only supported link speed attribute

2024-03-07T08:47:57+00:00

With the addition of more link speed mode to the netdev trigger, it was pointed out that there may be a problem with bloating the attribute list with modes that won't ever be supported by the trigger as the attached device name doesn't support them. To clear and address this problem, change the logic where these additional trigger modes are listed. Since the netdev trigger REQUIRE a device name to be set, attach to the device name change function additional logic to parse the supported link speed modes using ethtool APIs and show only the supported link speed modes attribute. Link speed attribute are refreshed on device_name set and on NETDEV_CHANGE events. This only apply to the link speed modes and every other mode is still provided by default. Signed-off-by: Christian Marangi Reviewed-by: Marek Behún Link: https://lore.kernel.org/r/20240111160501.1774-1-ansuelsmth@gmail.com Signed-off-by: Lee Jones

leds: trigger: netdev: Add module alias ledtrig:netdev

2024-03-07T08:47:56+00:00

Add module alias ledtrig:netdev to enable auto-loading of the module. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/84a1bbd3-1ac7-4f37-849a-7f4d31698f76@gmail.com Signed-off-by: Lee Jones