linux-kernel - Re: [rfc] leds: add TI LMU backlight 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]

Message-ID: <20180830201825.GA1936@amd>
Date:   Thu, 30 Aug 2018 22:18:25 +0200
From:   Pavel Machek <pavel@....cz>
To:     Dan Murphy <dmurphy@...com>
Cc:     linux-leds@...r.kernel.org, jacek.anaszewski@...il.com,
        kernel list <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-omap@...r.kernel.org, tony@...mide.com, sre@...nel.org,
        nekit1000@...il.com, mpartap@....net, merlijn@...zup.org
Subject: Re: [rfc] leds: add TI LMU backlight driver

Hi!

> > Here's preview of driver for TI LMU. It controls LEDs on Droid 4
> > smartphone, including keyboard and screen backlights.
> > 
> > This adds backlight support for the following TI LMU
> > chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
> > 
> > Signed-off-by: Milo Kim <milo.kim@...com>
> > [add LED subsystem support for keyboard backlight and rework DT
> > binding according to Rob Herrings feedback]
> > Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.co.uk>
> > [remove backlight subsystem support for now]
> > Signed-off-by: Pavel Machek <pavel@....cz>
> > 
> > ---
> > 
> > Does it looks mostly reasonable? I guess it will need some
> > s/BACKLIGHT/LEDS/ , and I'll need to remove my debugging hacks.
> > 
> > I'd prefer this to be LED driver, first; I'll need to figure out what
> > to do with backlight. I guess something like existing "backlight"
> > trigger should do the trick.
> > 
> 
> I looked at this driver from Milo before submitting a specific LM3697 driver.

Aha. I did not realize that was for same hardware... I should have
cc-ed you, I guess.

> I do not like this driver.
> I don't like that it smashes numerous devices into some structure with varying register maps.
>

Can you elaborate? The chips are similar enough that single driver
makes sense, and we certainly want to maintain one driver, not 6
drivers differing only in .. what exactly?

> Not only that but it appears that you just pulled this driver from a repo and posted it without clean up.
> 

a) No I did not, feel free to generate a diff.

b) Even if I did, why would that be a problem?

> If the devices share register maps and can be added to families I would prefer to do it that way.
> 
> So if the LM3695 and LM3697 share the same features and register map they should be one driver
> The LM363x series may be able to be a different driver.

Well all 6 chips this driver supports seem to be similar enough, so
that single driver makes sense.

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)