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

[Daniel Thompson <daniel@riscstar.com>]

On Mon, Aug 24, 2026 at 10:39:19AM -0500, Andrew Davis wrote:
> 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.

Yes, led_bl disables the sysfs interface of any LED supplier(s). Note
that this is not changed by anything in the patch series ([1/2]
rearranges the code slghtlt but this has always been the case).


> > 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).

Agreed, although it does allow an existing board not to change userspace
ABI based on a Kconfig option.


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

Mod config isn't "nice" although it might be a good enough solution for
what is probably a fairly niche issue if nothing better comes up.

I'd also note that a mod config would also allow the driver to error out
when CONFIG_LED_BL is not set (with a hint on the logs to either enable
LED_BL or set the config option) rather then the current "secret" ABI
change.


Daniel.