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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 Feb 2022 17:58:16 -0600
From:   Rob Herring <robh@...nel.org>
To:     Rafał Miłecki <zajec5@...il.com>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        bcm-kernel-feedback-list@...adcom.com, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Rafał Miłecki <rafal@...ecki.pl>
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 <rafal@...ecki.pl>
> 
> 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 <rafal@...ecki.pl>
> ---
> 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@...f0000 {
> -            compatible = "brcm,nvram";
> -            reg = <0x1eff0000 0x10000>;
> +        compatible = "brcm,nvram";
> +        reg = <0x1eff0000 0x10000>;
> +
> +        mac: et0macaddr {
> +        };
>      };
> -- 
> 2.34.1
> 
>