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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <18c0d9c0-bee8-41fa-8fe8-26a0ceda1ecd@linaro.org>
Date:   Wed, 22 Sep 2021 14:23:34 +0100
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Ahmad Fatoum <a.fatoum@...gutronix.de>,
        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



On 22/09/2021 14:08, Ahmad Fatoum wrote:
> Hi,
> 
> On 22.09.21 15:03, Srinivas Kandagatla wrote:
>>
>>
>> On 22/09/2021 13:58, Ahmad Fatoum wrote:
>>> Hi Srini,
>>>
>>> On 22.09.21 14:49, Srinivas Kandagatla wrote:
>>>>
>>>>
>>>> On 22/09/2021 13:31, Ahmad Fatoum wrote:
>>>>>>>
>>>>>>> On 08.09.21 12:02, Joakim Zhang wrote:
>>>>>>>> From: Srinivas Kandagatla<srinivas.kandagatla@...aro.org>
>>>>>>>>
>>>>>>>> Some of the nvmem providers encode data for certain type of nvmem cell,
>>>>>>>> example mac-address is stored in ascii or with delimiter or in reverse order.
>>>>>>>>
>>>>>>>> This is much specific to vendor, so having a cell-type would allow nvmem
>>>>>>>> provider drivers to post-process this before using it.
>>>>>>> I don't agree with this assessment. Users of the OCOTP so far
>>>>>>> used this specific encoding. Bootloaders decode the OCOTP this way, but this
>>>>>>> encoding isn't really an inherent attribute of the OCOTP. A new NXP SoC
>>>>>>> with a different OTP IP will likely use the same format. Users may even
>>>>>>> use the same format on an EEPROM to populate a second off-SoC interface, .. etc.
>>>>>>>
>>>>>> That is okay.
>>>>> How would you go about using this same format on an EEPROM?
>>>>
>>>> Am guessing that by the time there are more users for such formats, those post-processing functions should be converted into some library functions.
>>>
>>> User A wants to reverse bytes in MAC address. User B stores it in ASCII.
>>> Both use the exact same EEPROM. How could this ever work when the
>>> encoding decision is left to the EEPROM driver?
>>
>> 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.

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.

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.


--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    /* ... */
>>>>
>>>
>>>
>>
> 
>