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

On Mon, Aug 24, 2026 at 10:39:19AM -0500, Andrew Davis wrote:

On 8/24/26 4:33 AM, Daniel Thompson wrote:

quoted

On Mon, Aug 17, 2026 at 07:08:15PM +0200, A. Sverdlin wrote:

quoted

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

quoted

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.

quoted

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.