LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Srinivas Kandagatla <firstname.lastname@example.org>
To: Joakim Zhang <email@example.com>, Rob Herring <firstname.lastname@example.org>
Cc: "email@example.com" <firstname.lastname@example.org>,
Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data" property
Date: Fri, 3 Sep 2021 13:37:59 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
On 18/08/2021 08:54, Joakim Zhang wrote:
>> -----Original Message-----
>> From: Rob Herring <firstname.lastname@example.org>
>> Sent: 2021年8月18日 3:58
>> To: Srinivas Kandagatla <email@example.com>
>> Cc: Joakim Zhang <firstname.lastname@example.org>; email@example.com;
>> firstname.lastname@example.org; dl-linux-imx <email@example.com>;
>> firstname.lastname@example.org; email@example.com
>> Subject: Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data"
>> 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 <firstname.lastname@example.org>
>>>> Documentation/devicetree/bindings/nvmem/nvmem.yaml | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>> diff --git a/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:
>>>> 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)
>>> 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
> 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
- 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.
- 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.
- provider driver does not need to implement callbacks
- 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?
> Best Regards,
> Joakim Zhang
next prev parent reply other threads:[~2021-09-03 12:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-10 7:35 [PATCH V1 0/4] " Joakim Zhang
2021-08-10 7:35 ` [PATCH V1 1/4] bindings: " Joakim Zhang
2021-08-10 15:14 ` Jan Lübbe
2021-08-11 8:05 ` Joakim Zhang
2021-08-11 8:06 ` Joakim Zhang
2021-08-11 9:05 ` Jan Lübbe
2021-08-11 10:16 ` Srinivas Kandagatla
2021-08-17 19:58 ` Rob Herring
2021-08-18 7:54 ` Joakim Zhang
2021-08-24 6:31 ` Joakim Zhang
2021-09-03 12:37 ` Srinivas Kandagatla [this message]
2021-09-06 8:58 ` Joakim Zhang
2021-09-07 10:11 ` Srinivas Kandagatla
2021-09-08 7:14 ` Joakim Zhang
2021-09-08 8:48 ` Srinivas Kandagatla
2021-09-08 8:57 ` Joakim Zhang
2021-09-08 9:21 ` Srinivas Kandagatla
2021-08-10 7:35 ` [PATCH V1 2/4] nvmem: core: introduce "reverse-data" property to reverse buffer Joakim Zhang
2021-08-11 9:52 ` Srinivas Kandagatla
2021-08-11 10:16 ` Joakim Zhang
2021-08-10 7:35 ` [PATCH V1 3/4] arm64: dts: imx8m: add "reverse-data" property for MAC ocopt Joakim Zhang
2021-08-10 7:35 ` [PATCH V1 4/4] arm64: dts: imx8m: remove unused "nvmem_macaddr_swap" property for FEC Joakim Zhang
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH V1 1/4] bindings: nvmem: introduce "reverse-data" property' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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).