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 for Android: free password hash cracker in your pocket

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

Message-ID: <Op5n9imM72IZnLCmMZ8lEZ7GxZD-r4cYZDB6zF0DcNNRu5dwpGEgi7PyjsAfQFnTMEtB8DTS76wLNWcnTtfDMUa1KDZYO3_geq-oOVXOr50=@conchuod.ie>
Date:   Thu, 20 Jan 2022 15:42:06 +0000
From:   conor dooley <mail@...chuod.ie>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Conor Dooley <Conor.Dooley@...rochip.com>,
        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:
>> > 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.
A lot (but not all) of the peripherals on Polarfire SoC are "subsets"
of the IP cores: I think corei2c is almost identical but for others
the hard version has some of the optional features disabled or slight
changes made.

If the IP is already written why not use it ;)
>
>> 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.
Fair enough!
>
>> > 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).