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

[Joakim Zhang]

> -----Original Message-----
> From: Rob Herring <robh@xxxxxxxxxx>
> Sent: 2021年8月18日 3:58
> To: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx>
> Cc: Joakim Zhang <qiangqing.zhang@xxxxxxx>; shawnguo@xxxxxxxxxx;
> kernel@xxxxxxxxxxxxxx; dl-linux-imx <linux-imx@xxxxxxx>;
> devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> 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@xxxxxxx>
> > > ---
> > >   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