linux-kernel - Re: [PATCH 1/6] dt-bindings: nvmem: add cell-type to nvmem cells

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] [day] [month] [year] [list]

Date:   Thu, 23 Sep 2021 22:02:51 +0200
From:   Ahmad Fatoum <a.fatoum@...gutronix.de>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Joakim Zhang <qiangqing.zhang@....com>, robh+dt@...nel.org,
        shawnguo@...nel.org,
        Jan Lübbe <jlu@...gutronix.de>
Cc:     devicetree@...r.kernel.org, linux-imx@....com,
        kernel@...gutronix.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] dt-bindings: nvmem: add cell-type to nvmem cells

Hello Srini,

On 22.09.21 15:23, Srinivas Kandagatla wrote:
> On 22/09/2021 14:08, Ahmad Fatoum wrote:
>> On 22.09.21 15:03, Srinivas Kandagatla wrote:
>>> User A and B should mention about this encoding information in there NVMEM provider bindings.
>>>
>>> Based on that specific post-processing should be selected.
>>
>> So instead of just compatible = "atmel,at24c16"; there will be
>>
>>    compatible = "user-A,my-eeprom", "atmel,at24c16";
>>
>> and
>>
>>    compatible = "user-B,my-eeprom", "atmel,at24c16";
> 
> It will depend how you specify encoding information.

I would specify them in cell-type, which you disagree with, thus
I am asking:

Is using a stock EEPROM with a non-canonical format for e.g. a MAC
address something that you think should be supported with NVMEM?

> The issue with making this encoding information generic is that the combinations are endless and nvmem core bindings is definitely not the right place for this.

Add a separate file and include it from the core file?

> ex:
> If I remember correctly we have mac-address stored in various formats:
> from old thread I can see
> 
> Type 1: Octets in ASCII without delimiters. (Swapped/non-Swapped)
> 
> Type 2: Octets in ASCII with delimiters like (":", ",", ".", "-"... so on) (Swapped/non-Swapped)
> 
> Type 3: Is the one which stores mac address in Type1/2 but this has to
> be incremented to be used on other instances of eth.
> 
> Type 4: Octets as bytes/u8, swapped/non-swapped
> 
> This list can be endless and its not just the cell-type property you have to deal with, new properties keep popping up.

Yes, an extendible interface will likely encourage people to extend it.

Cheers,
Ahmad

> --srini
> 
> 
> 
>>
>> and they each need to patch the at24 driver to call one of the
>> common library functions?
>>
>>>
>>> --srini
>>>>
>>>
>>>>>
>>>>> --srini
>>>>>
>>>>>>
>>>>>>>> I'd thus prefer to not make this specific to the OCOTP as all:
>>>>>>>>
>>>>>>>>       * #define NVMEM_CELL_ENCODING_MAC_ADDRESS_IMX    /* ... */
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |