linux-kernel - Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD Pensando Elba System Resource chip

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]

Message-ID: <20220822142544.GA3770388-robh@kernel.org>
Date:   Mon, 22 Aug 2022 09:25:44 -0500
From:   Rob Herring <robh@...nel.org>
To:     Brad Larson <brad@...sando.io>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-mmc@...r.kernel.org, adrian.hunter@...el.com,
        alcooperx@...il.com, andy.shevchenko@...il.com, arnd@...db.de,
        blarson@....com, brijeshkumar.singh@....com,
        catalin.marinas@....com, gsomlo@...il.com, gerg@...ux-m68k.org,
        krzk@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        lee.jones@...aro.org, broonie@...nel.org,
        yamada.masahiro@...ionext.com, p.zabel@...gutronix.de,
        piotrs@...ence.com, p.yadav@...com, rdunlap@...radead.org,
        samuel@...lland.org, fancer.lancer@...il.com,
        suravee.suthikulpanit@....com, thomas.lendacky@....com,
        ulf.hansson@...aro.org, will@...nel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v6 06/17] dt-bindings: mfd: amd,pensando-elbasr: Add AMD
 Pensando Elba System Resource chip

On Sat, Aug 20, 2022 at 12:57:39PM -0700, Brad Larson wrote:
> From: Brad Larson <blarson@....com>
> 
> Add support for the AMD Pensando Elba SoC System Resource chip
> using the SPI interface.  The Elba SR is a Multi-function Device
> supporting device register access using CS0, smbus interface for
> FRU and board peripherals using CS1, dual Lattice I2C masters for
> transceiver management using CS2, and CS3 for flash access.
> 
> Signed-off-by: Brad Larson <blarson@....com>
> ---
>  .../bindings/mfd/amd,pensando-elbasr.yaml     | 97 +++++++++++++++++++
>  1 file changed, 97 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
> 
> diff --git a/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml b/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
> new file mode 100644
> index 000000000000..ded347c3352c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/amd,pensando-elbasr.yaml
> @@ -0,0 +1,97 @@
> +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/amd,pensando-elbasr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: AMD Pensando Elba SoC Resource Controller bindings
> +
> +description: |
> +  AMD Pensando Elba SoC Resource Controller is a set of
> +  miscellaneous control/status registers accessed on CS0,
> +  a designware i2c master/slave on CS1, a Lattice rd1173
> +  dual i2c master on CS2, and flash on CS3.  The /dev interfaces
> +  created are /dev/pensr0.<CS>.  Hardware reset of the eMMC

/dev is a Linux thing and not relevant for the bindings.

> +  is implemented by a sub-device reset-controller which accesses
> +  a CS0 control register.
> +
> +maintainers:
> +  - Brad Larson <blarson@....com>
> +
> +properties:
> +  compatible:
> +    items:
> +      - enum:
> +          - amd,pensando-elbasr
> +
> +  spi-max-frequency:
> +    description: Maximum SPI frequency of the device in Hz.

No need for generic descriptions of common properties.
> +
> +  reg:
> +    maxItems: 1
> +
> +  '#address-cells':
> +    const: 1
> +
> +  '#size-cells':
> +    const: 0
> +
> +  interrupts:
> +    maxItems: 1
> +
> +required:
> +  - compatible
> +  - reg
> +  - spi-max-frequency
> +
> +patternProperties:
> +  '^reset-controller@[a-f0-9]+$':
> +    $ref: /schemas/reset/amd,pensando-elbasr-reset.yaml
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +    spi {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +        num-cs = <4>;
> +
> +        sysc: system-controller@0 {
> +            compatible = "amd,pensando-elbasr";
> +            reg = <0>;
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +            spi-max-frequency = <12000000>;
> +
> +            rstc: reset-controller@0 {
> +                compatible = "amd,pensando-elbasr-reset";
> +                reg = <0>;

What does 0 represent here? A register address within 'elbasr' device?

Why do you need a child node for this? Are there other sub-devices and 
your binding is incomplete? Just put '#reset-cells' in the parent.

> +                #reset-cells = <1>;
> +            };
> +        };
> +
> +        i2c1: i2c@1 {
> +            compatible = "amd,pensando-elbasr";

You can't reuse the same compatible to represent different things.


> +            reg = <1>;
> +            spi-max-frequency = <12000000>;
> +        };
> +
> +        i2c2: i2c@2 {
> +            compatible = "amd,pensando-elbasr";

As this is a Lattice RD1173, I would expect a compatible based on that.


> +            reg = <2>;
> +            spi-max-frequency = <12000000>;
> +            interrupt-parent = <&porta>;
> +            interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
> +        };
> +
> +        flash@3 {
> +            compatible = "amd,pensando-elbasr";

Isn't this a flash device?

> +            reg = <3>;
> +            spi-max-frequency = <12000000>;
> +        };
> +    };
> +
> +...
> -- 
> 2.17.1
> 
>