Messages in this thread | | | Date | Mon, 29 Nov 2021 18:43:45 +0100 | From | Michael Walle <> | Subject | Re: [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: > >> } >> >> ð0 { >> 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
| |