[v3,2/3] doc: bindings: Add bindings documentation for mtd nvmem

Message ID 1521933899-362-3-git-send-email-albeu@free.fr
State Changes Requested
Delegated to: Boris Brezillon
Headers show
Series
  • mtd: Add support for reading MTD devices via the nvmem API
Related show

Commit Message

Alban March 24, 2018, 11:24 p.m.
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@free.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

Comments

Rob Herring April 16, 2018, 9:08 p.m. | #1
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@free.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...

> +			label = "art";
> +			reg = <0x7F0000 0x010000>;

Lowercase hex.

> +			read-only;
> +
> +			nvmem-cells {
> +				compatible = "nvmem-cells";
> +				#address-cells = <1>;
> +				#size-cells = <1>;
> +
> +				eeprom@1000 {

"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.

> +					reg = <0x1000 0x1000>;
> +				};
> +			};
> +		};
> +	};
> -- 
> 2.7.4
>
Alban April 17, 2018, 12:44 p.m. | #2
On Mon, 16 Apr 2018 16:08:51 -0500
Rob Herring <robh@kernel.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@free.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@1000 {  
> 
> "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

Patch

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 {
+			label = "art";
+			reg = <0x7F0000 0x010000>;
+			read-only;
+
+			nvmem-cells {
+				compatible = "nvmem-cells";
+				#address-cells = <1>;
+				#size-cells = <1>;
+
+				eeprom@1000 {
+					reg = <0x1000 0x1000>;
+				};
+			};
+		};
+	};