All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 23 Sep 2021 22:02:51 +0200	[thread overview]
Message-ID: <7aa60518-1045-5773-5b24-9f386cac1b8e@pengutronix.de> (raw)
In-Reply-To: <18c0d9c0-bee8-41fa-8fe8-26a0ceda1ecd@linaro.org>

Hello Srini,

On 22.09.21 15:23, Srinivas Kandagatla wrote:
> On 22/09/2021 14:08, Ahmad Fatoum wrote:
>> On 22.09.21 15:03, Srinivas Kandagatla wrote:
>>> 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.

I would specify them in cell-type, which you disagree with, thus
I am asking:

Is using a stock EEPROM with a non-canonical format for e.g. a MAC
address something that you think should be supported with NVMEM?

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

Add a separate file and include it from the core file?

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

Yes, an extendible interface will likely encourage people to extend it.

Cheers,
Ahmad

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


-- 
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 |

  reply	other threads:[~2021-09-23 20:02 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
2021-09-22 13:23                 ` Srinivas Kandagatla
2021-09-23 20:02                   ` Ahmad Fatoum [this message]
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=7aa60518-1045-5773-5b24-9f386cac1b8e@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.