lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAtXAHc34fG_TZbHrRp=oB_e=-o18zDesT73YSEx1Tr5ZE0oSw@mail.gmail.com>
Date:   Thu, 9 Mar 2017 20:06:09 -0800
From:   Moritz Fischer <moritz.fischer@...us.com>
To:     Marek Vasut <marek.vasut@...il.com>
Cc:     Alban <albeu@...e.fr>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Richard Weinberger <richard@....at>,
        Cyrille Pitchen <cyrille.pitchen@...el.com>,
        Devicetree List <devicetree@...r.kernel.org>,
        linux-mtd@...ts.infradead.org
Subject: Re: [PATCH v2 1/2] doc: bindings: Add bindings documentation for mtd nvmem

On Thu, Mar 9, 2017 at 7:17 PM, Marek Vasut <marek.vasut@...il.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@...e.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@...0 {
>> +                             label = "wmac-eeprom";
>> +                             reg = <0x1000 0x1000>;
>> +                     };
>> +             };
>> +     };
>>
>
>
> --
> Best regards,
> Marek Vasut

Cheers,
Moritz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ