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

[Marek Vasut]

On 03/10/2017 05:06 AM, Moritz Fischer wrote:
> On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut <marek.vasut at 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 at 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