lkml.org 
[lkml]   [2021]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] dt-bindings: nvmem: add transformation support
Hi Srinivas,

Am 2021-11-29 13:54, schrieb Srinivas Kandagatla:
> On 23/11/2021 13:44, Michael Walle wrote:
>> This is my second attempt to solve the use case where there is only
>> the
>> base MAC address stored in an EEPROM or similar storage provider. This
>> is the case for the Kontron sl28 board and multiple openwrt supported
>> boards.
>>
>> The first proposal [1] didn't find much appreciation and there wasn't
>> any reply to my question or new proposal [2]. So here we are with my
>> new
>> proposal, that is more flexible and doesn't fix the ethernet mac only.
>> This is just an RFC for the device tree representation for now to see
>> if
>> this is the correct way to tackle this.
>>
>> I'm also aware of the latest post process hook support [3]. This
>> doesn't
>> fix the base mac address issue, but I think it also doesn't solve the
>> case with swapped ethernet addresses in the general case. That hook
>> will
>> involve the driver to do the swapping, but how would the driver know
>> if that swapping is actually required. Usually the interpretation of
>> the
>> content is opaque to the driver, after all it is the user/board
>
> But this is the path for any post processing hook, which ever
> direction we endup with(using core helpers or provider specific
> post-processing).

Mh? I don't understand. My point was that the driver is unlikely
to know what it should process. Take the mtd (or the mtd otp)
nvmem provider for example. If I understand it correctly, it just
gets the nvmem name, for example, "mac-address". How should
the post process hook know, what it should do? IMHO that just
works for very specific drivers, which tied to the content
they provide.

>> manufacturer who does program the storage device. We might be lucky in
>> the imx-ocotp case because the IMX reference manual actually states
>> where and in which format the mac address is programmed.
>>
>> Introduce a transformation property. This is intended to be just an
>> enumeration of operations. If there will be a new operation, support
>> for
>> it has to be added to the nvmem core.
>>
>> A transformation might have multiple output values, like in the base
>> mac
>> address case. It reads the mac address from the nvmem storage and
>> generates multiple individual addresses, i.e. on our board we reserve
>> 8
>> consecutive addresses. These addresses then can be assigned to
>> different
>> network interfaces. To make it possible to reference different values
>> we
>> need to introduce an argument to the phandle. This additional argument
>> is then an index into a list of values.
>>
>> Example:
>> mac_addresses: base-mac-address@10 {
>> #nvmem-cell-cells = <1>;
>> reg = <10 6>;
>> transformation = <NVMEM_T_ETH_OFFSET 0 1 7>;
>
> IMO, this is totally redundant. we could probably encode this info
> directly in the cell specifiers, something like:
>
>> }
>>
>> &eth0 {
>> nvmem-cells = <&mac_addresses 0>;
>
> nvmem-cells = <&base_mac_addresses NVMEM_T_ETH_OFFSET 0>;

I had he same idea, but keep in mind, that there could be more
than just one nvmem cells:

nvmem-cells = <&phandle1 arg1 &pandle2 arg2 arg3>;
nvmem-cell-names = "name1", "name2";

So you'd need the #nvmem-cell-cells either way.

> And value of #nvmem-cell-cells is dependent on the first cell
> specifier.

What do you mean with first cell specifier? the phandle
(base_mac_address
in the example) or the NVMEM_T_ETH_OFFSET? I guess the latter, because
the
arguments depend on the transformation. But this is not how the
of_parse_phandle_with_args() works, it will look the '#nvmem-cell-cells'
property up, to see how many arguments it should expect, which is a
property to the referenced node. Thus I've come up with the additional
indirection. The number of arguments for the reference cell is either
0 or 1 and the transformation is part of the nvmem cell.

> I understand that these 3 bits of info is required for this type of
> post processing and this can only come from DT and its not possible to
> determine this at runtime.

ok :)

> Would this address other usecases?

I think so, but see above for why it can't work. Or I am missing
something.

> Are you in a position to test few of them?

Sure (at least after my vacation). And TBH I think the imxotp mac
swap should use the same or it will be likely that there are future
SoCs which will always swap the ethnet

> Lets wait for Rob's opinion on adding #nvmem-cell-cells property with
> cell specifiers describing the encoding information?

+1

Thanks for looking into this,
-michael

\
 
 \ /
  Last update: 2021-11-29 23:40    [W:0.095 / U:1.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site