Messages in this thread | | | Date | Fri, 25 Feb 2022 10:07:20 +0100 | Subject | Re: [PATCH REBASED 2/2] dt-bindings: nvmem: cells: add MAC address cell | From | Rafał Miłecki <> |
| |
On 1.02.2022 18:01, Michael Walle wrote: > Am 2022-02-01 16:55, schrieb Rob Herring: >> On Wed, Jan 26, 2022 at 08:07:45AM +0100, Rafał Miłecki wrote: >>> From: Rafał Miłecki <rafal@milecki.pl> >>> >>> This adds support for describing details of NVMEM cell containing MAC >>> address. Those are often device specific and could be nicely stored in >>> DT. >>> >>> Initial documentation includes support for describing: >>> 1. Cell data format (e.g. Broadcom's NVRAM uses ASCII to store MAC) >>> 2. Reversed bytes flash (required for i.MX6/i.MX7 OCOTP support) >>> 3. Source for multiple addresses (very common in home routers) >>> >>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl> >>> --- >>> .../bindings/nvmem/cells/mac-address.yaml | 94 +++++++++++++++++++ >>> 1 file changed, 94 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml b/Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml >>> new file mode 100644 >>> index 000000000000..f8d19e87cdf0 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml >>> @@ -0,0 +1,94 @@ >>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/nvmem/cells/mac-address.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: NVMEM cell containing a MAC address >>> + >>> +maintainers: >>> + - Rafał Miłecki <rafal@milecki.pl> >>> + >>> +properties: >>> + compatible: >>> + const: mac-address >>> + >>> + format: >>> + description: | >>> + Some NVMEM cells contain MAC in a non-binary format. >>> + >>> + ASCII should be specified if MAC is string formatted like: >>> + - "01:23:45:67:89:AB" (30 31 3a 32 33 3a 34 35 3a 36 37 3a 38 39 3a 41 42) >>> + - "01-23-45-67-89-AB" >>> + - "0123456789AB" >>> + enum: >>> + - ascii >>> + >>> + reversed-bytes: >>> + type: boolean >>> + description: | >>> + MAC is stored in reversed bytes order. Example: >>> + Stored value: AB 89 67 45 23 01 >>> + Actual MAC: 01 23 45 67 89 AB >>> + >>> + base-address: >>> + type: boolean >>> + description: | >>> + Marks NVMEM cell as provider of multiple addresses that are relative to >>> + the one actually stored physically. Respective addresses can be requested >>> + by specifying cell index of NVMEM cell. >> >> While a base address is common, aren't there different ways the base is >> modified. >> >> The problem with these properties is every new variation results in a >> new property and the end result is something not well designed. A unique >> compatible string, "#nvmem-cell-cells" and code to interpret the data is >> more flexible. > > I actually like having a unique compatible for anything but the basic > operations. For example, the sl28 vpd area also has a checksum, which > could be handled if there is an own compatible. I don't think this is > possible with this proposal. Also there is a version field, what if > we change the layout of that thing? Am I supposed to change the > device tree? The more I think about Rob's proposal to have a compatible > the more I like it.
Having more detailed binding for cells doesn't stop you from using NVMEM device specific binding.
You could have e.g.
partition@f00000 { compatible = "foo,foo-cells", "nvmem-cells"; (...)
mac@100 { compatible = "mac-address"; reg = <0x100 0x6>; };
OR
mac@100 { compatible = "mac-address"; reg = <0x100 0x11>; format = "ascii"; }; };
Then you can have "foo,foo-cells" driver handling checksum.
I'm not saying we have to use this solution, just saying it's possible.
| |