2022-02-11 15:23:58

by Rafał Miłecki

[permalink] [raw]
Subject: [PATCH V2 2/3] dt-bindings: nvmem: brcm,nvram: add NVMEM cell to example

From: Rafał Miłecki <[email protected]>

NVRAM doesn't have cells at hardcoded addresses. They are stored in
internal struct (custom & dynamic format) . It's still important to
define relevant cells in DT so NVMEM consumers can reference them.

One of cells set in almost every device is "et0macaddr" containing MAC
address. Add it to example to show how it can be referenced.

Signed-off-by: Rafał Miłecki <[email protected]>
---
V2: Add children nodes description per Rob's request
---
.../devicetree/bindings/nvmem/brcm,nvram.yaml | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
index 8c3f0cd22821..fc1df9d1c4d4 100644
--- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
+++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
@@ -27,11 +27,23 @@ properties:
reg:
maxItems: 1

+patternProperties:
+ ".*":
+ description: |
+ Each child node represents one NVRAM entry (variable). Node name has to
+ match variable name as internally defined in the NVRAM.
+
+ Some of common NVRAM variables are: "board_id", "boardflags", "boot_wait",
+ "clkfreq", "et0macaddr", "sdram_config", "wait_time".
+
unevaluatedProperties: false

examples:
- |
nvram@1eff0000 {
- compatible = "brcm,nvram";
- reg = <0x1eff0000 0x10000>;
+ compatible = "brcm,nvram";
+ reg = <0x1eff0000 0x10000>;
+
+ mac: et0macaddr {
+ };
};
--
2.34.1



2022-02-18 00:38:06

by Rob Herring (Arm)

[permalink] [raw]
Subject: Re: [PATCH V2 2/3] dt-bindings: nvmem: brcm,nvram: add NVMEM cell to example

On Fri, Feb 11, 2022 at 02:05:53PM +0100, Rafał Miłecki wrote:
> From: Rafał Miłecki <[email protected]>
>
> NVRAM doesn't have cells at hardcoded addresses. They are stored in
> internal struct (custom & dynamic format) . It's still important to
> define relevant cells in DT so NVMEM consumers can reference them.
>
> One of cells set in almost every device is "et0macaddr" containing MAC
> address. Add it to example to show how it can be referenced.
>
> Signed-off-by: Rafał Miłecki <[email protected]>
> ---
> V2: Add children nodes description per Rob's request
> ---
> .../devicetree/bindings/nvmem/brcm,nvram.yaml | 16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
> index 8c3f0cd22821..fc1df9d1c4d4 100644
> --- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml
> @@ -27,11 +27,23 @@ properties:
> reg:
> maxItems: 1
>
> +patternProperties:
> + ".*":

This doesn't really work as a schema as it matches every property or
child node.

> + description: |
> + Each child node represents one NVRAM entry (variable). Node name has to
> + match variable name as internally defined in the NVRAM.
> +
> + Some of common NVRAM variables are: "board_id", "boardflags", "boot_wait",
> + "clkfreq", "et0macaddr", "sdram_config", "wait_time".

I meant documenting these as schema, not just in a description:

properties:
board_id:
type: object
description: ...

board_flags:
type: object
description: ...

I'm guessing making this list exhaustive is not possible?

> +
> unevaluatedProperties: false

type: object

To say anything else must be a child node.

>
> examples:
> - |
> nvram@1eff0000 {
> - compatible = "brcm,nvram";
> - reg = <0x1eff0000 0x10000>;
> + compatible = "brcm,nvram";
> + reg = <0x1eff0000 0x10000>;
> +
> + mac: et0macaddr {
> + };
> };
> --
> 2.34.1
>
>