From: jbrunet@baylibre.com (Jerome Brunet)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH] nvmem: meson: use generic compatible
Date: Wed, 18 Oct 2017 09:31:07 +0200 [thread overview]
Message-ID: <1508311867.3957.33.camel@baylibre.com> (raw)
In-Reply-To: <20171017205204.t4vfvbc2c5nsrnhm@rob-hp-laptop>
On Tue, 2017-10-17 at 15:52 -0500, Rob Herring wrote:
> On Fri, Oct 13, 2017 at 09:39:13PM +0200, Jerome Brunet wrote:
> > On Fri, 2017-10-13 at 21:14 +0200, Martin Blumenstingl wrote:
> > > Hi Jerome,
> > >
> > > On Thu, Oct 12, 2017 at 5:24 PM, Jerome Brunet <jbrunet@baylibre.com>
> > > wrote:
> > > > The meson efuse driver seems to be compatible with more SoCs than
> > > > initially thought. Let's use the most generic compatible he have in
> > > > DT instead of the gxbb specific one
> > > >
> > > > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > > > ---
> > > > Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt | 4 ++--
> > > > drivers/nvmem/meson-efuse.c | 2 +-
> > > > 2 files changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
> > > > b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
> > > > index fafd85bd67a6..0260524292fe 100644
> > > > --- a/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
> > > > +++ b/Documentation/devicetree/bindings/nvmem/amlogic-efuse.txt
> > > > @@ -1,7 +1,7 @@
> > > > = Amlogic eFuse device tree bindings =
> > > >
> > > > Required properties:
> > > > -- compatible: should be "amlogic,meson-gxbb-efuse"
> > > > +- compatible: should be "amlogic,meson-gx-efuse"
>
> Same comment as for the firmware.
>
> > >
> > > have you checked with the devicetree maintainers how they want the
> > > documentation to look like in this case?
> >
> > You mean "Should we put every compatible existing (in DT) in the
> > documentation"
> > From what I've seen, at least in meson drivers, only the matched ones are
> > listed.
> >
> > That's a good question though.
> > We tend to put soc specific compatible "in case" we need them later on.
> > Should
> > we document those ?
>
> Absolutely.
My understanding is that this documentation is the documentation of the bindings
used by the driver.
If I understand your point, we should document bindings (compatible in that
case) that are in fact not fact by the driver. This means that if someone refer
only to the documentation, he might be surprised by the result.
>
> Rob
next prev parent reply other threads:[~2017-10-18 7:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 15:24 [PATCH] nvmem: meson: use generic compatible Jerome Brunet
2017-10-13 19:14 ` Martin Blumenstingl
2017-10-13 19:39 ` Jerome Brunet
2017-10-17 20:52 ` Rob Herring
2017-10-18 7:31 ` Jerome Brunet [this message]
2017-10-19 21:10 ` Rob Herring
2017-10-20 8:21 ` Jerome Brunet
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=1508311867.3957.33.camel@baylibre.com \
--to=jbrunet@baylibre.com \
--cc=linus-amlogic@lists.infradead.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