[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180417144457.2831140e@avionic-0020>
Date: Tue, 17 Apr 2018 14:44:57 +0200
From: Alban <albeu@...e.fr>
To: Rob Herring <robh@...nel.org>
Cc: Alban <albeu@...e.fr>, linux-kernel@...r.kernel.org,
Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
Mark Rutland <mark.rutland@....com>,
David Woodhouse <dwmw2@...radead.org>,
Brian Norris <computersforpeace@...il.com>,
Boris Brezillon <boris.brezillon@...e-electrons.com>,
Marek Vasut <marek.vasut@...il.com>,
Richard Weinberger <richard@....at>,
Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
devicetree@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: [PATCH v3 2/3] doc: bindings: Add bindings documentation for
mtd nvmem
On Mon, 16 Apr 2018 16:08:51 -0500
Rob Herring <robh@...nel.org> wrote:
> On Sun, Mar 25, 2018 at 12:24:58AM +0100, Alban Bedel wrote:
> > Config data for drivers, like MAC addresses, is often stored in MTD.
> > Add a binding that define how such data storage can be represented in
> > device tree.
> >
> > Signed-off-by: Alban Bedel <albeu@...e.fr>
> > ---
> > Changelog:
> > v2: * Added a "Required properties" section with the nvmem-provider
> > property
> > v3: * Fixed my name in From and Signed-off-by
> > * Moved to the new nvmem binding with the nvmem-cells subnode
> > ---
> > .../devicetree/bindings/nvmem/mtd-nvmem.txt | 27 ++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> >
> > diff --git a/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > new file mode 100644
> > index 0000000..c819a69
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > @@ -0,0 +1,27 @@
> > += NVMEM in MTD =
> > +
> > +Config data for drivers, like MAC addresses, is often stored in MTD.
> > +An MTD device, or one of its partition, can be defined as a NVMEM provider
> > +by having an 'nvmem-cells' subnode as defined in nvmem.txt.
> > +
> > +Example:
> > +
> > + flash@0 {
> > + ...
> > +
> > + partition@2 {
>
> This unit address is not correct...
Is it because I ellipsed the #address-cells and #size-cells? I will add
them.
> > + label = "art";
> > + reg = <0x7F0000 0x010000>;
>
> Lowercase hex.
Will do.
> > + read-only;
> > +
> > + nvmem-cells {
> > + compatible = "nvmem-cells";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + eeprom@...0 {
>
> "eeprom" isn't specific data. The purpose of the nvmem binding is to
> provide specific data fields like MAC addresseses.
>
> Plus "eeprom" is the node name for EEPROM devices.
This example is from a board using an ath9k chip and this field contains
what the driver names EEPROM, although it is in fact only a config
binary blob. However I agree that it is misleading for such an example,
I will replace it with something like "wifi-config-data".
Alban
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists