lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 22 Sep 2021 14:03:30 +0100 From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org> To: Ahmad Fatoum <a.fatoum@...gutronix.de>, Joakim Zhang <qiangqing.zhang@....com>, robh+dt@...nel.org, shawnguo@...nel.org, Jan Lübbe <jlu@...gutronix.de> Cc: devicetree@...r.kernel.org, linux-imx@....com, kernel@...gutronix.de, linux-kernel@...r.kernel.org Subject: Re: [PATCH 1/6] dt-bindings: nvmem: add cell-type to nvmem cells 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@...aro.org> >>>>>> >>>>>> 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 /* ... */ >> > >
Powered by blists - more mailing lists