linux-kernel - Re: [PATCH v3 02/10] dt-bindings: sram: Convert Samsung Exynos SYSRAM bindings to json-schema

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, 10 Oct 2019 14:33:56 -0500
From:   Rob Herring <robh@...nel.org>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     Mark Rutland <mark.rutland@....com>, Kukjin Kim <kgene@...nel.org>,
        Benoît Cousson <bcousson@...libre.com>,
        Tony Lindgren <tony@...mide.com>,
        Jason Cooper <jason@...edaemon.net>,
        Andrew Lunn <andrew@...n.ch>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-tegra@...r.kernel.org
Subject: Re: [PATCH v3 02/10] dt-bindings: sram: Convert Samsung Exynos
 SYSRAM bindings to json-schema

On Wed, Oct 02, 2019 at 06:43:08PM +0200, Krzysztof Kozlowski wrote:
> Convert Samsung Exynos SYSRAM bindings to DT schema format using
> json-schema.
> 
> Signed-off-by: Krzysztof Kozlowski <krzk@...nel.org>
> 
> ---
> 
> Changes since v2:
> 1. Use sram as name of node in example.
> 
> Changes since v1:
> 1. Indent example with four spaces (more readable).
> ---
>  .../devicetree/bindings/sram/samsung-sram.txt | 38 ------------
>  .../bindings/sram/samsung-sram.yaml           | 58 +++++++++++++++++++
>  MAINTAINERS                                   |  2 +-
>  3 files changed, 59 insertions(+), 39 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/sram/samsung-sram.txt
>  create mode 100644 Documentation/devicetree/bindings/sram/samsung-sram.yaml


> diff --git a/Documentation/devicetree/bindings/sram/samsung-sram.yaml b/Documentation/devicetree/bindings/sram/samsung-sram.yaml
> new file mode 100644
> index 000000000000..3e77c434ecca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sram/samsung-sram.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sram/samsung-sram.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung Exynos SoC SYSRAM for SMP bringup
> +
> +maintainers:
> +  - Krzysztof Kozlowski <krzk@...nel.org>
> +
> +description: |+
> +  Samsung SMP-capable Exynos SoCs use part of the SYSRAM for the bringup
> +  of the secondary cores. Once the core gets powered up it executes the
> +  code that is residing at some specific location of the SYSRAM.
> +
> +  Therefore reserved section sub-nodes have to be added to the mmio-sram
> +  declaration. These nodes are of two types depending upon secure or
> +  non-secure execution environment.
> +
> +allOf:
> +  - $ref: "sram.yaml#"
> +
> +properties:
> +  $nodename:
> +    pattern: "^sysram(@.*)?"

As you are renaming all the node names, this will no longer work. If you 
change it to 'sram', that's going to match others, but would still work 
as long as the child node names are unique to Samsung. If you change 
them to '*-sram' then, you'd have to come up with something else. That 
probably means using 'compatible' strings. At that point, it's kind of 
silly to just be validating what your are using to select the schema. It 
may be better to just add the compatible strings into sram.yaml if 
that's the only difference.

> +
> +patternProperties:
> +  "^([a-z]*-)?sysram@[a-f0-9]$":
> +    type: object
> +
> +    properties:
> +      compatible:
> +        description:
> +          Depending upon boot mode
> +        enum:
> +          - samsung,exynos4210-sysram                 # for Secure SYSRAM
> +          - samsung,exynos4210-sysram-ns              # for Non-secure SYSRAM
> +