Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Alban]

On Thu, 2 Mar 2017 21:22:20 +0100
Boris Brezillon  wrote:

> On Thu,  2 Mar 2017 20:50:21 +0100
> Alban  wrote:
> 
> > Add the binding to expose MTD partitions as nvmem providers.  
> 
> Looks good. Maybe you should take the case you describe in your
> cover-letter into account and add an extra layer: add an nvmem sub-node
> containing the nvmem cells, so that you can expose nvmem cells directly
> under master MTD devices (and not only partitions). 

I think that would be the better solution. This can be done
independently, once we agree on a binding we just have to fix
of_nvmem_cell_get(). My suggestion would be to have the new binding
looking like this:

nvmem-device@10 {
...
nvmem-provider;
nvmem-cells {
compatible = "nvmem-cells";
#address-cells = <1>;
#size-cells = <1>;

nvmem-cell@100 {
label = "mac-address";
reg = <0x100 0x200>;
}

...
}
}

I would also suggest making the "nvmem-provider" property mandatory
to indicate that the device provides this capability. Up to now all
nvmem providers only support this API but I think there might be more
multi function devices in the future.

Alban


pgpY3XaCu6XUV.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Alban]

On Thu, 2 Mar 2017 21:22:20 +0100
Boris Brezillon  wrote:

> On Thu,  2 Mar 2017 20:50:21 +0100
> Alban  wrote:
> 
> > Add the binding to expose MTD partitions as nvmem providers.  
> 
> Looks good. Maybe you should take the case you describe in your
> cover-letter into account and add an extra layer: add an nvmem sub-node
> containing the nvmem cells, so that you can expose nvmem cells directly
> under master MTD devices (and not only partitions). 

I think that would be the better solution. This can be done
independently, once we agree on a binding we just have to fix
of_nvmem_cell_get(). My suggestion would be to have the new binding
looking like this:

nvmem-device@10 {
...
nvmem-provider;
nvmem-cells {
compatible = "nvmem-cells";
#address-cells = <1>;
#size-cells = <1>;

nvmem-cell@100 {
label = "mac-address";
reg = <0x100 0x200>;
}

...
}
}

I would also suggest making the "nvmem-provider" property mandatory
to indicate that the device provides this capability. Up to now all
nvmem providers only support this API but I think there might be more
multi function devices in the future.

Alban


pgpY3XaCu6XUV.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Alban]

On Fri, 3 Mar 2017 13:37:44 +0100
Boris Brezillon  wrote:

> On Fri, 3 Mar 2017 13:17:05 +0100
> Alban  wrote:
> 
> > On Thu, 2 Mar 2017 21:22:20 +0100
> > Boris Brezillon  wrote:
> >   
> > > On Thu,  2 Mar 2017 20:50:21 +0100
> > > Alban  wrote:
> > > 
> > > > Add the binding to expose MTD partitions as nvmem providers.  
> > > 
> > > Looks good. Maybe you should take the case you describe in your
> > > cover-letter into account and add an extra layer: add an nvmem sub-node
> > > containing the nvmem cells, so that you can expose nvmem cells directly
> > > under master MTD devices (and not only partitions). 
> > 
> > I think that would be the better solution. This can be done
> > independently, once we agree on a binding we just have to fix
> > of_nvmem_cell_get(). My suggestion would be to have the new binding
> > looking like this:
> > 
> > nvmem-device@10 {
> > ...
> > nvmem-provider;
> > nvmem-cells {
> > compatible = "nvmem-cells";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > 
> > nvmem-cell@100 {
> > label = "mac-address";
> > reg = <0x100 0x200>;
> > }
> > 
> > ...
> > }
> > }
> > 
> > I would also suggest making the "nvmem-provider" property mandatory
> > to indicate that the device provides this capability. Up to now all
> > nvmem providers only support this API but I think there might be more
> > multi function devices in the future.  
> 
> If you enforce the name of the child node (here nvmem-cells), you don't
> need this extra nvmem-provider property. Am I missing something?

That property would define the capability to be used as nvmem-provider,
furthermore it would cover the case where no cell is defined. Also in
the case of MTD devices it would avoid an ambiguity when there is no
'partitions' sub node, as then the nvmem-cells node could be interpreted
as a partition following the old binding.

From what I understand most of such "implicit" binding have sooner or
later proved to be too limited, or worth, clashing with another one.
They then had to be deprecated and replaced by explicit ones. The MTD
partitions binding is a good example of such evolution.

Alban


pgpsZ2o8rgbXB.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Alban]

On Fri, 3 Mar 2017 13:37:44 +0100
Boris Brezillon  wrote:

> On Fri, 3 Mar 2017 13:17:05 +0100
> Alban  wrote:
> 
> > On Thu, 2 Mar 2017 21:22:20 +0100
> > Boris Brezillon  wrote:
> >   
> > > On Thu,  2 Mar 2017 20:50:21 +0100
> > > Alban  wrote:
> > > 
> > > > Add the binding to expose MTD partitions as nvmem providers.  
> > > 
> > > Looks good. Maybe you should take the case you describe in your
> > > cover-letter into account and add an extra layer: add an nvmem sub-node
> > > containing the nvmem cells, so that you can expose nvmem cells directly
> > > under master MTD devices (and not only partitions). 
> > 
> > I think that would be the better solution. This can be done
> > independently, once we agree on a binding we just have to fix
> > of_nvmem_cell_get(). My suggestion would be to have the new binding
> > looking like this:
> > 
> > nvmem-device@10 {
> > ...
> > nvmem-provider;
> > nvmem-cells {
> > compatible = "nvmem-cells";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > 
> > nvmem-cell@100 {
> > label = "mac-address";
> > reg = <0x100 0x200>;
> > }
> > 
> > ...
> > }
> > }
> > 
> > I would also suggest making the "nvmem-provider" property mandatory
> > to indicate that the device provides this capability. Up to now all
> > nvmem providers only support this API but I think there might be more
> > multi function devices in the future.  
> 
> If you enforce the name of the child node (here nvmem-cells), you don't
> need this extra nvmem-provider property. Am I missing something?

That property would define the capability to be used as nvmem-provider,
furthermore it would cover the case where no cell is defined. Also in
the case of MTD devices it would avoid an ambiguity when there is no
'partitions' sub node, as then the nvmem-cells node could be interpreted
as a partition following the old binding.

From what I understand most of such "implicit" binding have sooner or
later proved to be too limited, or worth, clashing with another one.
They then had to be deprecated and replaced by explicit ones. The MTD
partitions binding is a good example of such evolution.

Alban


pgpsZ2o8rgbXB.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Boris Brezillon]

On Fri, 3 Mar 2017 13:17:05 +0100
Alban  wrote:

> On Thu, 2 Mar 2017 21:22:20 +0100
> Boris Brezillon  wrote:
> 
> > On Thu,  2 Mar 2017 20:50:21 +0100
> > Alban  wrote:
> >   
> > > Add the binding to expose MTD partitions as nvmem providers.
> > 
> > Looks good. Maybe you should take the case you describe in your
> > cover-letter into account and add an extra layer: add an nvmem sub-node
> > containing the nvmem cells, so that you can expose nvmem cells directly
> > under master MTD devices (and not only partitions).   
> 
> I think that would be the better solution. This can be done
> independently, once we agree on a binding we just have to fix
> of_nvmem_cell_get(). My suggestion would be to have the new binding
> looking like this:
> 
> nvmem-device@10 {
>   ...
>   nvmem-provider;
>   nvmem-cells {
>   compatible = "nvmem-cells";
>   #address-cells = <1>;
>   #size-cells = <1>;
> 
>   nvmem-cell@100 {
>   label = "mac-address";
>   reg = <0x100 0x200>;
>   }
> 
>   ...
>   }
> }
> 
> I would also suggest making the "nvmem-provider" property mandatory
> to indicate that the device provides this capability. Up to now all
> nvmem providers only support this API but I think there might be more
> multi function devices in the future.

If you enforce the name of the child node (here nvmem-cells), you don't
need this extra nvmem-provider property. Am I missing something?

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Boris Brezillon]

On Fri, 3 Mar 2017 13:17:05 +0100
Alban  wrote:

> On Thu, 2 Mar 2017 21:22:20 +0100
> Boris Brezillon  wrote:
> 
> > On Thu,  2 Mar 2017 20:50:21 +0100
> > Alban  wrote:
> >   
> > > Add the binding to expose MTD partitions as nvmem providers.
> > 
> > Looks good. Maybe you should take the case you describe in your
> > cover-letter into account and add an extra layer: add an nvmem sub-node
> > containing the nvmem cells, so that you can expose nvmem cells directly
> > under master MTD devices (and not only partitions).   
> 
> I think that would be the better solution. This can be done
> independently, once we agree on a binding we just have to fix
> of_nvmem_cell_get(). My suggestion would be to have the new binding
> looking like this:
> 
> nvmem-device@10 {
>   ...
>   nvmem-provider;
>   nvmem-cells {
>   compatible = "nvmem-cells";
>   #address-cells = <1>;
>   #size-cells = <1>;
> 
>   nvmem-cell@100 {
>   label = "mac-address";
>   reg = <0x100 0x200>;
>   }
> 
>   ...
>   }
> }
> 
> I would also suggest making the "nvmem-provider" property mandatory
> to indicate that the device provides this capability. Up to now all
> nvmem providers only support this API but I think there might be more
> multi function devices in the future.

If you enforce the name of the child node (here nvmem-cells), you don't
need this extra nvmem-provider property. Am I missing something?

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Boris Brezillon]

On Fri, 3 Mar 2017 11:27:34 +
Srinivas Kandagatla  wrote:

> On 02/03/17 19:50, Alban wrote:
> > Add the binding to expose MTD partitions as nvmem providers.  
> 
> It would be nice to see more description of this patch, explaining the 
> real use case.
> >
> > Signed-off-by: Alban 
> > ---
> >  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 29 
> > ++
> >  1 file changed, 29 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 000..47602f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > @@ -0,0 +1,29 @@
> > += NVMEM in MTD =
> > +
> > +Config data for drivers is often stored in MTD devices. This binding
> > +define how such data can be represented in device tree.
> > +
> > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`  
> We should prefix this property with "mtd" to make it more explicit that 
> this is specific to mtd devices.

MTD is a linux-ism, not sure DT maintainers will like it ;-).

> 
> May be we should put this under "Required Properties" section, marking 
> it as mandatory for mtd nvmem providers.

It's definitely optional. It's really a choice to provide a nvmem cells
under an MTD partition.

> 
> > +property to their node. Data cells can then be defined as child nodes
> > +of the partition as defined in nvmem.txt.
> > +
> > +Example:
> > +
> > +   flash@0 {
> > +   ...
> > +
> > +   partition@2 {
> > +   label = "art";
> > +   reg = <0x7F 0x01>;
> > +   read-only;
> > +
> > +   nvmem-provider;
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   eeprom@1000 {
> > +   label = "wmac-eeprom";
> > +   reg = <0x1000 0x1000>;
> > +   };
> > +   };
> > +   };
> >  

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Boris Brezillon]

On Fri, 3 Mar 2017 11:27:34 +
Srinivas Kandagatla  wrote:

> On 02/03/17 19:50, Alban wrote:
> > Add the binding to expose MTD partitions as nvmem providers.  
> 
> It would be nice to see more description of this patch, explaining the 
> real use case.
> >
> > Signed-off-by: Alban 
> > ---
> >  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 29 
> > ++
> >  1 file changed, 29 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 000..47602f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > @@ -0,0 +1,29 @@
> > += NVMEM in MTD =
> > +
> > +Config data for drivers is often stored in MTD devices. This binding
> > +define how such data can be represented in device tree.
> > +
> > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`  
> We should prefix this property with "mtd" to make it more explicit that 
> this is specific to mtd devices.

MTD is a linux-ism, not sure DT maintainers will like it ;-).

> 
> May be we should put this under "Required Properties" section, marking 
> it as mandatory for mtd nvmem providers.

It's definitely optional. It's really a choice to provide a nvmem cells
under an MTD partition.

> 
> > +property to their node. Data cells can then be defined as child nodes
> > +of the partition as defined in nvmem.txt.
> > +
> > +Example:
> > +
> > +   flash@0 {
> > +   ...
> > +
> > +   partition@2 {
> > +   label = "art";
> > +   reg = <0x7F 0x01>;
> > +   read-only;
> > +
> > +   nvmem-provider;
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   eeprom@1000 {
> > +   label = "wmac-eeprom";
> > +   reg = <0x1000 0x1000>;
> > +   };
> > +   };
> > +   };
> >  

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Alban]

On Fri, 3 Mar 2017 11:27:34 +
Srinivas Kandagatla  wrote:

> On 02/03/17 19:50, Alban wrote:
> > Add the binding to expose MTD partitions as nvmem providers.  
> 
> It would be nice to see more description of this patch, explaining the 
> real use case.

I'll try, writing good documentation is not my strong point :/

> >
> > Signed-off-by: Alban 
> > ---
> >  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 29 
> > ++
> >  1 file changed, 29 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 000..47602f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > @@ -0,0 +1,29 @@
> > += NVMEM in MTD =
> > +
> > +Config data for drivers is often stored in MTD devices. This binding
> > +define how such data can be represented in device tree.
> > +
> > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`  
> We should prefix this property with "mtd" to make it more explicit that 
> this is specific to mtd devices.
> 
> May be we should put this under "Required Properties" section, marking 
> it as mandatory for mtd nvmem providers.

I agree it should be required, but I would not make it MTD specific. In
fact I would suggest making it mandatory for all nvmem providers. That
would be inline with 'interrupt-controller' and all the other properties
used to indicate the capabilities of devices.

Alban


pgpP5HorLH8vR.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Alban]

On Fri, 3 Mar 2017 11:27:34 +
Srinivas Kandagatla  wrote:

> On 02/03/17 19:50, Alban wrote:
> > Add the binding to expose MTD partitions as nvmem providers.  
> 
> It would be nice to see more description of this patch, explaining the 
> real use case.

I'll try, writing good documentation is not my strong point :/

> >
> > Signed-off-by: Alban 
> > ---
> >  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 29 
> > ++
> >  1 file changed, 29 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 000..47602f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > @@ -0,0 +1,29 @@
> > += NVMEM in MTD =
> > +
> > +Config data for drivers is often stored in MTD devices. This binding
> > +define how such data can be represented in device tree.
> > +
> > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`  
> We should prefix this property with "mtd" to make it more explicit that 
> this is specific to mtd devices.
> 
> May be we should put this under "Required Properties" section, marking 
> it as mandatory for mtd nvmem providers.

I agree it should be required, but I would not make it MTD specific. In
fact I would suggest making it mandatory for all nvmem providers. That
would be inline with 'interrupt-controller' and all the other properties
used to indicate the capabilities of devices.

Alban


pgpP5HorLH8vR.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Srinivas Kandagatla]

On 02/03/17 19:50, Alban wrote:

Add the binding to expose MTD partitions as nvmem providers.


It would be nice to see more description of this patch, explaining the 
real use case.


Signed-off-by: Alban 
---
 .../devicetree/bindings/nvmem/mtd-nvmem.txt| 29 ++
 1 file changed, 29 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 000..47602f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
@@ -0,0 +1,29 @@
+= NVMEM in MTD =
+
+Config data for drivers is often stored in MTD devices. This binding
+define how such data can be represented in device tree.
+
+An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
We should prefix this property with "mtd" to make it more explicit that 
this is specific to mtd devices.


May be we should put this under "Required Properties" section, marking 
it as mandatory for mtd nvmem providers.



+property to their node. Data cells can then be defined as child nodes
+of the partition as defined in nvmem.txt.
+
+Example:
+
+   flash@0 {
+   ...
+
+   partition@2 {
+   label = "art";
+   reg = <0x7F 0x01>;
+   read-only;
+
+   nvmem-provider;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   eeprom@1000 {
+   label = "wmac-eeprom";
+   reg = <0x1000 0x1000>;
+   };
+   };
+   };

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Srinivas Kandagatla]

On 02/03/17 19:50, Alban wrote:

Add the binding to expose MTD partitions as nvmem providers.


It would be nice to see more description of this patch, explaining the 
real use case.


Signed-off-by: Alban 
---
 .../devicetree/bindings/nvmem/mtd-nvmem.txt| 29 ++
 1 file changed, 29 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 000..47602f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
@@ -0,0 +1,29 @@
+= NVMEM in MTD =
+
+Config data for drivers is often stored in MTD devices. This binding
+define how such data can be represented in device tree.
+
+An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
We should prefix this property with "mtd" to make it more explicit that 
this is specific to mtd devices.


May be we should put this under "Required Properties" section, marking 
it as mandatory for mtd nvmem providers.



+property to their node. Data cells can then be defined as child nodes
+of the partition as defined in nvmem.txt.
+
+Example:
+
+   flash@0 {
+   ...
+
+   partition@2 {
+   label = "art";
+   reg = <0x7F 0x01>;
+   read-only;
+
+   nvmem-provider;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   eeprom@1000 {
+   label = "wmac-eeprom";
+   reg = <0x1000 0x1000>;
+   };
+   };
+   };

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Boris Brezillon]

On Thu,  2 Mar 2017 20:50:21 +0100
Alban  wrote:

> Add the binding to expose MTD partitions as nvmem providers.

Looks good. Maybe you should take the case you describe in your
cover-letter into account and add an extra layer: add an nvmem sub-node
containing the nvmem cells, so that you can expose nvmem cells directly
under master MTD devices (and not only partitions). 

> 
> Signed-off-by: Alban 
> ---
>  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 29 
> ++
>  1 file changed, 29 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 000..47602f7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> @@ -0,0 +1,29 @@
> += NVMEM in MTD =
> +
> +Config data for drivers is often stored in MTD devices. This binding
> +define how such data can be represented in device tree.
> +
> +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> +property to their node. Data cells can then be defined as child nodes
> +of the partition as defined in nvmem.txt.
> +
> +Example:
> +
> + flash@0 {
> + ...
> +
> + partition@2 {
> + label = "art";
> + reg = <0x7F 0x01>;
> + read-only;
> +
> + nvmem-provider;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + eeprom@1000 {
> + label = "wmac-eeprom";
> + reg = <0x1000 0x1000>;
> + };
> + };
> + };

Re: [PATCH 1/3] doc: bindings: Add bindings documentation for mtd nvmem

[Boris Brezillon]

On Thu,  2 Mar 2017 20:50:21 +0100
Alban  wrote:

> Add the binding to expose MTD partitions as nvmem providers.

Looks good. Maybe you should take the case you describe in your
cover-letter into account and add an extra layer: add an nvmem sub-node
containing the nvmem cells, so that you can expose nvmem cells directly
under master MTD devices (and not only partitions). 

> 
> Signed-off-by: Alban 
> ---
>  .../devicetree/bindings/nvmem/mtd-nvmem.txt| 29 
> ++
>  1 file changed, 29 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 000..47602f7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> @@ -0,0 +1,29 @@
> += NVMEM in MTD =
> +
> +Config data for drivers is often stored in MTD devices. This binding
> +define how such data can be represented in device tree.
> +
> +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> +property to their node. Data cells can then be defined as child nodes
> +of the partition as defined in nvmem.txt.
> +
> +Example:
> +
> + flash@0 {
> + ...
> +
> + partition@2 {
> + label = "art";
> + reg = <0x7F 0x01>;
> + read-only;
> +
> + nvmem-provider;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + eeprom@1000 {
> + label = "wmac-eeprom";
> + reg = <0x1000 0x1000>;
> + };
> + };
> + };