On 22/09/2021 14:08, Ahmad Fatoum wrote:

Hi,

On 22.09.21 15:03, Srinivas Kandagatla wrote:

quoted

On 22/09/2021 13:58, Ahmad Fatoum wrote:

quoted

Hi Srini,

On 22.09.21 14:49, Srinivas Kandagatla wrote:

quoted

On 22/09/2021 13:31, Ahmad Fatoum wrote:

quoted

quoted

quoted

On 08.09.21 12:02, Joakim Zhang wrote:

quoted

From: Srinivas Kandagatla<redacted>

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?

quoted

--srini

quoted

quoted

quoted

--srini

quoted

quoted

quoted

I'd thus prefer to not make this specific to the OCOTP as all:

      * #define NVMEM_CELL_ENCODING_MAC_ADDRESS_IMX    /* ... */