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