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

[Ahmad Fatoum]

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@xxxxxxxxxx>
>>>>>
>>>>> 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?

> 
> --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 |