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: <53fd9335-baca-fb52-42f1-2af3b08b5f1f@linaro.org>
Date:   Wed, 22 Sep 2021 14:03:30 +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 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.

--srini
> 

>>
>> --srini
>>
>>>
>>>>> I'd thus prefer to not make this specific to the OCOTP as all:
>>>>>
>>>>>      * #define NVMEM_CELL_ENCODING_MAC_ADDRESS_IMX    /* ... */
>>
> 
>