linux-kernel - Re: [PATCH v7 1/6] dt-bindings: ti-lmu: Remove LM3697

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:   Fri, 14 Sep 2018 10:18:23 +0200
From:   Pavel Machek <pavel@....cz>
To:     Dan Murphy <dmurphy@...com>
Cc:     robh+dt@...nel.org, jacek.anaszewski@...il.com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        lee.jones@...aro.org, linux-omap@...r.kernel.org,
        linux-leds@...r.kernel.org
Subject: Re: [PATCH v7 1/6] dt-bindings: ti-lmu: Remove LM3697

Hi!

> >> How do I politely explain that the original implementation was wrong for certain devices?
> > 
> > Implementation? Device tree is hardware description.
> 
> Yes this hardware description is incorrect.  The hardware description is
> describing a MFD but this LED driver (and a couple others) only perform
> 1 function and that is to drive a LED string.

So what? Does not seem incorrect to me. Maybe the description should
not be in MFD directory, but other than that...

> >> Isn't code and documentation supposed to be pushed in stages
> >> together?
> > 
> > Device tree is _not_ documentation. And yes, it is normally pushed
> > together. But that did not happen here, and bindings are already in.
> 
> Hmm..  Its not documentation but it is in the Documentation folder.
> And just because the bindings are in does not mean they cannot be
> changed.

You may want to learn more about device tree and/or talk to the device
tree maintainers. This is an old article. https://lwn.net/Articles/561462/

NAK on this patch. I see that this binding has problems, but
introducing different binding for subset of devices is _not_ a fix.

> > What about the multi function devices? They should have same binding.
> 
> The MFD devices defined are not in contention here only the SFD.

I'd like to see common solutions for SFD and MFD, as the hardware is
similar, and that includes the code. Having code that is easier to
maintain is important, and having many drivers are harder to maintain
than one driver.

Milo's code looks better than yours in that regard. I disagree about
Milo's code being "nightmare" to modify, and care about "easy to
maintain" more than "binary size".

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)