From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
	"Joakim Zhang" <qiangqing.zhang@nxp.com>,
	robh+dt@kernel.org, shawnguo@kernel.org,
	"Jan Lübbe" <jlu@pengutronix.de>
Cc: devicetree@vger.kernel.org, linux-imx@nxp.com,
	kernel@pengutronix.de, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] dt-bindings: nvmem: add cell-type to nvmem cells
Date: Wed, 22 Sep 2021 15:08:00 +0200	[thread overview]
Message-ID: <89b4a2d6-1966-7fcb-d476-f69e88293ea0@pengutronix.de> (raw)
In-Reply-To: <53fd9335-baca-fb52-42f1-2af3b08b5f1f@linaro.org>
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@linaro.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.
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";
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    /* ... */
>>>
>>
>>
> 
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
next prev parent reply	other threads:[~2021-09-22 13:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-08 10:02 [PATCH 0/6] nvmem: add "cell-type" property to support mac-address Joakim Zhang
2021-09-08 10:02 ` [PATCH 1/6] dt-bindings: nvmem: add cell-type to nvmem cells Joakim Zhang
2021-09-22 11:34   ` Ahmad Fatoum
2021-09-22 12:23     ` Srinivas Kandagatla
2021-09-22 12:31       ` Ahmad Fatoum
2021-09-22 12:49         ` Srinivas Kandagatla
2021-09-22 12:58           ` Ahmad Fatoum
2021-09-22 13:03             ` Srinivas Kandagatla
2021-09-22 13:08               ` Ahmad Fatoum [this message]
2021-09-22 13:23                 ` Srinivas Kandagatla
2021-09-23 20:02                   ` Ahmad Fatoum
2021-09-23  2:51     ` Joakim Zhang
2021-09-08 10:02 ` [PATCH 2/6] nvmem: core: parse nvmem cell-type from device tree Joakim Zhang
2021-09-22 11:36   ` Ahmad Fatoum
2021-09-08 10:02 ` [PATCH 3/6] nvmem: core: add nvmem cell post processing callback Joakim Zhang
2021-09-22 11:37   ` Ahmad Fatoum
2021-09-23  2:52     ` Joakim Zhang
2021-09-08 10:02 ` [PATCH 4/6] nvmem: imx-ocotp: add support for post porcessing Joakim Zhang
2021-09-08 10:02 ` [PATCH 5/6] arm64: dts: imx8mm: add "cell-type" property for mac-address Joakim Zhang
2021-09-22 11:40   ` Ahmad Fatoum
2021-09-23  2:52     ` Joakim Zhang
2021-09-08 10:02 ` [PATCH 6/6] arm64: dts: imx8m: remove unused "nvmem_macaddr_swap" property for FEC Joakim Zhang
2021-09-22 11:40   ` Ahmad Fatoum
2021-09-22 10:46 ` [PATCH 0/6] nvmem: add "cell-type" property to support mac-address Joakim Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox
  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):
  git send-email \
    --in-reply-to=89b4a2d6-1966-7fcb-d476-f69e88293ea0@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=devicetree@vger.kernel.org \
    --cc=jlu@pengutronix.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qiangqing.zhang@nxp.com \
    --cc=robh+dt@kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=srinivas.kandagatla@linaro.org \
    /path/to/YOUR_REPLY
  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
  Be sure your reply has a Subject: header at the top and a blank line
  before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).