Hi,

On Tue, Apr 03, 2018 at 12:49:08PM +0200, Pavel Machek wrote:
> > +enum ti_lmu_bl_type {
> > +   TI_LMU_BL,  /* backlight userspace interface */
> > +   TI_LMU_LED, /* led userspace interface */
> > +};
> ...
> > +static int ti_lmu_bl_add_device(struct ti_lmu_bank *lmu_bank)
> > +{
> > +   switch (lmu_bank->type) {
> > +   case TI_LMU_BL:
> > +           return ti_lmu_bl_register_backlight(lmu_bank);
> > +   case TI_LMU_LED:
> > +           return ti_lmu_bl_register_led(lmu_bank);
> > +   default:
> > +           return -EINVAL;
> > +   }
> > +}
> 
> Ok, this is somehow unusual/crazy. Single driver with two
> interfaces.
> 
> Do we need the LED interface for something?
>
> If yes, I believe reasonable solution would be to always provide LED
> interface, and then have "backlight-trigger" which that would provide
> backlight interface for arbitrary LED.

Userspace expects keyboard backlight to be exposed via the LED
subsystem and display backlight via the backlight subsystem.

I considered always exposing the banks via the LED subsystem and
using a generic backlight driver. That brings its own problems,
since there is a dependency between the display and the backlight.
This is described in DT using a phandle. Getting the right backlight
device from the phandle will become very tricky with this approach.

-- Sebastian

Attachment: signature.asc
Description: PGP signature

Reply via email to