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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ