Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data" property

Hi Joakim,


On 06/09/2021 09:58, Joakim Zhang wrote:

Hi Srinivas,

quoted

-----Original Message-----
From: Srinivas Kandagatla <redacted>
Sent: 2021年9月3日 20:38
To: Joakim Zhang <redacted>; Rob Herring
[off-list ref]
Cc: shawnguo@kernel.org; kernel@pengutronix.de; dl-linux-imx
[off-list ref]; devicetree@vger.kernel.org;
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
property

Hi Joakim,

On 18/08/2021 08:54, Joakim Zhang wrote:

quoted

quoted

-----Original Message-----
From: Rob Herring <robh@kernel.org>
Sent: 2021年8月18日 3:58
To: Srinivas Kandagatla <redacted>
Cc: Joakim Zhang <redacted>; shawnguo@kernel.org;
kernel@pengutronix.de; dl-linux-imx [off-list ref];
devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
property

On Wed, Aug 11, 2021 at 11:16:49AM +0100, Srinivas Kandagatla wrote:

quoted

On 10/08/2021 08:35, Joakim Zhang wrote:

quoted

Introduce "reverse-data" property for nvmem provider to reverse buffer.

Signed-off-by: Joakim Zhang <redacted>
---
    Documentation/devicetree/bindings/nvmem/nvmem.yaml | 5 +++++
    1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml

b/Documentation/devicetree/bindings/nvmem/nvmem.yaml
index b8dc3d2b6e92..bc745083fc64 100644

--- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml
+++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml

@@ -61,6 +61,11 @@ patternProperties:
                  description:
                    Size in bit within the address range specified by

reg.

quoted

quoted

quoted

quoted

+      reverse-data:
+        $ref: /schemas/types.yaml#/definitions/flag
+        description:
+          Reverse the data that read from the storage device.
+

This new property is only going to solve one of the reverse order
issue here.
If I remember correctly we have mac-address stored in various formats ex:
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

I think its right time to consider adding compatibles to nvmem-cells
to be able to specify encoding information and handle post processing.

Yes. Trying to handle this with never ending new properties will end
up with a mess. At some point, you just need code to parse the data.

Thanks, Rob.

Hi Srinivas,

Firstly Sorry for taking so long to reply as I was on vacation.

quoted

Do you plan to implement it?

No, Am not planning to do this. But am happy to walk-thru the ideas that I
have.

quoted

Or need me follow up? If yes, please input your insights to point me how to

work for it.

Do we have some kind of meta data/information in nvmem memory to indicate
the storage encoding?

No, none of these.

quoted

Am I correct to say that this is only issue with mac-address nvmem cell?

I think, yes.
  

quoted

Irrespective of where this encoding info comes from we have 2 options.

Option 1: Add callback to handle mac-address post-processing with in the
provider driver.

Sorry, I am not very familiar with nvmem framework, what's this "callback" mean?
Do you also want to introduce a common callback for different vendor drivers to
work for mac-address post-processing? Extend the " struct nvmem_config"?

quoted

Pros:
- It can deal with vendor specific non-standard encodings, and code is mostly
with-in vendor specific nvmem provider driver and bindings.
- will keep nvmem core simple w.r.t handling data.

Cons:
- provider driver implement callback and new bindings.
- might need to add a nvmem-cell-type binding to be able differentiate the cell
types and handle post-processing.

Ahhh, I am not quite understand how to implement for it? Could you please give some
draft hints?

If we extend the struct nvmem_config, add a callback to handle mac address, how can we
determine which is the mac-address device node? There is no device node info from .reg_read
callback.

I have pushed some nvmem core patches which are just compile tested to https://git.kernel.org/pub/scm/linux/kernel/git/srini/nvmem.git/log/?h=topic/post-processing

This should provide the callback hook I was talking about.

Can you take a look at them and let me know if it works for you.

I have also added some test changes to imx provider driver as well, which you might have to take a closer look to get it working.

You need to look at adding/changing two things:

1. setting reverse_mac_address flag in imx driver.
	Does IMX always has mac-address reversed? if yes then we do not need any new bindings for imx nvmem provider, if no we might need to add some kind of flag to indicate this.

2. In imx devicetree for mac-address nvmem cell make sure you add

cell-type = <NVMEM_CELL_TYPE_MAC_ADDRESS>;

quoted

Option 2: nvmem core handles the post processing.

Pros:
- provider driver does not need to implement callbacks

Cons:
- We have to find a way to define vendor specific non-standard encoding
information in generic bindings which is going to be a challenge and high chance
of ending up in to much of clutter in generic bindings.

Finally, The way I look at this is that once we start adding post-processing in
nvmem core then we might endup with code that will not be really used for
most of the usecases and might endup with cases that might not be possible to
handle in the core.


Does Option 1 work for you?

Yes, I also prefer to implement it in specific driver, as you mention above, these code are for
very rarely use cases.

If we chose Option 1, I want to implement it totally in specific driver(imx-ocotp.c), and I have a draft,
could it be acdeptable?

Yes, this is the direction, however we need a proper callback to do this. And offset information is still comes from Device tree.


Have a look at the patches pushed into topic/post-processing branch.

--srini