[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1508311867.3957.33.camel@baylibre.com>
Date: Wed, 18 Oct 2017 09:31:07 +0200
From: Jerome Brunet <jbrunet@...libre.com>
To: Rob Herring <robh@...nel.org>
Cc: Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Kevin Hilman <khilman@...libre.com>,
Carlo Caione <carlo@...one.org>, devicetree@...r.kernel.org,
linux-amlogic@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] nvmem: meson: use generic compatible
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@...libre.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@...libre.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
Powered by blists - more mailing lists