linux-kernel - Re: [PATCH v4 03/14] dt-bindings: i2c: add bindings for microchip mpfs i2c

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: <CAMuHMdXU_M89W7w064YsjuFfqE2m_PeM9HVps0nmaC1+aUHAQw@mail.gmail.com>
Date:   Thu, 20 Jan 2022 15:56:46 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Conor Dooley <Conor.Dooley@...rochip.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Rob Herring <robh+dt@...nel.org>,
        Jassi Brar <jassisinghbrar@...il.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Mark Brown <broonie@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>, Lee Jones <lee.jones@...aro.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        Linux PWM List <linux-pwm@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-rtc@...r.kernel.org, linux-spi <linux-spi@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Bin Meng <bin.meng@...driver.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Lewis Hanly <Lewis.Hanly@...rochip.com>,
        Daire.McNamara@...rochip.com, Ivan.Griffin@...rochip.com,
        Atish Patra <atishp@...osinc.com>
Subject: Re: [PATCH v4 03/14] dt-bindings: i2c: add bindings for microchip
 mpfs i2c

Hi Conor,

On Thu, Jan 20, 2022 at 2:42 PM <Conor.Dooley@...rochip.com> wrote:
> On 20/01/2022 08:30, Geert Uytterhoeven wrote:
> > On Mon, Jan 17, 2022 at 12:06 PM <conor.dooley@...rochip.com> wrote:
> >> From: Conor Dooley <conor.dooley@...rochip.com>
> >>
> >> Add device tree bindings for the i2c controller on
> >> the Microchip PolarFire SoC.
> >>
> >> Signed-off-by: Daire McNamara <daire.mcnamara@...rochip.com>
> >> Signed-off-by: Conor Dooley <conor.dooley@...rochip.com>
> >
> > Thanks for your patch!
> >
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/i2c/microchip,mpfs-i2c.yaml
> >> @@ -0,0 +1,55 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/i2c/microchip,mpfs-i2c.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Microchip MPFS I2C Controller Device Tree Bindings
> >> +
> >> +maintainers:
> >> +  - Daire McNamara <daire.mcnamara@...rochip.com>
> >> +
> >> +allOf:
> >> +  - $ref: /schemas/i2c/i2c-controller.yaml#
> >> +
> >> +properties:
> >> +  compatible:
> >> +    enum:
> >> +      - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs
> >> +      - microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core
> >
> > Wouldn't it be more logical to have:
> >
> >      items:
> >        - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs
> >        - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core
> >
> > ?
> This would be fine for mpfs-i2c since corei2c is a "superset" - but how
> would that look for the fabric core? I don't think falling back from the
> fabric core onto the "hard" one makes sense. This would mean the
> following two entries:
>
> i2c2: i2c@...00000 { //fabric
>         compatible = "microchip,corei2c-rtl-v7";
> };
> i2c1: i2c@...0b000 { //"hard" mpfs peripheral
>         compatible = "microchip,mpfs-i2c", "microchip,corei2c-rtl-v7";
> };

Oops, I missed that you have both forms.
But in se, they're the same IP core, just hard vs. soft? Then the
below makes sense.

> But this generates errors in dt_binding_check w/ your suggestion - so
> how about the following (similar to ti,omap4-i2c.yaml):
>
>    compatible:
>      oneOf:
>        - items:
>          - const: microchip,mpfs-i2c #  Microchip PolarFire...
>          - const: microchip,corei2c-rtl-v7 # Microchip Fabric...
>        - const: microchip,corei2c-rtl-v7 # Microchip Fabric...
>
> Is there a prettier way than this duplication?

I'm afraid not, and the above scheme is used a lot.

> > If the IP core is reused, it can become:
> >
> >      items:
> >        - enum:
> >            - microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs
> >            - microchip,<foo>-i2c # ...
> >        - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core
> >
> > That way the driver can just match on the second (fallback) value,
> > and no further driver changes will be needed (until v8 or later).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds