kernel/drivers/leds/trigger, branch linux-6.9.y

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

2024-03-07T08:48:08Z

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: panic: Simplify led_trigger_set_panic

2024-03-07T08:48:01Z

I don't see why we iterate over all triggers to find the panic trigger. We *are* the panic trigger. Therefore we also know that the panic trigger doesn't have an activate() hook. So we can simplify the code significantly. Signed-off-by: Heiner Kallweit Reviewed-by: Jacek Anaszewski Link: https://lore.kernel.org/r/84c0fa67-2f03-4474-aa75-914d65d88dd0@gmail.com Signed-off-by: Lee Jones

leds: triggers: default-on: Add module alias for module auto-loading

2024-03-07T08:48:00Z

A bigger number of board device tree files, plus few drivers, set default-on as default trigger for LED's. Therefore add an alias for module auto-loading. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/7e94d26b-d772-4a07-b0f6-bb3111b9ff75@gmail.com Signed-off-by: Lee Jones

leds: trigger: audio: Set module alias for module auto-loading

2024-03-07T08:47:59Z

This a follow-up to 5edf7f11313d ("leds: trigger: Load trigger modules on-demand if used as default trigger") and sets an alias for the audio triggers. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/4663d2d8-660d-4af2-9f65-d95e95263923@gmail.com Signed-off-by: Lee Jones

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

2024-03-07T08:47:57Z

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:56Z

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

leds: trigger: netdev: Skip setting baseline state in activate if hw-controlled

2024-03-07T08:47:50Z

The current codes uses the sw_control path in set_baseline_state() when called from netdev_trig_activate() even if we're hw-controlled. This may result in errors when led_set_brightness() is called because we may not have set_brightness led ops (if hw doesn't support setting a "LED" to ON). In addition this path may schedule trigger_data->work which doesn't make sense when being hw-controlled. Therefore set trigger_data->hw_control = true before calling set_device_name() from netdev_trig_activate(). In this call chain we have to prevent set_baseline_state() from being called, because this would call hw_control_set(). Use led_cdev->trigger_data == NULL as indicator for being called from netdev_trig_activate(). Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/d3f2859c-2673-401c-a4f7-fcaef2167991@gmail.com Signed-off-by: Lee Jones

Merge tag 'leds-next-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds

2024-01-17T23:25:27Z

Pull LED updates from Lee Jones: "New Drivers: - Add support for Allwinner A100 RGB LED controller - Add support for Maxim 5970 Dual Hot-swap controller New Device Support: - Add support for AW20108 to Awinic LED driver New Functionality: - Extend support for Net speeds to include; 2.5G, 5G and 10G - Allow tx/rx and cts/dsr/dcd/rng TTY LEDS to be turned on and off via sysfs if required - Add support for hardware control in AW200xx Fix-ups: - Use safer methods for string handling - Improve error handling; return proper error values, simplify, avoid duplicates, etc - Replace Mutex use with the Completion mechanism - Fix include lists; alphabetise, remove unused, explicitly add used - Use generic platform device properties - Use/convert to new/better APIs/helpers/MACROs instead of hand-rolling implementations - Device Tree binding adaptions/conversions/creation - Continue work to remove superfluous platform .remove() call-backs - Remove superfluous/defunct code - Trivial; whitespace, unused variables, spelling, clean-ups, etc - Avoid unnecessary duplicate locks Bug Fixes: - Repair Kconfig based dependency lists - Ensure unused dynamically allocated data is freed after use - Fix support for brightness control - Add missing sufficient delays during reset to ensure correct operation - Avoid division-by-zero issues" * tag 'leds-next-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (45 commits) leds: trigger: netdev: Add core support for hw not supporting fallback to LED sw control leds: trigger: panic: Don't register panic notifier if creating the trigger failed leds: sun50i-a100: Convert to be agnostic to property provider leds: max5970: Add missing headers leds: max5970: Make use of dev_err_probe() leds: max5970: Make use of device properties leds: max5970: Remove unused variable leds: rgb: Drop obsolete dependency on COMPILE_TEST leds: sun50i-a100: Avoid division-by-zero warning leds: trigger: Remove unused function led_trigger_rename_static() leds: qcom-lpg: Introduce a wrapper for getting driver data from a pwm chip leds: gpio: Add kernel log if devm_fwnode_gpiod_get() fails dt-bindings: leds: qcom,spmi-flash-led: Fix example node name dt-bindings: leds: aw200xx: Fix led pattern and add reg constraints dt-bindings: leds: awinic,aw200xx: Add AW20108 device leds: aw200xx: Add support for aw20108 device leds: aw200xx: Improve autodim calculation method leds: aw200xx: Enable disable_locking flag in regmap config leds: aw200xx: Add delay after software reset dt-bindings: leds: aw200xx: Remove property "awinic,display-rows" ...

leds: trigger: netdev: Add core support for hw not supporting fallback to LED sw control

2023-12-21T16:25:21Z

If hw doesn't support sw control of the LED and we switch to a mode not supported by hw, currently we get lots of errors because neither brigthness_set() nor brithness_set_blocking() is set. Deal with this by not falling back to sw control, and return -EOPNOTSUPP to the user. Note that we still store the new mode. This is needed in case an intermediate unsupported mode is necessary to switch from one supported mode to another. Add a comment explaining how a driver for such hw is supposed to behave. Signed-off-by: Heiner Kallweit Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/3fd5184c-3641-4b0b-b59a-f489ec69a6cd@gmail.com Signed-off-by: Lee Jones

leds: trigger: panic: Don't register panic notifier if creating the trigger failed

2023-12-21T14:54:45Z

It doesn't make sense to register the panic notifier if creating the panic trigger failed. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/8a61e229-5388-46c7-919a-4d18cc7362b2@gmail.com Signed-off-by: Lee Jones