From: Rafał Miłecki <rafal@xxxxxxxxxx> Michael has recently posted a cleaned up patchset for NVMEM transformations support: [PATCH 0/8] nvmem: add ethernet address offset support https://lore.kernel.org/lkml/20211228142549.1275412-1-michael@xxxxxxxx/T/ https://patchwork.ozlabs.org/project/linux-mtd/list/?series=278644&state=* I find it very important & fully support it. In home routers we very often deal with just one MAC address that: 1. Is a base for calculating multiple Ethernet addresses 2. Can be stored in binary as well as ASCII format I'd like to suggest just a slightly different solution though. I think that using something like: otp-1 { compatible = "kontron,sl28-vpd", "user-otp"; #address-cells = <1>; #size-cells = <1>; base_mac_address: base-mac-address@17 { #nvmem-cell-cells = <1>; reg = <17 6>; }; }; isn't clear enough and requires too much conditional code in Linux / whatever implementation. DT doesn't make it clear which NVMEM cells are used for what and how should be handled. That has to be hardcoded in a Linux / whatever driver. My idea is to add "compatible" & additional flags to NVMEM cells. Example: otp-1 { compatible = "user-otp"; #address-cells = <1>; #size-cells = <1>; base_mac_address: base-mac-address@17 { compatible = "mac-address"; reg = <17 6>; #nvmem-cell-cells = <1>; }; }; (for more examples see PATCH 2/2 and its mac-address.yaml . Rafał Miłecki (2): dt-bindings: nvmem: extract NVMEM cell to separated file dt-bindings: nvmem: cells: add MAC address cell .../devicetree/bindings/nvmem/cells/cell.yaml | 35 +++++++ .../bindings/nvmem/cells/mac-address.yaml | 94 +++++++++++++++++++ .../devicetree/bindings/nvmem/nvmem.yaml | 25 +---- 3 files changed, 131 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/nvmem/cells/cell.yaml create mode 100644 Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml -- 2.31.1
