Messages in this thread | | | Date | Wed, 01 Dec 2021 15:30:37 +0100 | From | Michael Walle <> | Subject | Re: [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>; >> } >> >> ð0 { >> nvmem-cells = <&mac_addresses 0>; >> nvmem-cell-names = "mac-address"; >> }; >> >> ð1 { >> 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>; };
ð0 { nvmem-cells = <ðernet_base_mac 0>; nvmem-cell-names = "mac-address"; };
ð1 { nvmem-cells = <ðernet_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
| |