Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1593972 > unrolled thread

[PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem Alban <albeu@free.fr> - 2017-03-07 09:30 +0100
    Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for  mtd nvmem Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-03-07 22:20 +0100
      Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for  mtd nvmem Alban <albeu@free.fr> - 2017-03-08 16:50 +0100
        Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for  mtd nvmem Boris Brezillon <boris.brezillon@free-electrons.com> - 2017-03-08 17:40 +0100
    Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd  nvmem Marek Vasut <marek.vasut@gmail.com> - 2017-03-10 04:20 +0100
      Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem Moritz Fischer <moritz.fischer@ettus.com> - 2017-03-10 05:10 +0100
        Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd  nvmem Marek Vasut <marek.vasut@gmail.com> - 2017-03-10 06:00 +0100
          Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd  nvmem Maxime Ripard <maxime.ripard@free-electrons.com> - 2017-03-10 07:40 +0100
            Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd  nvmem Marek Vasut <marek.vasut@gmail.com> - 2017-03-10 08:30 +0100

#1593972 — [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

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 <albeu@free.fr>
---
Changelog:
v2: * Added a "Required properties" section with the nvmem-provider
      property
---
 .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 33 ++++++++++++++++++++++
 1 file changed, 33 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..8ed25e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
@@ -0,0 +1,33 @@
+= NVMEM in MTD =
+
+Config data for drivers, like MAC addresses, is often stored in MTD.
+This binding define how such data storage 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.
+
+Required properties:
+nvmem-provider:	Indicate that the device should be registered as
+		NVMEM provider
+
+Example:
+
+	flash@0 {
+		...
+
+		partition@2 {
+			label = "art";
+			reg = <0x7F0000 0x010000>;
+			read-only;
+
+			nvmem-provider;
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			eeprom@1000 {
+				label = "wmac-eeprom";
+				reg = <0x1000 0x1000>;
+			};
+		};
+	};
-- 
2.7.4

[toc] | [next] | [standalone]

#1594657 — Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

On Tue,  7 Mar 2017 09:26:03 +0100
Alban <albeu@free.fr> 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 <albeu@free.fr>
> ---
> Changelog:
> v2: * Added a "Required properties" section with the nvmem-provider
>       property
> ---
>  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 33 ++++++++++++++++++++++
>  1 file changed, 33 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..8ed25e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> @@ -0,0 +1,33 @@
> += NVMEM in MTD =
> +
> +Config data for drivers, like MAC addresses, is often stored in MTD.
> +This binding define how such data storage can be represented in device tree.
> +
> +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> +property to their node.

If everyone agrees that this is actually needed, then it should
definitely go in the nvmem binding doc, and we should patch all nvmem
providers to define this property (even if we keep supporting nodes
that are not defining it). I'm not fully convinced yet, but I might be
wrong.

I also think we should take the "nvmem under flash node without partitions"
into account now, or at least have a clear plan on how we want to represent
it.

Something like that?

	flash {
		partitions {
			part@X {
				nvmem {
					#address-cells = <1>;
					#size-cells = <1>;

					cell@Y {
					};
				};
			};
		};

		nvmem {
			#address-cells = <1>;
			#size-cells = <1>;

			cell@X {
			};
		};
	};

Note that patching nvmem core to support the subnode case should be
pretty easy (see below).

--->8---
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 408b521ee520..507c6190505b 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -465,7 +465,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
        nvmem->priv = config->priv;
        nvmem->reg_read = config->reg_read;
        nvmem->reg_write = config->reg_write;
-       np = config->dev->of_node;
+       np = config->of_node ? : config->dev->of_node;
        nvmem->dev.of_node = np;
        dev_set_name(&nvmem->dev, "%s%d",
                     config->name ? : "nvmem", config->id);
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index cd93416d762e..ec2f5116d62d 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -21,6 +21,7 @@ typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset,
 
 struct nvmem_config {
        struct device           *dev;
+       struct device_node      *of_node;
        const char              *name;
        int                     id;
        struct module           *owner;

[toc] | [prev] | [next] | [standalone]

#1595305 — Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

[Multipart message — attachments visible in raw view] — view raw

On Tue, 7 Mar 2017 22:01:07 +0100
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:

> On Tue,  7 Mar 2017 09:26:03 +0100
> Alban <albeu@free.fr> 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 <albeu@free.fr>
> > ---
> > Changelog:
> > v2: * Added a "Required properties" section with the nvmem-provider
> >       property
> > ---
> >  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 33 ++++++++++++++++++++++
> >  1 file changed, 33 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..8ed25e6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > @@ -0,0 +1,33 @@
> > += NVMEM in MTD =
> > +
> > +Config data for drivers, like MAC addresses, is often stored in MTD.
> > +This binding define how such data storage can be represented in device tree.
> > +
> > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> > +property to their node.  
> 
> If everyone agrees that this is actually needed, then it should
> definitely go in the nvmem binding doc, and we should patch all nvmem
> providers to define this property (even if we keep supporting nodes
> that are not defining it). I'm not fully convinced yet, but I might be
> wrong.

I really like to hear what the DT people think about this.

> I also think we should take the "nvmem under flash node without partitions"
> into account now, or at least have a clear plan on how we want to represent
> it.
> 
> Something like that?

Yes, but with the following extras:

> 	flash {
                nvmem-provider;
> 		partitions {
> 			part@X {
> 				nvmem {
  					compatible = "nvmem-cells";
> 					#address-cells = <1>;
> 					#size-cells = <1>;
> 
> 					cell@Y {
> 					};
> 				};
> 			};
> 		};
> 
> 		nvmem {
  			compatible = "nvmem-cells";
> 			#address-cells = <1>;
> 			#size-cells = <1>;
> 
> 			cell@X {
> 			};
> 		};
> 	};
>
> Note that patching nvmem core to support the subnode case should be
> pretty easy (see below).

This shouldn't be needed as nothing would change for the NVMEM devices,
what could be added is a check for the "nvmem-provider" property.
To support the proposed binding we would only need a minor change to
of_nvmem_cell_get():

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 408b521ee520..6231ea27c9f4 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -444,6 +444,10 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
        if (!config->dev)
                return ERR_PTR(-EINVAL);

+       if (config->dev->of_node &&
+           !of_property_read_bool(config->dev->of_node, "nvmem-provider"))
+               return ERR_PTR(-ENODEV);
+
        nvmem = kzalloc(sizeof(*nvmem), GFP_KERNEL);
        if (!nvmem)
                return ERR_PTR(-ENOMEM);
@@ -777,6 +781,15 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
        if (!nvmem_np)
                return ERR_PTR(-EINVAL);

+       /* handle the new cell binding */
+       if (of_device_is_compatible(nvmem_np, "nvmem-cells")) {
+               nvmem_np = of_get_next_parent(cell_np);
+               if (!nvmem_np)
+                       return ERR_PTR(-EINVAL);
+               if (!of_property_read_bool(nvmem_np, "nvmem-provider"))
+                       return ERR_PTR(-ENODEV);
+       }
+
        nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
        if (IS_ERR(nvmem))
                return ERR_CAST(nvmem);


> --->8---  
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 408b521ee520..507c6190505b 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -465,7 +465,7 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
>         nvmem->priv = config->priv;
>         nvmem->reg_read = config->reg_read;
>         nvmem->reg_write = config->reg_write;
> -       np = config->dev->of_node;
> +       np = config->of_node ? : config->dev->of_node;
>         nvmem->dev.of_node = np;
>         dev_set_name(&nvmem->dev, "%s%d",
>                      config->name ? : "nvmem", config->id);
> diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
> index cd93416d762e..ec2f5116d62d 100644
> --- a/include/linux/nvmem-provider.h
> +++ b/include/linux/nvmem-provider.h
> @@ -21,6 +21,7 @@ typedef int (*nvmem_reg_write_t)(void *priv, unsigned int offset,
>  
>  struct nvmem_config {
>         struct device           *dev;
> +       struct device_node      *of_node;
>         const char              *name;
>         int                     id;
>         struct module           *owner;

[toc] | [prev] | [next] | [standalone]

#1595366 — Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

Hi Alban,

On Wed, 8 Mar 2017 16:20:01 +0100
Alban <albeu@free.fr> wrote:

> On Tue, 7 Mar 2017 22:01:07 +0100
> Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> 
> > On Tue,  7 Mar 2017 09:26:03 +0100
> > Alban <albeu@free.fr> 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 <albeu@free.fr>
> > > ---
> > > Changelog:
> > > v2: * Added a "Required properties" section with the nvmem-provider
> > >       property
> > > ---
> > >  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 33 ++++++++++++++++++++++
> > >  1 file changed, 33 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..8ed25e6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> > > @@ -0,0 +1,33 @@
> > > += NVMEM in MTD =
> > > +
> > > +Config data for drivers, like MAC addresses, is often stored in MTD.
> > > +This binding define how such data storage can be represented in device tree.
> > > +
> > > +An MTD can be defined as an NVMEM provider by adding the `nvmem-provider`
> > > +property to their node.    
> > 
> > If everyone agrees that this is actually needed, then it should
> > definitely go in the nvmem binding doc, and we should patch all nvmem
> > providers to define this property (even if we keep supporting nodes
> > that are not defining it). I'm not fully convinced yet, but I might be
> > wrong.  
> 
> I really like to hear what the DT people think about this.

That was the plan.

> 
> > I also think we should take the "nvmem under flash node without partitions"
> > into account now, or at least have a clear plan on how we want to represent
> > it.
> > 
> > Something like that?  
> 
> Yes, but with the following extras:
> 
> > 	flash {  
>                 nvmem-provider;
> > 		partitions {
> > 			part@X {
> > 				nvmem {  
>   					compatible = "nvmem-cells";
> > 					#address-cells = <1>;
> > 					#size-cells = <1>;
> > 
> > 					cell@Y {
> > 					};
> > 				};
> > 			};
> > 		};
> > 
> > 		nvmem {  
>   			compatible = "nvmem-cells";
> > 			#address-cells = <1>;
> > 			#size-cells = <1>;
> > 
> > 			cell@X {
> > 			};
> > 		};
> > 	};
> >
> > Note that patching nvmem core to support the subnode case should be
> > pretty easy (see below).  
> 
> This shouldn't be needed as nothing would change for the NVMEM devices,
> what could be added is a check for the "nvmem-provider" property.
> To support the proposed binding we would only need a minor change to
> of_nvmem_cell_get():
> 
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 408b521ee520..6231ea27c9f4 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -444,6 +444,10 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config)
>         if (!config->dev)
>                 return ERR_PTR(-EINVAL);
> 
> +       if (config->dev->of_node &&
> +           !of_property_read_bool(config->dev->of_node, "nvmem-provider"))
> +               return ERR_PTR(-ENODEV);
> +
>         nvmem = kzalloc(sizeof(*nvmem), GFP_KERNEL);
>         if (!nvmem)
>                 return ERR_PTR(-ENOMEM);
> @@ -777,6 +781,15 @@ struct nvmem_cell *of_nvmem_cell_get(struct device_node *np,
>         if (!nvmem_np)
>                 return ERR_PTR(-EINVAL);
> 
> +       /* handle the new cell binding */
> +       if (of_device_is_compatible(nvmem_np, "nvmem-cells")) {
> +               nvmem_np = of_get_next_parent(cell_np);
> +               if (!nvmem_np)
> +                       return ERR_PTR(-EINVAL);
> +               if (!of_property_read_bool(nvmem_np, "nvmem-provider"))
> +                       return ERR_PTR(-ENODEV);
> +       }
> +
>         nvmem = __nvmem_device_get(nvmem_np, NULL, NULL);
>         if (IS_ERR(nvmem))
>                 return ERR_CAST(nvmem);
> 

Yep, works too. Let's wait for a DT review, before taking a decision.

Thanks,

Boris

[toc] | [prev] | [next] | [standalone]

#1596590 — Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

On 03/07/2017 09:26 AM, Alban 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 <albeu@free.fr>
> ---
> Changelog:
> v2: * Added a "Required properties" section with the nvmem-provider
>       property
> ---
>  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 33 ++++++++++++++++++++++
>  1 file changed, 33 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..8ed25e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> @@ -0,0 +1,33 @@
> += NVMEM in MTD =
> +
> +Config data for drivers, like MAC addresses, is often stored in MTD.
> +This binding define how such data storage 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.

Why don't we just read the data from MTD and be done with it ? What's
the benefit of complicating things by using nvmem ?

> +Required properties:
> +nvmem-provider:	Indicate that the device should be registered as
> +		NVMEM provider
> +
> +Example:
> +
> +	flash@0 {
> +		...
> +
> +		partition@2 {
> +			label = "art";
> +			reg = <0x7F0000 0x010000>;
> +			read-only;
> +
> +			nvmem-provider;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +
> +			eeprom@1000 {
> +				label = "wmac-eeprom";
> +				reg = <0x1000 0x1000>;
> +			};
> +		};
> +	};
> 


-- 
Best regards,
Marek Vasut

[toc] | [prev] | [next] | [standalone]

#1596604

On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> On 03/07/2017 09:26 AM, Alban 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 <albeu@free.fr>
>> ---
>> Changelog:
>> v2: * Added a "Required properties" section with the nvmem-provider
>>       property
>> ---
>>  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 33 ++++++++++++++++++++++
>>  1 file changed, 33 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..8ed25e6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
>> @@ -0,0 +1,33 @@
>> += NVMEM in MTD =
>> +
>> +Config data for drivers, like MAC addresses, is often stored in MTD.
>> +This binding define how such data storage 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.
>
> Why don't we just read the data from MTD and be done with it ? What's
> the benefit of complicating things by using nvmem ?

Well because usually stuff like MAC addresses etc are stored in eeproms.
This gives a nice abstraction with making them both look like nvmem (that was my
reasoning back then when I submitted a patch to support the OTP part in a
SPI NOR part.

>> +Required properties:
>> +nvmem-provider:      Indicate that the device should be registered as
>> +             NVMEM provider
>> +
>> +Example:
>> +
>> +     flash@0 {
>> +             ...
>> +
>> +             partition@2 {
>> +                     label = "art";
>> +                     reg = <0x7F0000 0x010000>;
>> +                     read-only;
>> +
>> +                     nvmem-provider;
>> +                     #address-cells = <1>;
>> +                     #size-cells = <1>;
>> +
>> +                     eeprom@1000 {
>> +                             label = "wmac-eeprom";
>> +                             reg = <0x1000 0x1000>;
>> +                     };
>> +             };
>> +     };
>>
>
>
> --
> Best regards,
> Marek Vasut

Cheers,
Moritz

[toc] | [prev] | [next] | [standalone]

#1596625 — Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

On 03/10/2017 05:06 AM, Moritz Fischer wrote:
> On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 03/07/2017 09:26 AM, Alban 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 <albeu@free.fr>
>>> ---
>>> Changelog:
>>> v2: * Added a "Required properties" section with the nvmem-provider
>>>       property
>>> ---
>>>  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 33 ++++++++++++++++++++++
>>>  1 file changed, 33 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..8ed25e6
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
>>> @@ -0,0 +1,33 @@
>>> += NVMEM in MTD =
>>> +
>>> +Config data for drivers, like MAC addresses, is often stored in MTD.
>>> +This binding define how such data storage 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.
>>
>> Why don't we just read the data from MTD and be done with it ? What's
>> the benefit of complicating things by using nvmem ?
> 
> Well because usually stuff like MAC addresses etc are stored in eeproms.

But eeproms are already supported, see drivers/misc/ .

> This gives a nice abstraction with making them both look like nvmem (that was my
> reasoning back then when I submitted a patch to support the OTP part in a
> SPI NOR part.

Hm, I am confused here, we're mixing SPI NOR, EEPROMs and OTP devices here.

-- 
Best regards,
Marek Vasut

[toc] | [prev] | [next] | [standalone]

#1596685 — Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

[Multipart message — attachments visible in raw view] — view raw

Hi Marek,

On Fri, Mar 10, 2017 at 05:52:36AM +0100, Marek Vasut wrote:
> On 03/10/2017 05:06 AM, Moritz Fischer wrote:
> > On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> On 03/07/2017 09:26 AM, Alban 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 <albeu@free.fr>
> >>> ---
> >>> Changelog:
> >>> v2: * Added a "Required properties" section with the nvmem-provider
> >>>       property
> >>> ---
> >>>  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 33 ++++++++++++++++++++++
> >>>  1 file changed, 33 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..8ed25e6
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
> >>> @@ -0,0 +1,33 @@
> >>> += NVMEM in MTD =
> >>> +
> >>> +Config data for drivers, like MAC addresses, is often stored in MTD.
> >>> +This binding define how such data storage 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.
> >>
> >> Why don't we just read the data from MTD and be done with it ? What's
> >> the benefit of complicating things by using nvmem ?
> > 
> > Well because usually stuff like MAC addresses etc are stored in eeproms.
> 
> But eeproms are already supported, see drivers/misc/ .

This the old, free for all, way to support eeproms. We have a proper
framework for them now, and it's called nvmem.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1596694 — Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

On 03/10/2017 07:38 AM, Maxime Ripard wrote:
> Hi Marek,
> 
> On Fri, Mar 10, 2017 at 05:52:36AM +0100, Marek Vasut wrote:
>> On 03/10/2017 05:06 AM, Moritz Fischer wrote:
>>> On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>>>> On 03/07/2017 09:26 AM, Alban 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 <albeu@free.fr>
>>>>> ---
>>>>> Changelog:
>>>>> v2: * Added a "Required properties" section with the nvmem-provider
>>>>>       property
>>>>> ---
>>>>>  .../devicetree/bindings/nvmem/mtd-nvmem.txt        | 33 ++++++++++++++++++++++
>>>>>  1 file changed, 33 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..8ed25e6
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/nvmem/mtd-nvmem.txt
>>>>> @@ -0,0 +1,33 @@
>>>>> += NVMEM in MTD =
>>>>> +
>>>>> +Config data for drivers, like MAC addresses, is often stored in MTD.
>>>>> +This binding define how such data storage 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.
>>>>
>>>> Why don't we just read the data from MTD and be done with it ? What's
>>>> the benefit of complicating things by using nvmem ?
>>>
>>> Well because usually stuff like MAC addresses etc are stored in eeproms.
>>
>> But eeproms are already supported, see drivers/misc/ .
> 
> This the old, free for all, way to support eeproms. We have a proper
> framework for them now, and it's called nvmem.

Ha, so that's why this patchset, I see. Thanks for clarifying.

-- 
Best regards,
Marek Vasut

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web