linux-kernel - Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 Nov 2017 21:19:37 -0500
From:   "Jingoo Han" <jingoohan1@...il.com>
To:     "'Dan Murphy'" <dmurphy@...com>,
        "'Jacek Anaszewski'" <jacek.anaszewski@...il.com>,
        "'Pavel Machek'" <pavel@....cz>
Cc:     <robh+dt@...nel.org>, <mark.rutland@....com>, <rpurdie@...ys.net>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-leds@...r.kernel.org>, "'Lee Jones'" <lee.jones@...aro.org>,
        "'Daniel Thompson'" <daniel.thompson@...aro.org>
Subject: Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver

On Thursday, November 16, 2017 4:42 PM, Dan Murphy wrote:
> 
> Jacek
> 
> On 11/16/2017 02:14 PM, Jacek Anaszewski wrote:
> > Hi Dan and Pavel,
> >
> > On 11/15/2017 11:23 PM, Pavel Machek wrote:
> >> Hi!
> >>
> >>>> Shouldn't the driver be targeted for backlight subsystem then?
> >>>>
> >>>> Adding backlight maintainers.
> >>>>
> >>>
> >>> Great point!  I was not aware of the backlight subsystem.
> >>>
> >>> Looks like I need to create a back light version as well.
> >>>
> >>> Like the lp8788 did since this can be used as a LED driver beyond
> >>> display back lighting.
> >>
> >> No, definitely not two drivers for lp8788 hardware.
> >
> > I agree.
> >
> >> If that does not yet exist... you want to create glue layer to be able
> >> to use LED as a display backlight. (It may already exist, no idea).
> >>
> >> ...
> >>
> >> Actually or maybe a LED trigger. Just set LED's trigger to "this is
> >> display backlight".
> >
> > There is one already:
> >
> > drivers/leds/trigger/ledtrig-backlight.c
> >
> > It adds a LED class device to the fb_notifier_list
> > (drivers/video/fbdev/core/fb_notify.c)
> >
> > using fb_register_client(). The same is used in
> > backlight_device_register (drivers/video/backlight/backlight.c).
> >
> > Actually why do you want to have this driver in the LED subsystem,
> > if it is advertised as "designed for LCD display backlighting"?
> 
> Well this is also advertised as a driver for Smart phone and tablet
> devices.  And having worked with the Android lighting
> solutions this is the preferred subsystem for Android.  The Android OS
> manages the led brightness based on ALS values and in
> turn calls into the driver to control the brightness register through the
> vendor provided lighting HAL.
> 
> I am going to look at the backlight source to figure out how to get the
> same functionality using the backlight subsystem.
> Otherwise I will plug in this driver to the backlight subsystem through
> the notifier.


I also developed Android devices for a long time.
I think that modifying HAL will not be difficult.

Also, backlight subsystem will be similar with LED subsystem.
You can grasp it easily.

Best regards,
Jingoo Han

> 
> >
> > As a side note I can say that I've been always wondering why the two
> > subsystems for similar type of hardware.
> 
> This is my worry too.  Why do we need both subsystems to do the same
thing?
> 
> I don't see either having one advantage over the other.
> 
> 
> Dan
> >
> 
> 
> --
> ------------------
> Dan Murphy