devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: "Joakim Zhang" <qiangqing.zhang@nxp.com>,
	srinivas.kandagatla@linaro.org, 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 13:34:18 +0200	[thread overview]
Message-ID: <6d91d833-08cc-7ce2-4fe5-3d843a8b31ae@pengutronix.de> (raw)
In-Reply-To: <20210908100257.17833-2-qiangqing.zhang@nxp.com>

Hi,

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.

I'd thus prefer to not make this specific to the OCOTP as all:

  * #define NVMEM_CELL_ENCODING_MAC_ADDRESS_IMX	/* ... */

  * cell-type = <NVMEM_CELL_ENCODING_MAC_ADDRESS_IMX>;

  * and then the decoder is placed into some generic location, e.g.
   drivers/nvmem/encodings.c for Linux

That way, we can reuse this and future encodings across nvmem providers.
It's also more extendable: e.g. big endian fields on EEPROMs. Just stick
the cell-type in, document it in the binding and drivers supporting it
will interpret bytes appropriately.

It's still a good idea to record the type as well as the encoding,
e.g. split the 32 bit encoding constant into two 16-bit values.
One is an enum of possible types (unknown, mac_address, IP address ... etc.)
and one is an enum of the available encodings.

What do you think?

> 
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
>  Documentation/devicetree/bindings/nvmem/nvmem.yaml | 11 +++++++++++
>  include/dt-bindings/nvmem/nvmem.h                  |  8 ++++++++
>  2 files changed, 19 insertions(+)
>  create mode 100644 include/dt-bindings/nvmem/nvmem.h
> 
> diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> index b8dc3d2b6e92..8cf6c7e72b0a 100644
> --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
> @@ -60,6 +60,11 @@ patternProperties:
>              - minimum: 1
>                description:
>                  Size in bit within the address range specified by reg.
> +      cell-type:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        maxItems: 1
> +        description:
> +          Type of nvmem, Use defines in dt-bindings/nvmem/nvmem.h.
>  
>      required:
>        - reg
> @@ -69,6 +74,7 @@ additionalProperties: true
>  examples:
>    - |
>        #include <dt-bindings/gpio/gpio.h>
> +      #include <dt-bindings/nvmem/nvmem.h>
>  
>        qfprom: eeprom@700000 {
>            #address-cells = <1>;
> @@ -98,6 +104,11 @@ examples:
>                reg = <0xc 0x1>;
>                bits = <2 3>;
>            };
> +
> +          mac_addr: mac-addr@90{
> +              reg = <0x90 0x6>;
> +              cell-type = <NVMEM_CELL_TYPE_MAC_ADDRESS>;
> +          };
>        };
>  
>  ...
> diff --git a/include/dt-bindings/nvmem/nvmem.h b/include/dt-bindings/nvmem/nvmem.h
> new file mode 100644
> index 000000000000..eed0478f6bfd
> --- /dev/null
> +++ b/include/dt-bindings/nvmem/nvmem.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef __DT_NVMMEM_H
> +#define __DT_NVMMEM_H
> +
> +#define NVMEM_CELL_TYPE_UNKNOWN		0
> +#define NVMEM_CELL_TYPE_MAC_ADDRESS	1
> +
> +#endif /* __DT_NVMMEM_H */
> 


-- 
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-22 11:34 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 [this message]
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
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=6d91d833-08cc-7ce2-4fe5-3d843a8b31ae@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).