From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
To: "Ahmad Fatoum" <a.fatoum@pengutronix.de>,
"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 14:03:30 +0100 [thread overview]
Message-ID: <53fd9335-baca-fb52-42f1-2af3b08b5f1f@linaro.org> (raw)
In-Reply-To: <d580dd06-8bc8-91c9-262b-f6f276b033c2@pengutronix.de>
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.
--srini
>
>>
>> --srini
>>
>>>
>>>>> I'd thus prefer to not make this specific to the OCOTP as all:
>>>>>
>>>>> * #define NVMEM_CELL_ENCODING_MAC_ADDRESS_IMX /* ... */
>>
>
>
next prev parent reply other threads:[~2021-09-22 13:03 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 [this message]
2021-09-22 13:08 ` Ahmad Fatoum
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=53fd9335-baca-fb52-42f1-2af3b08b5f1f@linaro.org \
--to=srinivas.kandagatla@linaro.org \
--cc=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 \
/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).