No, we should hit that use case to start with.I assume these cell nodes should be marked with some property that theyHonestly, this approach is a total hack to get it working.
Probably this might be fixed by lookup nvmem device too ?
This is what Am thinking which should look like:
## DT ##
eeprom_at24: at24@56 {
compatible = "atmel,24c32";
/* Some way to identify that this is a TLV data */
nvmem-cell-parser-name = "onie-tlv-cells";
reg = <0x56>;
mac_address: mac-address {
/* THIS REG is updated once TLV is parsed */
reg = <0 0x6>
};
should be evaluated later, so the cell will be not read
in case it was not parsed because it may
exist in nvmem device optionally.
before register.
Or, treat cells with length "0" in a special way and allow to update
cell info later.you can update irrespective of the length, as long as this is done
};I assume parser driver can just invoke add_cell_table (with may be
some_dev_node {
compatible = "xxx";
nvmem-cells = <&mac_address>;
nvmem-cell-names = "mac-address";
};
== CODE ==
ret = of_get_mac_address(dev->of_node, base_mac);
==========
If you notice the mac_address node reg is 0.
This node "reg" property should be updated ( using of_update_property())
by nvmem-provider driver while tlv parsing and by matching the node name
with tlv name.
by adding 'bool update' field to the cell_info struct) and core.c will just
update existing cells parsed from OF.
That way rest of the code will work as usual.
If this work for you then we can ask Rob if he foresee any issues in
this approach. I already see similar usage in reserved-memory case.