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]

Date:   Thu, 20 Jan 2022 13:42:25 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <geert@...ux-m68k.org>
CC:     <linus.walleij@...aro.org>, <bgolaszewski@...libre.com>,
        <robh+dt@...nel.org>, <jassisinghbrar@...il.com>,
        <paul.walmsley@...ive.com>, <palmer@...belt.com>,
        <aou@...s.berkeley.edu>, <a.zummo@...ertech.it>,
        <alexandre.belloni@...tlin.com>, <broonie@...nel.org>,
        <gregkh@...uxfoundation.org>, <thierry.reding@...il.com>,
        <u.kleine-koenig@...gutronix.de>, <lee.jones@...aro.org>,
        <linux-gpio@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-i2c@...r.kernel.org>,
        <linux-pwm@...r.kernel.org>, <linux-riscv@...ts.infradead.org>,
        <linux-crypto@...r.kernel.org>, <linux-rtc@...r.kernel.org>,
        <linux-spi@...r.kernel.org>, <linux-usb@...r.kernel.org>,
        <krzysztof.kozlowski@...onical.com>, <bin.meng@...driver.com>,
        <heiko@...ech.de>, <Lewis.Hanly@...rochip.com>,
        <Daire.McNamara@...rochip.com>, <Ivan.Griffin@...rochip.com>,
        <atishp@...osinc.com>
Subject: Re: [PATCH v4 03/14] dt-bindings: i2c: add bindings for microchip
 mpfs i2c

On 20/01/2022 08:30, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi Conor,
> 
> 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";
};

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?
> 
> 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
>