Am 2022-08-31 09:45, schrieb Krzysztof Kozlowski:
On 26/08/2022 00:44, Michael Walle wrote:
Add a schema for the NVMEM layout on Kontron's sl28 boards.
Signed-off-by: Michael Walle <michael@xxxxxxxx>
---
.../nvmem/layouts/kontron,sl28-vpd.yaml | 52
+++++++++++++++++++
1 file changed, 52 insertions(+)
create mode 100644
Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
diff --git
a/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
new file mode 100644
index 000000000000..e4bc2d9182db
--- /dev/null
+++
b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id:
http://devicetree.org/schemas/nvmem/layouts/kontron,sl28-vpd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of the Kontron SMARC-sAL28 vital product data
+
+maintainers:
+ - Michael Walle <michael@xxxxxxxx>
+
+description:
+ The vital product data (VPD) of the sl28 boards contains a serial
+ number and a base MAC address. The actual MAC addresses for the
+ on-board ethernet devices are derived from this base MAC address by
+ adding an offset.
+
+properties:
+ compatible:
+ items:
+ - const: kontron,sl28-vpd
+ - const: user-otp
+
+ serial-number:
+ type: object
You should define the contents of this object. I would expect this to
be
uint32 or string. I think you also need description, as this is not
really standard field.
First thing, this binding isn't like the usual ones, so it might be
totally wrong.
What I'd like to achieve here is the following:
We have the nvmem-consumer dt binding where you can reference a
nvmem cell in a consumer node. Example:
nvmem-cells = <&base_mac_address 5>;
nvmem-cell-names = "mac-address";
On the other end of the link we have the nvmem-provider. The dt
bindings works well if that one has individual cell nodes, like
it is described in the nvmem.yaml binding. I.e. you can give the
cell a label and make a reference to it in the consumer just like
in the example above.
Now comes the catch: what if there is no actual description of the
cell in the device tree, but is is generated during runtime. How
can I get a label to it. Therefore, in this case, there is just
an empty node and the driver will associate it with the cell
created during runtime (see patch 10). It is not expected, that
is has any properties.
+
+ base-mac-address:
Fields should be rather described here, not in top-level description.
+ type: object
On this level:
additionalProperties: false
+
+ properties:
+ "#nvmem-cell-cells":
+ const: 1
+
I also wonder why you do not have unit addresses. What if you want to
have two base MAC addresses?
That would describe an offset within the nvmem device. But the offset
might not be constant, depending on the content. My understanding
so far was that in that case, you use the "-N" suffix.
base-mac-address-1
base-mac-address-2
(or maybe completely different names).
+required:
+ - compatible
Other fields are I guess required? At least serial-number should be
always?
Yes I could add them to the required list, but they are only
"required" if you need to reference them within the device tree, in
which
case there have to be there anyway. IOW, the driver doesn't care if
there is a node. If there is none, it doesn't set the "struct
device_node*"
in the nvmem cell.
+
+additionalProperties: false
+
+examples:
+ - |
+ otp-1 {
Messed up indentation (use 4 spaces). Generic node name "otp".
+ compatible = "kontron,sl28-vpd", "user-otp";
+
+ serial_number: serial-number {
What's the point of the empty node?
See above.
-michael
+ };
+
+ base_mac_address: base-mac-address {
+ #nvmem-cell-cells = <1>;
+ };
+ };
+
+...
