Re: [RFC PATCH 1/9] leds: Load trigger modules on-demand if used as hw control trigger

[Andrew Lunn]

> While I agree that the current policy makes its own sense and works
> well on most devices, it leads to out-of-sync software states on recent
> laptops.
> 
> When the LED's hardware autonomously put itself into hw control mode,
> it is offloaded to the hardware per se -- we *can't* prevent this from
> happening.

If you cannot control the hardware, why are you trying to control the
hardware?

> The series is about how to update software state to reflect the
> hardware state change. Blindly keeping the software state despite the
> hardware state is hardly meaningful and makes software out-of-sync.

Since you cannot control the hardware, just don't register the
LED. That gives a truer picture. Something else than Linux is
controlling it.

Do you get a notification when that something else takes control? ACPI
event or something? If you do, can just re-impose the software state
back on the hardware.

> As shown above, this series doesn't change the LED's hardware state and
> it just updates the software state to notify user about that. If you'd
> like to enforce software state's priority, we would have to explicitly
> undo the hardware state change immediately after the LED's hardware has
> autonomously activated/deactivated hw control mode.

Yes, if you decide Linux is driving the hardware, the Linux state
should always be imposed back on the hardware. Just consider it flaky
hardware which needs hitting over the head every so often to make
work.

But maybe we should take a step back here. What are your real use
cases here? Why do you want Linux to control this hardware, when
something else already is controlling it? Is /sys/class/led even the
right API? That will depend on what your use cases are.

	Andrew