From: Pavel Machek <pavel@ucw.cz>
To: Dan Murphy <dmurphy@ti.com>
Cc: robh+dt@kernel.org, jacek.anaszewski@gmail.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
lee.jones@linaro.org, linux-omap@vger.kernel.org,
linux-leds@vger.kernel.org
Subject: Re: [PATCH v7 1/6] dt-bindings: ti-lmu: Remove LM3697
Date: Fri, 14 Sep 2018 10:18:23 +0200 [thread overview]
Message-ID: <20180914081822.GA21830@amd> (raw)
In-Reply-To: <7950fa32-c8f9-52bb-06b0-0c1cc93b6bc9@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2018-09-14 8:18 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 17:08 [PATCH v7 0/6] LM3697 dedicated LED driver Dan Murphy
2018-09-11 17:08 ` [PATCH v7 1/6] dt-bindings: ti-lmu: Remove LM3697 Dan Murphy
2018-09-11 18:14 ` Lee Jones
2018-09-11 20:05 ` Pavel Machek
2018-09-11 21:48 ` Dan Murphy
2018-09-12 21:49 ` Pavel Machek
2018-09-13 15:15 ` Dan Murphy
2018-09-14 8:18 ` Pavel Machek [this message]
2018-09-14 20:15 ` Jacek Anaszewski
2018-09-14 21:42 ` Pavel Machek
2018-09-15 20:00 ` Jacek Anaszewski
2018-09-17 15:24 ` Dan Murphy
2018-09-17 19:22 ` Jacek Anaszewski
2018-09-17 21:23 ` Dan Murphy
2018-09-20 22:04 ` Pavel Machek
2018-09-21 12:44 ` Dan Murphy
2018-09-14 8:23 ` Pavel Machek
2018-09-12 18:35 ` Jacek Anaszewski
2018-09-11 17:08 ` [PATCH v7 2/6] mfd: ti-lmu: Remove support for LM3697 Dan Murphy
2018-09-11 18:13 ` Lee Jones
2018-09-11 17:08 ` [PATCH v7 3/6] dt-bindings: leds: Add bindings for lm3697 driver Dan Murphy
2018-09-24 16:18 ` Rob Herring
2018-09-24 18:02 ` Pavel Machek
2018-09-25 19:39 ` Rob Herring
2018-09-25 21:19 ` Dan Murphy
2018-09-11 17:08 ` [PATCH v7 4/6] leds: lm3697: Introduce the " Dan Murphy
2018-09-11 17:08 ` [PATCH v7 5/6] dt-bindings: leds: Add runtime ramp node for LM3697 Dan Murphy
2018-09-11 17:08 ` [PATCH v7 6/6] leds: lm3697: Add ramp rate feature Dan Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180914081822.GA21830@amd \
--to=pavel@ucw.cz \
--cc=devicetree@vger.kernel.org \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).