Re: [PATCH 2/2] leds: lp8864: Register a backlight device

[Andrew Davis <afd@ti.com>]

On 8/24/26 4:33 AM, Daniel Thompson wrote:
> On Mon, Aug 17, 2026 at 07:08:15PM +0200, A. Sverdlin wrote:
>> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
>>
>> The LP8864/LP8866 is a display-cluster LED backlight driver. Expose a
>> standard backlight class interface in addition to the LED class device,
>> so it can be used by display/panel stacks that expect a backlight.
>>
>> Use the new devm_led_backlight_register() helper, which spawns a
>> led-backlight device driven by our LED and tied to the I2C device
>> lifetime. This keeps the driver a plain LED driver, requires no
>> device-tree changes and remains backwards compatible with existing DTs.
>> It is a no-op when the led-backlight support is not enabled.
> 
> ... but when led-backlight support is enabled it will prohibit the use
> of the LED sysfs interface.
> 

The commit message states "in addition to" so both are registered still.
The issue would be in the [1/2] patch if it disables the LED sysfs interface
as this might be unexpected behavior to not keep both interfaces active.

> Having zero DT changes is a nice property but it seems rather fragile to
> change the ABI the userspace must use to manipulate the LED based on
> CONFIG_LED_BL.
> 

If this was done in DT then it would also change the API userspace must
use in a non-flexible way (DT is also considered a fixed ABI for a board).

> Is there no way to explictly configure which ABI should be used?
> 

I wonder if there is a good way to have the actual use of one API cause
the other to be disabled at runtime? So the first one used disables the
other, but that does sound like a race.

Maybe a mod config to disable the LED-BL path and keep the simple LED
sysfs interface would be enough. Or maybe a sysfw entry so it could
be set per-device if needed.

Andrew

> 
> Daniel.