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@xxxxxxxxxx>
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@xxxxxxxxxx>
---
.../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@xxxxxxxxxx>
+
+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.
