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

[Srinivas Kandagatla]

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

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