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