[PATCH V1 0/4] nvmem: introduce "reverse-data" property

[PATCH V1 0/4] nvmem: introduce "reverse-data" property

[Joakim Zhang]

This patch adds "reverse-data" property at nvmem provider to reverse
buffer if nvmem consumer needed.

Please refer to [1] which reverse data at consumer side, but already
rejected by Rob Herring.

[1] https://lkml.org/lkml/2021/4/9/352

Joakim Zhang (4):
  bindings: nvmem: introduce "reverse-data" property
  nvmem: core: introduce "reverse-data" property to reverse buffer
  arm64: dts: imx8m: add "reverse-data" property for MAC ocopt
  arm64: dts: imx8m: remove unused "nvmem_macaddr_swap" property for FEC

 .../devicetree/bindings/nvmem/nvmem.yaml      |  5 ++++
 arch/arm64/boot/dts/freescale/imx8mm.dtsi     |  2 +-
 arch/arm64/boot/dts/freescale/imx8mn.dtsi     |  2 +-
 arch/arm64/boot/dts/freescale/imx8mp.dtsi     |  2 +-
 arch/arm64/boot/dts/freescale/imx8mq.dtsi     |  2 +-
 drivers/nvmem/core.c                          | 30 +++++++++++++++++++
 include/linux/nvmem-provider.h                |  2 ++
 7 files changed, 41 insertions(+), 4 deletions(-)

-- 
2.17.1

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

[Joakim Zhang]

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

Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
 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.
 
+      reverse-data:
+        $ref: /schemas/types.yaml#/definitions/flag
+        description:
+          Reverse the data that read from the storage device.
+
     required:
       - reg
 
-- 
2.17.1

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

[Jan Lübbe]

On Tue, 2021-08-10 at 15:35 +0800, Joakim Zhang wrote:
> Introduce "reverse-data" property for nvmem provider to reverse buffer.
> 
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
>  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.
>  
> +      reverse-data:
> +        $ref: /schemas/types.yaml#/definitions/flag
> +        description:
> +          Reverse the data that read from the storage device.

I'd prefer if it was more explicit that the *bytes* will be reversed. Otherwise
a reader might think that this is reversing on the *bit* level.

Jan

> +
>      required:
>        - reg
>  

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

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

[Joakim Zhang]

> -----Original Message-----
> From: Jan Lübbe <jlu@pengutronix.de>
> Sent: 2021年8月10日 23:14
> To: Joakim Zhang <qiangqing.zhang@nxp.com>;
> srinivas.kandagatla@linaro.org; robh+dt@kernel.org; shawnguo@kernel.org
> Cc: devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> kernel@pengutronix.de; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
> property
> 
> On Tue, 2021-08-10 at 15:35 +0800, Joakim Zhang wrote:
> > Introduce "reverse-data" property for nvmem provider to reverse buffer.
> >
> > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > ---
> >  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.
> >
> > +      reverse-data:
> > +        $ref: /schemas/types.yaml#/definitions/flag
> > +        description:
> > +          Reverse the data that read from the storage device.
> 
> I'd prefer if it was more explicit that the *bytes* will be reversed. Otherwise a
> reader might think that this is reversing on the *bit* level.

Make sense, how about 'reverse-byte-order'?

Best Regards,
Joakim Zhang
> Jan
> 
> > +
> >      required:
> >        - reg
> >
> 
> --
> Pengutronix e.K.                           |
> |
> Steuerwalder Str. 21                       |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pe
> ngutronix.de%2F&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%7C79
> 3a60188540455919b608d95c118878%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C637642052637994749%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
> 000&amp;sdata=S27O8AV8lRvGxyEutJl6Uh4AjbArD%2BkvQl%2FI05ZU1P8%3D
> &amp;reserved=0  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686           | Fax:
> +49-5121-206917-5555 |

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

[Joakim Zhang]

> -----Original Message-----
> From: Joakim Zhang <qiangqing.zhang@nxp.com>
> Sent: 2021年8月11日 16:05
> To: Jan Lübbe <jlu@pengutronix.de>; srinivas.kandagatla@linaro.org;
> robh+dt@kernel.org; shawnguo@kernel.org
> Cc: devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> kernel@pengutronix.de; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
> property
> 
> 
> > -----Original Message-----
> > From: Jan Lübbe <jlu@pengutronix.de>
> > Sent: 2021年8月10日 23:14
> > To: Joakim Zhang <qiangqing.zhang@nxp.com>;
> > srinivas.kandagatla@linaro.org; robh+dt@kernel.org;
> > shawnguo@kernel.org
> > Cc: devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> > kernel@pengutronix.de; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
> > property
> >
> > On Tue, 2021-08-10 at 15:35 +0800, Joakim Zhang wrote:
> > > Introduce "reverse-data" property for nvmem provider to reverse buffer.
> > >
> > > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > > ---
> > >  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.
> > >
> > > +      reverse-data:
> > > +        $ref: /schemas/types.yaml#/definitions/flag
> > > +        description:
> > > +          Reverse the data that read from the storage device.
> >
> > I'd prefer if it was more explicit that the *bytes* will be reversed.
> > Otherwise a reader might think that this is reversing on the *bit* level.
> 
> Make sense, how about 'reverse-byte-order'?

Sorry, 'reverse-bytes-order'.

Best Regards,
Joakim Zhang
> Best Regards,
> Joakim Zhang
> > Jan
> >
> > > +
> > >      required:
> > >        - reg
> > >
> >
> > --
> > Pengutronix e.K.                           |
> > |
> > Steuerwalder Str. 21                       |
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.p
> > e
> >
> ngutronix.de%2F&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%7C79
> >
> 3a60188540455919b608d95c118878%7C686ea1d3bc2b4c6fa92cd99c5c30163
> >
> 5%7C0%7C0%7C637642052637994749%7CUnknown%7CTWFpbGZsb3d8eyJWI
> >
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1
> >
> 000&amp;sdata=S27O8AV8lRvGxyEutJl6Uh4AjbArD%2BkvQl%2FI05ZU1P8%3D
> > &amp;reserved=0  |
> > 31137 Hildesheim, Germany                  | Phone:
> +49-5121-206917-0
> > |
> > Amtsgericht Hildesheim, HRA 2686           | Fax:
> > +49-5121-206917-5555 |

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

[Jan Lübbe]

On Wed, 2021-08-11 at 08:06 +0000, Joakim Zhang wrote:
> 
> > -----Original Message-----
> > From: Joakim Zhang <qiangqing.zhang@nxp.com>
> > Sent: 2021年8月11日 16:05
> > To: Jan Lübbe <jlu@pengutronix.de>; srinivas.kandagatla@linaro.org;
> > robh+dt@kernel.org; shawnguo@kernel.org
> > Cc: devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> > kernel@pengutronix.de; linux-kernel@vger.kernel.org
> > Subject: RE: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
> > property
> > 
> > 
> > > -----Original Message-----
> > > From: Jan Lübbe <jlu@pengutronix.de>
> > > Sent: 2021年8月10日 23:14
> > > To: Joakim Zhang <qiangqing.zhang@nxp.com>;
> > > srinivas.kandagatla@linaro.org; robh+dt@kernel.org;
> > > shawnguo@kernel.org
> > > Cc: devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>;
> > > kernel@pengutronix.de; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
> > > property
> > > 
> > > On Tue, 2021-08-10 at 15:35 +0800, Joakim Zhang wrote:
> > > > Introduce "reverse-data" property for nvmem provider to reverse buffer.
> > > > 
> > > > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > > > ---
> > > >  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.
> > > > 
> > > > +      reverse-data:
> > > > +        $ref: /schemas/types.yaml#/definitions/flag
> > > > +        description:
> > > > +          Reverse the data that read from the storage device.
> > > 
> > > I'd prefer if it was more explicit that the *bytes* will be reversed.
> > > Otherwise a reader might think that this is reversing on the *bit* level.
> > 
> > Make sense, how about 'reverse-byte-order'?
> 
> Sorry, 'reverse-bytes-order'.

'reverse-byte-order' sounds better to me, but I'm not a native English speaker.
I'd be fine with either, though.

Thanks
Jan

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

[Srinivas Kandagatla]

On 10/08/2021 08:35, Joakim Zhang wrote:
> Introduce "reverse-data" property for nvmem provider to reverse buffer.
> 
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
>   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.
>   
> +      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.


Lets see what Rob would say on this approach.


--srini

>       required:
>         - reg
>   
> 

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

[Rob Herring]

On Wed, Aug 11, 2021 at 11:16:49AM +0100, Srinivas Kandagatla wrote:
> 
> 
> On 10/08/2021 08:35, Joakim Zhang wrote:
> > Introduce "reverse-data" property for nvmem provider to reverse buffer.
> > 
> > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > ---
> >   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.
> > +      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.

Rob

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

[Joakim Zhang]

> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: 2021年8月18日 3:58
> To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Cc: Joakim Zhang <qiangqing.zhang@nxp.com>; shawnguo@kernel.org;
> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>;
> 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:
> >
> >
> > On 10/08/2021 08:35, Joakim Zhang wrote:
> > > Introduce "reverse-data" property for nvmem provider to reverse buffer.
> > >
> > > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > > ---
> > >   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.
> > > +      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,

Do you plan to implement it?

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

Thanks.

Best Regards,
Joakim Zhang
> Rob

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

[Joakim Zhang]

Hi Srinivas,

> > > > --- 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.
> > > > +      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,
> 
> Do you plan to implement it?
> 
> Or need me follow up? If yes, please input your insights to point me how to
> work for it.

Any comments?

Best Regards,
Joakim Zhang

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

[Srinivas Kandagatla]

Hi Joakim,

On 18/08/2021 08:54, Joakim Zhang wrote:
> 
>> -----Original Message-----
>> From: Rob Herring <robh@kernel.org>
>> Sent: 2021年8月18日 3:58
>> To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Cc: Joakim Zhang <qiangqing.zhang@nxp.com>; shawnguo@kernel.org;
>> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>;
>> 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:
>>>
>>>
>>> On 10/08/2021 08:35, Joakim Zhang wrote:
>>>> Introduce "reverse-data" property for nvmem provider to reverse buffer.
>>>>
>>>> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
>>>> ---
>>>>    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.
>>>> +      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.

> Do you plan to implement it?

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

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

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

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.

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.

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?

--srini

> 
> Thanks.
> 
> Best Regards,
> Joakim Zhang
>> Rob

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

[Joakim Zhang]

Hi Srinivas,

> -----Original Message-----
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Sent: 2021年9月3日 20:38
> To: Joakim Zhang <qiangqing.zhang@nxp.com>; Rob Herring
> <robh@kernel.org>
> Cc: shawnguo@kernel.org; kernel@pengutronix.de; dl-linux-imx
> <linux-imx@nxp.com>; 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:
> >
> >> -----Original Message-----
> >> From: Rob Herring <robh@kernel.org>
> >> Sent: 2021年8月18日 3:58
> >> To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> >> Cc: Joakim Zhang <qiangqing.zhang@nxp.com>; shawnguo@kernel.org;
> >> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>;
> >> 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:
> >>>
> >>>
> >>> On 10/08/2021 08:35, Joakim Zhang wrote:
> >>>> Introduce "reverse-data" property for nvmem provider to reverse buffer.
> >>>>
> >>>> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> >>>> ---
> >>>>    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.
> >>>> +      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.
> 
> > Do you plan to implement it?
> 
> No, Am not planning to do this. But am happy to walk-thru the ideas that I
> have.
> 
> >
> > 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.

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

I think, yes.
 
> 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"?

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

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

--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -76,6 +76,8 @@
 #define IMX_OCOTP_WR_UNLOCK            0x3E770000
 #define IMX_OCOTP_READ_LOCKED_VAL      0xBADABADA

+#define IMX_OCOTP_MAC_MAX              0x2     /* The maximum numbers of MAC instance */
+
 static DEFINE_MUTEX(ocotp_mutex);

 struct ocotp_priv {
@@ -93,11 +95,18 @@ struct ocotp_ctrl_reg {
        u32 bm_rel_shadows;
 };

+struct mac_config {
+       u32 offset;
+       u32 size;
+       bool reverse_byte;
+};
+
 struct ocotp_params {
        unsigned int nregs;
        unsigned int bank_address_words;
        void (*set_timing)(struct ocotp_priv *priv);
        struct ocotp_ctrl_reg ctrl;
+       struct mac_config mac[IMX_OCOTP_MAC_MAX];
 };

 static int imx_ocotp_wait_for_busy(struct ocotp_priv *priv, u32 flags)
@@ -211,6 +220,20 @@ static int imx_ocotp_read(void *context, unsigned int offset,
        }

        index = offset % 4;
+
+       /* Handle MAC address reverse byte if required */
+       for (i = 0; i < IMX_OCOTP_MAC_MAX; i++) {
+               if (offset == priv->params->mac[i].offset &&
+                   bytes == priv->params->mac[i].size &&
+                   priv->params->mac[i].reverse_byte) {
+                       u8 *org = &p[index];
+                       int j;
+
+                       for (j = 0; j < bytes/2; j++)
+                               swap(org[j], org[bytes-j-1]);
+               }
+       }
+
        memcpy(val, &p[index], bytes);

 read_end:
@@ -556,6 +579,12 @@ static const struct ocotp_params imx8mp_params = {
        .bank_address_words = 0,
        .set_timing = imx_ocotp_set_imx6_timing,
        .ctrl = IMX_OCOTP_BM_CTRL_8MP,
+       .mac[0].offset = 0x90,
+       .mac[0].size = 6,
+       .mac[0].reverse_byte = true,
+       .mac[1].offset = 0x96,
+       .mac[1].size = 6,
+       .mac[1].reverse_byte = true,
 };

 static const struct of_device_id imx_ocotp_dt_ids[] = {


Best Regards,
Joakim Zhang

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

[Srinivas Kandagatla]

Hi Joakim,


On 06/09/2021 09:58, Joakim Zhang wrote:
> 
> Hi Srinivas,
> 
>> -----Original Message-----
>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Sent: 2021年9月3日 20:38
>> To: Joakim Zhang <qiangqing.zhang@nxp.com>; Rob Herring
>> <robh@kernel.org>
>> Cc: shawnguo@kernel.org; kernel@pengutronix.de; dl-linux-imx
>> <linux-imx@nxp.com>; 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:
>>>
>>>> -----Original Message-----
>>>> From: Rob Herring <robh@kernel.org>
>>>> Sent: 2021年8月18日 3:58
>>>> To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>>> Cc: Joakim Zhang <qiangqing.zhang@nxp.com>; shawnguo@kernel.org;
>>>> kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>;
>>>> 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:
>>>>>
>>>>>
>>>>> On 10/08/2021 08:35, Joakim Zhang wrote:
>>>>>> Introduce "reverse-data" property for nvmem provider to reverse buffer.
>>>>>>
>>>>>> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
>>>>>> ---
>>>>>>     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.
>>>>>> +      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.
>>
>>> Do you plan to implement it?
>>
>> No, Am not planning to do this. But am happy to walk-thru the ideas that I
>> have.
>>
>>>
>>> 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.
> 
>> Am I correct to say that this is only issue with mac-address nvmem cell?
> 
> I think, yes.
>   
>> 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"?
> 
>> 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>;




> 
>> 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
> 
> --- a/drivers/nvmem/imx-ocotp.c
> +++ b/drivers/nvmem/imx-ocotp.c
> @@ -76,6 +76,8 @@
>   #define IMX_OCOTP_WR_UNLOCK            0x3E770000
>   #define IMX_OCOTP_READ_LOCKED_VAL      0xBADABADA
> 
> +#define IMX_OCOTP_MAC_MAX              0x2     /* The maximum numbers of MAC instance */
> +
>   static DEFINE_MUTEX(ocotp_mutex);
> 
>   struct ocotp_priv {
> @@ -93,11 +95,18 @@ struct ocotp_ctrl_reg {
>          u32 bm_rel_shadows;
>   };
> 
> +struct mac_config {
> +       u32 offset;
> +       u32 size;
> +       bool reverse_byte;
> +};
> +
>   struct ocotp_params {
>          unsigned int nregs;
>          unsigned int bank_address_words;
>          void (*set_timing)(struct ocotp_priv *priv);
>          struct ocotp_ctrl_reg ctrl;
> +       struct mac_config mac[IMX_OCOTP_MAC_MAX];
>   };
> 
>   static int imx_ocotp_wait_for_busy(struct ocotp_priv *priv, u32 flags)
> @@ -211,6 +220,20 @@ static int imx_ocotp_read(void *context, unsigned int offset,
>          }
> 
>          index = offset % 4;
> +
> +       /* Handle MAC address reverse byte if required */
> +       for (i = 0; i < IMX_OCOTP_MAC_MAX; i++) {
> +               if (offset == priv->params->mac[i].offset &&
> +                   bytes == priv->params->mac[i].size &&
> +                   priv->params->mac[i].reverse_byte) {
> +                       u8 *org = &p[index];
> +                       int j;
> +
> +                       for (j = 0; j < bytes/2; j++)
> +                               swap(org[j], org[bytes-j-1]);
> +               }
> +       }
> +
>          memcpy(val, &p[index], bytes);
> 
>   read_end:
> @@ -556,6 +579,12 @@ static const struct ocotp_params imx8mp_params = {
>          .bank_address_words = 0,
>          .set_timing = imx_ocotp_set_imx6_timing,
>          .ctrl = IMX_OCOTP_BM_CTRL_8MP,
> +       .mac[0].offset = 0x90,
> +       .mac[0].size = 6,
> +       .mac[0].reverse_byte = true,
> +       .mac[1].offset = 0x96,
> +       .mac[1].size = 6,
> +       .mac[1].reverse_byte = true,
>   };
> 
>   static const struct of_device_id imx_ocotp_dt_ids[] = {
> 
> 
> Best Regards,
> Joakim Zhang
> 

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

[Joakim Zhang]

Hi Srinivas,

[...]
> I have pushed some nvmem core patches which are just compile tested to
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Flog%
> 2F%3Fh%3Dtopic%2Fpost-processing&data=04%7C01%7Cqiangqing.zhan
> g%40nxp.com%7Cadfa3ba63c634937876308d971e7e71f%7C686ea1d3bc2b4c6
> fa92cd99c5c301635%7C0%7C0%7C637666063097239185%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> XVCI6Mn0%3D%7C1000&sdata=W9yAnGm9rYzlSZuAAGiN4VHUtKYUTt9S
> oyGQ9QsY7fI%3D&reserved=0
> 
> This should provide the callback hook I was talking about.

Thanks a lot! Yes, this could be more common, vendors can parse their mac
address for different encoding style, also can extend for other cases.

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

There are some small issues need to be update:
1) https://git.kernel.org/pub/scm/linux/kernel/git/srini/nvmem.git/commit/?h=topic/post-processing&id=624f2cc99b48bbfe05c11e58fb73f84abb1a646e
	of_get_property() can't get the cell value, so I change to of_property_read_s32()
2) https://git.kernel.org/pub/scm/linux/kernel/git/srini/nvmem.git/commit/?h=topic/post-processing&id=a424302c7b15da41e1e8de56b0c78021b9a96c1e
	if (!nvmem->cell_post_process) {} should be if (nvmem->cell_post_process) {}, if we have this callback, we need do the post-processing.

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

No, it's depend on how to program the effuse. 
To avoid introducing consumer property in devicetree, I prefer to move reverse_mac_address
flag into ocotp_params struct, since each platforms has their own, it's easy to indicate this. I tried
it, and works.

> 2. In imx devicetree for mac-address nvmem cell make sure you add
> 
> cell-type = <NVMEM_CELL_TYPE_MAC_ADDRESS>;
> 
> 
> 
> 
> >
> >> 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.

I have improved this patch set according above comments and tested it. Also rebase to
the nvmem/for-next branch.

I plan to keep you as the nvmem part author and send out this patch set with dts changes. If it's fine for you?
  
Best Regards,
Joakim Zhang

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

[Srinivas Kandagatla]

On 08/09/2021 08:14, Joakim Zhang wrote:
> 
> Hi Srinivas,
> 
> [...]
>> I have pushed some nvmem core patches which are just compile tested to
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
>> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Flog%
>> 2F%3Fh%3Dtopic%2Fpost-processing&data=04%7C01%7Cqiangqing.zhan
>> g%40nxp.com%7Cadfa3ba63c634937876308d971e7e71f%7C686ea1d3bc2b4c6
>> fa92cd99c5c301635%7C0%7C0%7C637666063097239185%7CUnknown%7CT
>> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
>> XVCI6Mn0%3D%7C1000&sdata=W9yAnGm9rYzlSZuAAGiN4VHUtKYUTt9S
>> oyGQ9QsY7fI%3D&reserved=0
>>
>> This should provide the callback hook I was talking about.
> 
> Thanks a lot! Yes, this could be more common, vendors can parse their mac
> address for different encoding style, also can extend for other cases.

Yes, that is the idea,
> 
>> Can you take a look at them and let me know if it works for you.
> 
> There are some small issues need to be update:
> 1) https://git.kernel.org/pub/scm/linux/kernel/git/srini/nvmem.git/commit/?h=topic/post-processing&id=624f2cc99b48bbfe05c11e58fb73f84abb1a646e
> 	of_get_property() can't get the cell value, so I change to of_property_read_s32()
> 2) https://git.kernel.org/pub/scm/linux/kernel/git/srini/nvmem.git/commit/?h=topic/post-processing&id=a424302c7b15da41e1e8de56b0c78021b9a96c1e
> 	if (!nvmem->cell_post_process) {} should be if (nvmem->cell_post_process) {}, if we have this callback, we need do the post-processing.
> 
I have pushed these changes now to the branch.

>> 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.
> 
> No, it's depend on how to program the effuse.
> To avoid introducing consumer property in devicetree, I prefer to move reverse_mac_address
> flag into ocotp_params struct, since each platforms has their own, it's easy to indicate this. I tried
> it, and works. >

As long as provider can figure out how the efuse is programmed then it 
is fine with me.


>> 2. In imx devicetree for mac-address nvmem cell make sure you add
>>
>> cell-type = <NVMEM_CELL_TYPE_MAC_ADDRESS>;
>>
>>
>>
>>
>>>
>>>> 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.
> 
> I have improved this patch set according above comments and tested it. Also rebase to
> the nvmem/for-next branch.
> 
> I plan to keep you as the nvmem part author and send out this patch set with dts changes. If it's fine for you?

Yes please, can you pick the new patches from the branch before you send 
the series out.

--srini
>    
> Best Regards,
> Joakim Zhang
> 

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

[Joakim Zhang]

Hi Srinivas,

> -----Original Message-----
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Sent: 2021年9月8日 16:49
> To: Joakim Zhang <qiangqing.zhang@nxp.com>; Rob Herring
> <robh@kernel.org>
> Cc: shawnguo@kernel.org; kernel@pengutronix.de; dl-linux-imx
> <linux-imx@nxp.com>; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
> property
> 
> 
> 
> On 08/09/2021 08:14, Joakim Zhang wrote:
> >
> > Hi Srinivas,
> >
> > [...]
> >> I have pushed some nvmem core patches which are just compile tested
> >> to
> >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >> .kern%2F&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%7Cb8b85
> eab6bc34
> >>
> 917b86e08d972a57dee%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
> 7C6376
> >>
> 66877370588296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2
> >>
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=diFgK2ufOUK
> eXwd
> >> 0Ez8pCFjCUH8rXz5jfW7io8KDKmw%3D&amp;reserved=0
> >>
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Flog%
> >>
> 2F%3Fh%3Dtopic%2Fpost-processing&amp;data=04%7C01%7Cqiangqing.zhan
> >>
> g%40nxp.com%7Cadfa3ba63c634937876308d971e7e71f%7C686ea1d3bc2b4c6
> >>
> fa92cd99c5c301635%7C0%7C0%7C637666063097239185%7CUnknown%7CT
> >>
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
> >>
> XVCI6Mn0%3D%7C1000&amp;sdata=W9yAnGm9rYzlSZuAAGiN4VHUtKYUTt9S
> >> oyGQ9QsY7fI%3D&amp;reserved=0
> >>
> >> This should provide the callback hook I was talking about.
> >
> > Thanks a lot! Yes, this could be more common, vendors can parse their
> > mac address for different encoding style, also can extend for other cases.
> 
> Yes, that is the idea,
> >
> >> Can you take a look at them and let me know if it works for you.
> >
> > There are some small issues need to be update:
> > 1)
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Fcom
> mit%2F%3Fh%3Dtopic%2Fpost-processing%26id%3D624f2cc99b48bbfe05c11e
> 58fb73f84abb1a646e&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%
> 7Cb8b85eab6bc34917b86e08d972a57dee%7C686ea1d3bc2b4c6fa92cd99c5c3
> 01635%7C0%7C0%7C637666877370598253%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C1000&amp;sdata=APDzSbLob%2FRiZyyhU7VAhoUEAmSG95NsilQDQ53Hbf
> A%3D&amp;reserved=0
> > 	of_get_property() can't get the cell value, so I change to
> > of_property_read_s32()
> > 2)
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Fcom
> mit%2F%3Fh%3Dtopic%2Fpost-processing%26id%3Da424302c7b15da41e1e8d
> e56b0c78021b9a96c1e&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com
> %7Cb8b85eab6bc34917b86e08d972a57dee%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C637666877370598253%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C1000&amp;sdata=5E49DVzkpBVdkA4a%2B9tMXN%2B6k%2BG%2B3rQuVJ
> qTUgdbmKU%3D&amp;reserved=0
> > 	if (!nvmem->cell_post_process) {} should be if (nvmem->cell_post_process)
> {}, if we have this callback, we need do the post-processing.
> >
> I have pushed these changes now to the branch.
> 
> >> 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.
> >
> > No, it's depend on how to program the effuse.
> > To avoid introducing consumer property in devicetree, I prefer to move
> > reverse_mac_address flag into ocotp_params struct, since each
> > platforms has their own, it's easy to indicate this. I tried it, and
> > works. >
> 
> As long as provider can figure out how the efuse is programmed then it is fine
> with me.
> 
> 
> >> 2. In imx devicetree for mac-address nvmem cell make sure you add
> >>
> >> cell-type = <NVMEM_CELL_TYPE_MAC_ADDRESS>;
> >>
> >>
> >>
> >>
> >>>
> >>>> 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.
> >
> > I have improved this patch set according above comments and tested it. Also
> rebase to
> > the nvmem/for-next branch.
> >
> > I plan to keep you as the nvmem part author and send out this patch set with
> dts changes. If it's fine for you?
> 
> Yes please, can you pick the new patches from the branch before you send
> the series out.

As you define the type variable is "int", so had better use of_property_read_s32(), instead if of_property_read_u32(), right?

Best Regards,
Joakim Zhang

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

[Srinivas Kandagatla]

On 08/09/2021 09:57, Joakim Zhang wrote:
> 
> Hi Srinivas,
> 
>> -----Original Message-----
>> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> Sent: 2021年9月8日 16:49
>> To: Joakim Zhang <qiangqing.zhang@nxp.com>; Rob Herring
>> <robh@kernel.org>
>> Cc: shawnguo@kernel.org; kernel@pengutronix.de; dl-linux-imx
>> <linux-imx@nxp.com>; devicetree@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
>> property
>>
>>
>>
>> On 08/09/2021 08:14, Joakim Zhang wrote:
>>>
>>> Hi Srinivas,
>>>
>>> [...]
>>>> I have pushed some nvmem core patches which are just compile tested
>>>> to
>>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
>>>> .kern%2F&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%7Cb8b85
>> eab6bc34
>>>>
>> 917b86e08d972a57dee%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%
>> 7C6376
>>>>
>> 66877370588296%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
>> JQIjoiV2
>>>>
>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=diFgK2ufOUK
>> eXwd
>>>> 0Ez8pCFjCUH8rXz5jfW7io8KDKmw%3D&amp;reserved=0
>>>>
>> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Flog%
>>>>
>> 2F%3Fh%3Dtopic%2Fpost-processing&amp;data=04%7C01%7Cqiangqing.zhan
>>>>
>> g%40nxp.com%7Cadfa3ba63c634937876308d971e7e71f%7C686ea1d3bc2b4c6
>>>>
>> fa92cd99c5c301635%7C0%7C0%7C637666063097239185%7CUnknown%7CT
>>>>
>> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ
>>>>
>> XVCI6Mn0%3D%7C1000&amp;sdata=W9yAnGm9rYzlSZuAAGiN4VHUtKYUTt9S
>>>> oyGQ9QsY7fI%3D&amp;reserved=0
>>>>
>>>> This should provide the callback hook I was talking about.
>>>
>>> Thanks a lot! Yes, this could be more common, vendors can parse their
>>> mac address for different encoding style, also can extend for other cases.
>>
>> Yes, that is the idea,
>>>
>>>> Can you take a look at them and let me know if it works for you.
>>>
>>> There are some small issues need to be update:
>>> 1)
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
>> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Fcom
>> mit%2F%3Fh%3Dtopic%2Fpost-processing%26id%3D624f2cc99b48bbfe05c11e
>> 58fb73f84abb1a646e&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com%
>> 7Cb8b85eab6bc34917b86e08d972a57dee%7C686ea1d3bc2b4c6fa92cd99c5c3
>> 01635%7C0%7C0%7C637666877370598253%7CUnknown%7CTWFpbGZsb3d8e
>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>> %7C1000&amp;sdata=APDzSbLob%2FRiZyyhU7VAhoUEAmSG95NsilQDQ53Hbf
>> A%3D&amp;reserved=0
>>> 	of_get_property() can't get the cell value, so I change to
>>> of_property_read_s32()
>>> 2)
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kern
>> el.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fsrini%2Fnvmem.git%2Fcom
>> mit%2F%3Fh%3Dtopic%2Fpost-processing%26id%3Da424302c7b15da41e1e8d
>> e56b0c78021b9a96c1e&amp;data=04%7C01%7Cqiangqing.zhang%40nxp.com
>> %7Cb8b85eab6bc34917b86e08d972a57dee%7C686ea1d3bc2b4c6fa92cd99c5c
>> 301635%7C0%7C0%7C637666877370598253%7CUnknown%7CTWFpbGZsb3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
>> %7C1000&amp;sdata=5E49DVzkpBVdkA4a%2B9tMXN%2B6k%2BG%2B3rQuVJ
>> qTUgdbmKU%3D&amp;reserved=0
>>> 	if (!nvmem->cell_post_process) {} should be if (nvmem->cell_post_process)
>> {}, if we have this callback, we need do the post-processing.
>>>
>> I have pushed these changes now to the branch.
>>
>>>> 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.
>>>
>>> No, it's depend on how to program the effuse.
>>> To avoid introducing consumer property in devicetree, I prefer to move
>>> reverse_mac_address flag into ocotp_params struct, since each
>>> platforms has their own, it's easy to indicate this. I tried it, and
>>> works. >
>>
>> As long as provider can figure out how the efuse is programmed then it is fine
>> with me.
>>
>>
>>>> 2. In imx devicetree for mac-address nvmem cell make sure you add
>>>>
>>>> cell-type = <NVMEM_CELL_TYPE_MAC_ADDRESS>;
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>> 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.
>>>
>>> I have improved this patch set according above comments and tested it. Also
>> rebase to
>>> the nvmem/for-next branch.
>>>
>>> I plan to keep you as the nvmem part author and send out this patch set with
>> dts changes. If it's fine for you?
>>
>> Yes please, can you pick the new patches from the branch before you send
>> the series out.
> 
> As you define the type variable is "int", so had better use of_property_read_s32(), instead if of_property_read_u32(), right?

We should probably make that u32, as we are not expecting any negative 
range.

I tried to fix this in new patches.

--srini
> 
> Best Regards,
> Joakim Zhang
> 

[PATCH V1 2/4] nvmem: core: introduce "reverse-data" property to reverse buffer

[Joakim Zhang]

This patch intends to introduce "reverse-data" property at nvmem
provider side to reverse buffer.

For a case used from Ethernet driver, of_get_mac_address() may call
of_get_mac_addr_nvmem() to get MAC address from nvmem device. MAC address
programed in imx-ocopt is MSB first in lowest address, so need reverse
data then feedback to nvmem consumer. E.g. MAC address read from
imx-ocopt is 98:e2:06:9f:04:00, after reversed the data is
00:04:9f:06:e2:98.

Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
 drivers/nvmem/core.c           | 30 ++++++++++++++++++++++++++++++
 include/linux/nvmem-provider.h |  2 ++
 2 files changed, 32 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index b3bc30a04ed7..ccc2c5801c8e 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -55,6 +55,7 @@ struct nvmem_cell {
 	struct device_node	*np;
 	struct nvmem_device	*nvmem;
 	struct list_head	node;
+	u32			flags;
 };
 
 static DEFINE_MUTEX(nvmem_mutex);
@@ -92,6 +93,26 @@ static int __nvmem_reg_write(struct nvmem_device *nvmem, unsigned int offset,
 	return -EINVAL;
 }
 
+static int nvmem_buffer_reverse(void *bufaddr, int len)
+{
+	u8 *buf = (u8 *)bufaddr;
+	u8 *temp;
+	int i;
+
+	temp = kzalloc(len, GFP_KERNEL);
+	if (!temp)
+		return -ENOMEM;
+
+	memcpy(temp, buf, len);
+
+	for (i = 0; i < len; i++)
+		buf[i] = temp[len - i - 1];
+
+	kfree(temp);
+
+	return 0;
+}
+
 static int nvmem_access_with_keepouts(struct nvmem_device *nvmem,
 				      unsigned int offset, void *val,
 				      size_t bytes, int write)
@@ -705,6 +726,9 @@ static int nvmem_add_cells_from_of(struct nvmem_device *nvmem)
 		cell->bytes = be32_to_cpup(addr);
 		cell->name = kasprintf(GFP_KERNEL, "%pOFn", child);
 
+		if (of_property_read_bool(child, "reverse-data"))
+			cell->flags |= NVMEM_FLAGS_REVERSE_DATA;
+
 		addr = of_get_property(child, "bits", &len);
 		if (addr && len == (2 * sizeof(u32))) {
 			cell->bit_offset = be32_to_cpup(addr++);
@@ -1398,6 +1422,12 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
 	if (cell->bit_offset || cell->nbits)
 		nvmem_shift_read_buffer_in_place(cell, buf);
 
+	if (cell->flags & NVMEM_FLAGS_REVERSE_DATA) {
+		rc = nvmem_buffer_reverse(buf, cell->bytes);
+		if (rc < 0)
+			return rc;
+	}
+
 	if (len)
 		*len = cell->bytes;
 
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index 104505e9028f..364ac2a61b11 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -31,6 +31,8 @@ enum nvmem_type {
 #define NVMEM_DEVID_NONE	(-1)
 #define NVMEM_DEVID_AUTO	(-2)
 
+#define NVMEM_FLAGS_REVERSE_DATA	BIT(0)
+
 /**
  * struct nvmem_keepout - NVMEM register keepout range.
  *
-- 
2.17.1

Re: [PATCH V1 2/4] nvmem: core: introduce "reverse-data" property to reverse buffer

[Srinivas Kandagatla]

On 10/08/2021 08:35, Joakim Zhang wrote:
> This patch intends to introduce "reverse-data" property at nvmem
> provider side to reverse buffer.
> 
> For a case used from Ethernet driver, of_get_mac_address() may call
> of_get_mac_addr_nvmem() to get MAC address from nvmem device. MAC address
> programed in imx-ocopt is MSB first in lowest address, so need reverse

Is all the data stored in imx-ocopt reverse byte order?

or someone decided to change the order for only mac-address?


> data then feedback to nvmem consumer. E.g. MAC address read from
> imx-ocopt is 98:e2:06:9f:04:00, after reversed the data is
> 00:04:9f:06:e2:98.
> 
> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> ---
>   drivers/nvmem/core.c           | 30 ++++++++++++++++++++++++++++++
>   include/linux/nvmem-provider.h |  2 ++
>   2 files changed, 32 insertions(+)
> 
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index b3bc30a04ed7..ccc2c5801c8e 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -55,6 +55,7 @@ struct nvmem_cell {
>   	struct device_node	*np;
>   	struct nvmem_device	*nvmem;
>   	struct list_head	node;
> +	u32			flags;

This flag also needs to go in struct nvmem_cell_info too.

>   };
>   
>   static DEFINE_MUTEX(nvmem_mutex);
> @@ -92,6 +93,26 @@ static int __nvmem_reg_write(struct nvmem_device *nvmem, unsigned int offset,
>   	return -EINVAL;
>   }
>   
> +static int nvmem_buffer_reverse(void *bufaddr, int len)
> +{
> +	u8 *buf = (u8 *)bufaddr;
> +	u8 *temp;
> +	int i;
> +
> +	temp = kzalloc(len, GFP_KERNEL);
> +	if (!temp)
> +		return -ENOMEM;
> +
> +	memcpy(temp, buf, len);
> +
> +	for (i = 0; i < len; i++)
> +		buf[i] = temp[len - i - 1];
> +

You could possibly simplify this.

static void nvmem_buffer_reverse(u8 *buf, int len)
{
	int i;

	for (i = 0; i < len/2; i++)
		swap(buf[i], buf[len - i - 1]);
}

> +	kfree(temp);
> +
> +	return 0;
> +}
> +
>   static int nvmem_access_with_keepouts(struct nvmem_device *nvmem,
>   				      unsigned int offset, void *val,
>   				      size_t bytes, int write)
> @@ -705,6 +726,9 @@ static int nvmem_add_cells_from_of(struct nvmem_device *nvmem)
>   		cell->bytes = be32_to_cpup(addr);
>   		cell->name = kasprintf(GFP_KERNEL, "%pOFn", child);
>   
> +		if (of_property_read_bool(child, "reverse-data"))
> +			cell->flags |= NVMEM_FLAGS_REVERSE_DATA;
> +
>   		addr = of_get_property(child, "bits", &len);
>   		if (addr && len == (2 * sizeof(u32))) {
>   			cell->bit_offset = be32_to_cpup(addr++);
> @@ -1398,6 +1422,12 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
>   	if (cell->bit_offset || cell->nbits)
>   		nvmem_shift_read_buffer_in_place(cell, buf);
>   
> +	if (cell->flags & NVMEM_FLAGS_REVERSE_DATA) {
> +		rc = nvmem_buffer_reverse(buf, cell->bytes);
> +		if (rc < 0)
> +			return rc;
> +	}
> +
>   	if (len)
>   		*len = cell->bytes;
>   
> diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
> index 104505e9028f..364ac2a61b11 100644
> --- a/include/linux/nvmem-provider.h
> +++ b/include/linux/nvmem-provider.h
> @@ -31,6 +31,8 @@ enum nvmem_type {
>   #define NVMEM_DEVID_NONE	(-1)
>   #define NVMEM_DEVID_AUTO	(-2)
>   
> +#define NVMEM_FLAGS_REVERSE_DATA	BIT(0)

Maybe NVMEM_FLAGS_REVERSE_BYTE_ORDER and some kerneldoc would help new 
users.

--srini
> +
>   /**
>    * struct nvmem_keepout - NVMEM register keepout range.
>    *
> 

RE: [PATCH V1 2/4] nvmem: core: introduce "reverse-data" property to reverse buffer

[Joakim Zhang]

> -----Original Message-----
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Sent: 2021年8月11日 17:52
> To: Joakim Zhang <qiangqing.zhang@nxp.com>; robh+dt@kernel.org;
> shawnguo@kernel.org
> Cc: kernel@pengutronix.de; dl-linux-imx <linux-imx@nxp.com>;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH V1 2/4] nvmem: core: introduce "reverse-data" property
> to reverse buffer
> 
> 
> 
> On 10/08/2021 08:35, Joakim Zhang wrote:
> > This patch intends to introduce "reverse-data" property at nvmem
> > provider side to reverse buffer.
> >
> > For a case used from Ethernet driver, of_get_mac_address() may call
> > of_get_mac_addr_nvmem() to get MAC address from nvmem device. MAC
> > address programed in imx-ocopt is MSB first in lowest address, so need
> > reverse
> 
> Is all the data stored in imx-ocopt reverse byte order?

No, it depends on how users program these data.

> or someone decided to change the order for only mac-address?

No, will not change the order for mac-address, would be consistent.

> 
> > data then feedback to nvmem consumer. E.g. MAC address read from
> > imx-ocopt is 98:e2:06:9f:04:00, after reversed the data is
> > 00:04:9f:06:e2:98.
> >
> > Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
> > ---
> >   drivers/nvmem/core.c           | 30
> ++++++++++++++++++++++++++++++
> >   include/linux/nvmem-provider.h |  2 ++
> >   2 files changed, 32 insertions(+)
> >
> > diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index
> > b3bc30a04ed7..ccc2c5801c8e 100644
> > --- a/drivers/nvmem/core.c
> > +++ b/drivers/nvmem/core.c
> > @@ -55,6 +55,7 @@ struct nvmem_cell {
> >   	struct device_node	*np;
> >   	struct nvmem_device	*nvmem;
> >   	struct list_head	node;
> > +	u32			flags;
> 
> This flag also needs to go in struct nvmem_cell_info too.

OK.

> >   };
> >
> >   static DEFINE_MUTEX(nvmem_mutex);
> > @@ -92,6 +93,26 @@ static int __nvmem_reg_write(struct nvmem_device
> *nvmem, unsigned int offset,
> >   	return -EINVAL;
> >   }
> >
> > +static int nvmem_buffer_reverse(void *bufaddr, int len) {
> > +	u8 *buf = (u8 *)bufaddr;
> > +	u8 *temp;
> > +	int i;
> > +
> > +	temp = kzalloc(len, GFP_KERNEL);
> > +	if (!temp)
> > +		return -ENOMEM;
> > +
> > +	memcpy(temp, buf, len);
> > +
> > +	for (i = 0; i < len; i++)
> > +		buf[i] = temp[len - i - 1];
> > +
> 
> You could possibly simplify this.
> 
> static void nvmem_buffer_reverse(u8 *buf, int len) {
> 	int i;
> 
> 	for (i = 0; i < len/2; i++)
> 		swap(buf[i], buf[len - i - 1]);
> }

Thanks.

> > +	kfree(temp);
> > +
> > +	return 0;
> > +}
> > +
> >   static int nvmem_access_with_keepouts(struct nvmem_device *nvmem,
> >   				      unsigned int offset, void *val,
> >   				      size_t bytes, int write)
> > @@ -705,6 +726,9 @@ static int nvmem_add_cells_from_of(struct
> nvmem_device *nvmem)
> >   		cell->bytes = be32_to_cpup(addr);
> >   		cell->name = kasprintf(GFP_KERNEL, "%pOFn", child);
> >
> > +		if (of_property_read_bool(child, "reverse-data"))
> > +			cell->flags |= NVMEM_FLAGS_REVERSE_DATA;
> > +
> >   		addr = of_get_property(child, "bits", &len);
> >   		if (addr && len == (2 * sizeof(u32))) {
> >   			cell->bit_offset = be32_to_cpup(addr++); @@ -1398,6
> +1422,12 @@
> > static int __nvmem_cell_read(struct nvmem_device *nvmem,
> >   	if (cell->bit_offset || cell->nbits)
> >   		nvmem_shift_read_buffer_in_place(cell, buf);
> >
> > +	if (cell->flags & NVMEM_FLAGS_REVERSE_DATA) {
> > +		rc = nvmem_buffer_reverse(buf, cell->bytes);
> > +		if (rc < 0)
> > +			return rc;
> > +	}
> > +
> >   	if (len)
> >   		*len = cell->bytes;
> >
> > diff --git a/include/linux/nvmem-provider.h
> > b/include/linux/nvmem-provider.h index 104505e9028f..364ac2a61b11
> > 100644
> > --- a/include/linux/nvmem-provider.h
> > +++ b/include/linux/nvmem-provider.h
> > @@ -31,6 +31,8 @@ enum nvmem_type {
> >   #define NVMEM_DEVID_NONE	(-1)
> >   #define NVMEM_DEVID_AUTO	(-2)
> >
> > +#define NVMEM_FLAGS_REVERSE_DATA	BIT(0)
> 
> Maybe NVMEM_FLAGS_REVERSE_BYTE_ORDER and some kerneldoc would
> help new users.

Yes, will rename it, could you please point me where nvmem kerneldoc there to add new info?

Best Regards,
Joakim Zhang
> --srini
> > +
> >   /**
> >    * struct nvmem_keepout - NVMEM register keepout range.
> >    *
> >

[PATCH V1 3/4] arm64: dts: imx8m: add "reverse-data" property for MAC ocopt

[Joakim Zhang]

Add "reverse-data" property for MAC ocopt device node to reverse MAC address.

Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 1 +
 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 1 +
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 1 +
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index e7648c3b8390..d4645fb87565 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -539,6 +539,7 @@
 
 				fec_mac_address: mac-address@90 {
 					reg = <0x90 6>;
+					reverse-data;
 				};
 			};
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index d4231e061403..4bc250682dc5 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -544,6 +544,7 @@
 
 				fec_mac_address: mac-address@90 {
 					reg = <0x90 6>;
+					reverse-data;
 				};
 			};
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 9f7c7f587d38..e4d879d82c28 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -358,6 +358,7 @@
 
 				eth_mac1: mac-address@90 {
 					reg = <0x90 6>;
+					reverse-data;
 				};
 			};
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 91df9c5350ae..e1eb8fa0d348 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -570,6 +570,7 @@
 
 				fec_mac_address: mac-address@90 {
 					reg = <0x90 6>;
+					reverse-data;
 				};
 			};
 
-- 
2.17.1

[PATCH V1 4/4] arm64: dts: imx8m: remove unused "nvmem_macaddr_swap" property for FEC

[Joakim Zhang]

Remove unused "nvmem_macaddr_swap" property for FEC, there is no info in both
dt-binding and driver, so it's safe to remove it.

Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
---
 arch/arm64/boot/dts/freescale/imx8mm.dtsi | 1 -
 arch/arm64/boot/dts/freescale/imx8mn.dtsi | 1 -
 arch/arm64/boot/dts/freescale/imx8mp.dtsi | 1 -
 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 1 -
 4 files changed, 4 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index d4645fb87565..6b1883b3560b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -947,7 +947,6 @@
 				fsl,num-rx-queues = <3>;
 				nvmem-cells = <&fec_mac_address>;
 				nvmem-cell-names = "mac-address";
-				nvmem_macaddr_swap;
 				fsl,stop-mode = <&gpr 0x10 3>;
 				status = "disabled";
 			};
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 4bc250682dc5..14fe0f766d5b 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -950,7 +950,6 @@
 				fsl,num-rx-queues = <3>;
 				nvmem-cells = <&fec_mac_address>;
 				nvmem-cell-names = "mac-address";
-				nvmem_macaddr_swap;
 				fsl,stop-mode = <&gpr 0x10 3>;
 				status = "disabled";
 			};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index e4d879d82c28..5baacb83e2f0 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -815,7 +815,6 @@
 				nvmem-cells = <&eth_mac1>;
 				nvmem-cell-names = "mac-address";
 				fsl,stop-mode = <&gpr 0x10 3>;
-				nvmem_macaddr_swap;
 				status = "disabled";
 			};
 
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index e1eb8fa0d348..c4e107061c89 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1190,7 +1190,6 @@
 				fsl,num-rx-queues = <3>;
 				nvmem-cells = <&fec_mac_address>;
 				nvmem-cell-names = "mac-address";
-				nvmem_macaddr_swap;
 				fsl,stop-mode = <&iomuxc_gpr 0x10 3>;
 				status = "disabled";
 			};
-- 
2.17.1