lkml.org 
[lkml]   [2021]   [Dec]   [1]   [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 Rob,

Am 2021-11-30 20:19, schrieb Rob Herring:
> On Tue, Nov 23, 2021 at 02:44:25PM +0100, Michael Walle wrote:
..

>> 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.
>
> I still don't think trying to encode transformations of data into the
> DT
> is right approach.
>
>>
>> Example:
>> mac_addresses: base-mac-address@10 {
>> #nvmem-cell-cells = <1>;
>> reg = <10 6>;
>> transformation = <NVMEM_T_ETH_OFFSET 0 1 7>;
>> }
>>
>> &eth0 {
>> nvmem-cells = <&mac_addresses 0>;
>> nvmem-cell-names = "mac-address";
>> };
>>
>> &eth1 {
>> nvmem-cells = <&mac_addresses 2>;
>> nvmem-cell-names = "mac-address";
>> };
>>
>> The NVMEM_T_ETH_OFFSET transformation takes N additional (dt) cells
>> and
>> will generate N values. In this example BASE_MAC+0, BASE_MAC+1,
>> BASE_MAC+7.
>> An nvmem consumer can then reference the nvmem cell with an index. So
>> eth0
>> will get BASE_MAC+0 and eth1 will get BASE_MAC+7.
>>
>> This should be sufficient flexible for many different transformations
>> without having to touch the bindings except for adding documentation
>> and
>> checks for new transformations.
>
> The content and number of cells is supposed to be opaque to the client
> and interpreted by the provider. That's sort of true here, but not
> really because the interpretation is tied to 'transformation'. So I'm
> okay with adding cells, but not fixing the interpretation of them. A
> compatible should determine how the cells are interpreted.

What do you mean by "adding cells"? The additional argument to the
phandle?

So an example would be:

ethernet_base_mac: base-mac-address@100 {
#nvmem-cell-cells = <1>;
compatible = "nvmem-ethernet-address";
reg = <0x100 0x6>;
};

&eth0 {
nvmem-cells = <&ethernet_base_mac 0>;
nvmem-cell-names = "mac-address";
};

&eth1 {
nvmem-cells = <&ethernet_base_mac 7>;
nvmem-cell-names = "mac-address";
};

Right? Any suggestions for a better compatible name?

>> I do have one question regarding "#nvmem-cell-cells" (aside from the
>> awkward naming): is it allowed to have that property optional if there
>> is no additional argument to the phandle?
>
> We don't have any choice if we add "#nvmem-cell-cells". There's already
> cases without it.

Yes, that was the reason for the question. But I wasn't sure, whether
that is allowed.

-michael

\
 
 \ /
  Last update: 2021-12-01 15:31    [W:2.027 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site