linux-stable.git/drivers/leds/trigger, branch linux-6.10.y

leds: triggers: Flush pending brightness before activating trigger

2024-08-03T07:00:39+00:00

commit ab477b766edd3bfb6321a6e3df4c790612613fae upstream.

The race fixed in timer_trig_activate() between a blocking
set_brightness() call and trigger->activate() can affect any trigger.
So move the call to flush_work() into led_trigger_set() where it can
avoid the race for all triggers.

Fixes: 0db37915d912 ("leds: avoid races with workqueue")
Fixes: 8c0f693c6eff ("leds: avoid flush_work in atomic context")
Cc: stable@vger.kernel.org
Tested-by: Dustin L. Howett 
Signed-off-by: Thomas Weißschuh 
Link: https://lore.kernel.org/r/20240613-led-trigger-flush-v2-1-f4f970799d77@weissschuh.net
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman

leds: trigger: pattern: Add support for hrtimer

2024-05-02T16:32:01+00:00

Currently, led pattern trigger uses timer_list to schedule brightness
changing. As we know from timer_list API [1], it's not accurate to
milliseconds and depends on HZ granularity.

Example:
"0 10 0 0 50 10 50 0 100 10 100 0 150 10 150 0 200 10 200 0 250 10 250 0",
we expect it to be 60ms long, but it can actually be up to ~120ms
(add ~10ms for each pattern when HZ == 100).

But sometimes, userspace needs time accurate led patterns to make sure
that pattern will be executed during expected time slot.
To achieve this goal the patch introduces optional hrtimer usage for
led trigger pattern, because hrtimer is microseconds accurate timer.

[1]: kernel/time/timer.c#L104

Signed-off-by: Martin Kurbanov 
Link: https://lore.kernel.org/r/20240416201847.357099-1-mmkurbanov@salutedevices.com
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: audio: Remove this trigger

2024-03-28T10:40:24+00:00

Now that the audio trigger is fully integrated in
sound/core/control_led.c, we can remove it here.

Signed-off-by: Heiner Kallweit 
Reviewed-by: Takashi Iwai 
Link: https://lore.kernel.org/r/1e339779-6d04-4392-8ea2-5592c0fd1aa2@gmail.com
Signed-off-by: Lee Jones

ALSA: control-led: Integrate mute led trigger

2024-03-28T10:39:50+00:00

This driver is the only one calling ledtrig_audio_set(), therefore
the LED audio trigger isn't usable standalone. So it makes sense
to fully integrate LED audio triger handling here.

The module aliases ensure that the driver is auto-loaded (if built
as module) if a LED device has one of the two audio triggers as
default trigger.

In addition disable building the old audio mute LED trigger.

Signed-off-by: Heiner Kallweit 
Reviewed-by: Takashi Iwai 
Link: https://lore.kernel.org/r/107634e6-d9ad-4a9f-881d-1eb72ea1a5a7@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: panic: Simplify led_trigger_set_panic

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

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:00+00:00

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:59+00:00

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