Re: [RFC PATCH 0/9] leds: Add support for hw initiated hw control trigger transition

[Andrew Lunn]

On Sat, Feb 28, 2026 at 03:05:57AM +0800, Rong Zhang wrote:
> Hi all,
> 
> Some laptops can tune their keyboard backlight according to ambient
> light sensors (auto mode). This capability is essentially a hw control
> trigger. Meanwhile, such laptops also offer a shrotcut for cycling
> through brightness levels and auto mode. For example, on ThinkBook,
> pressing Fn+Space cycles keyboard backlight levels in the following
> sequence:
> 
>   1 => 2 => 0 => auto => 1 ...
> 
> Recent ThinkPad models should have similar sequence too.

With networking, we consider the hardware as an accelerator for what
the Linux network stack can already do in software. We let the user
configure the network stack however they want it, and then we ask the
hardware, can you accelerate this, so we don't need to do it in
software? It might say -EOPNOTSUPP, so it is left in software. It
might say 0, and we never see the packets, because the hardware is
doing the work. The user is not really aware acceleration is
happening, because they just configure the network stack how they
want, independent of acceleration or not.

For PHY and MAC LEDs it is exactly the same. Generally, the LEDs in
RJ45 connectors, or on the front panel can be turned on/off. The
netdev LED trigger knows if the link is 10M, 100M, 1G etc. It knows if
packets are being transmitted or received. It can make the LEDs show
the link speed, or blink for packet activity, in software, using
simple set_brightness calls. It will also ask the LED, can you
accelerate this? Can you get the state directly from the PHY/MAC? The
LED in my keyboard shift lock will say -EOPNOTSUPP, and the netdev
trigger will keep blinking it in software. The LED driver by the PHY
might say 0, and blink the LED itself. Or it might say -EOPNOTSUPP,
because the vendor decided to only support RX+TX, not only RX.

My preference is this model of accelerating what Linux can already do
should be used everywhere.

You know how many levels the LED supports, so the trigger can easily
implement the steps, 0, 1, 2, 0, 1, 2, based on receiving some event
from somewhere.  You can also accelerate this, you can ask the LED,
can you directly receive the event? -EOPNOTSUPP, keep controlling it
from software. 0, stop driving it from software, the hardware will
accelerate it.

If the system has access to a light sensor, the trigger can also
decide on 0, 1, or 2, based on polling the light sensor every
second. It can then ask the LED, do you have direct access to the
light sensor, can you accelerate this?

The experience from networking is, once you get into the mindset of
the hardware is there to accelerate what Linux can already do, a lot
of problems just disappear. It might you first need to implement the
software version, but once you have that, acceleration is easy.

Does Linux already have a software version of what you want? Can you
accelerate it?

	Andrew