linux-kernel - Re: [PATCH 15/21] dt-bindings: irqchip/atmel-aic5: Add support for sam9x7 aic

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: <4d3694b3-8728-42c1-8497-ae38134db37c@app.fastmail.com>
Date:   Sun, 04 Jun 2023 11:49:48 +0200
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Conor Dooley" <conor@...nel.org>,
        "Varshini Rajendran" <varshini.rajendran@...rochip.com>
Cc:     "Thomas Gleixner" <tglx@...utronix.de>,
        "Marc Zyngier" <maz@...nel.org>,
        "Rob Herring" <robh+dt@...nel.org>,
        krzysztof.kozlowski+dt@...aro.org,
        "Conor Dooley" <conor+dt@...nel.org>,
        "Nicolas Ferre" <nicolas.ferre@...rochip.com>,
        "Alexandre Belloni" <alexandre.belloni@...tlin.com>,
        "Claudiu Beznea" <claudiu.beznea@...rochip.com>,
        "David S . Miller" <davem@...emloft.net>,
        "Eric Dumazet" <edumazet@...gle.com>,
        "Jakub Kicinski" <kuba@...nel.org>,
        "Paolo Abeni" <pabeni@...hat.com>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Russell King" <linux@...linux.org.uk>,
        "Michael Turquette" <mturquette@...libre.com>,
        "Stephen Boyd" <sboyd@...nel.org>,
        "Sebastian Reichel" <sre@...nel.org>,
        "Mark Brown" <broonie@...nel.org>,
        "Gregory Clement" <gregory.clement@...tlin.com>,
        "Sudeep Holla" <sudeep.holla@....com>,
        "Balamanikandan Gunasundar" <balamanikandan.gunasundar@...rochip.com>,
        mihai.sain@...rochip.com, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Netdev <netdev@...r.kernel.org>, linux-usb@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-pm@...r.kernel.org,
        Hari.PrasathGE@...rochip.com, cristian.birsan@...rochip.com,
        durai.manickamkr@...rochip.com, manikandan.m@...rochip.com,
        dharma.b@...rochip.com, nayabbasha.sayed@...rochip.com,
        balakrishnan.s@...rochip.com
Subject: Re: [PATCH 15/21] dt-bindings: irqchip/atmel-aic5: Add support for sam9x7 aic

On Sat, Jun 3, 2023, at 23:23, Conor Dooley wrote:
> On Sat, Jun 03, 2023 at 10:19:50PM +0100, Conor Dooley wrote:
>> Hey Varshini,
>> 
>> On Sun, Jun 04, 2023 at 01:32:37AM +0530, Varshini Rajendran wrote:
>> > Document the support added for the Advanced interrupt controller(AIC)
>> > chip in the sam9x7 soc family
>> 
>> Please do not add new family based compatibles, but rather use per-soc
>> compatibles instead.
>
> These things leave me penally confused. Afaiu, sam9x60 is a particular
> SoC. sam9x7 is actually a family, containing sam9x70, sam9x72 and
> sam9x75. It would appear to me that each should have its own compatible,
> no?

I think the usual way this works is that the sam9x7 refers to the
SoC design as in what is actually part of the chip, whereas the 70,
72 and 75 models are variants that have a certain subset of the
features enabled.

If that is the case here, then referring to the on-chip parts by
the sam9x7 name makes sense, and this is similar to what we do
on TI AM-series chips.

There is a remaining risk that a there would be a future
sam9x71/73/74/76/... product based on a new chip that uses
incompatible devices, but at that point we can still use the
more specific model number to identify those without being
ambiguous. The same thing can of course happen when a SoC
vendor reuses a specific name of a prior product with an update
chip that has software visible changes.

I'd just leave this up to Varshini and the other at91 maintainers
here, provided they understand the exact risks.

It's different for the parts that are listed as just sam9x60
compatible in the DT, I think those clearly need to have sam9x7
in the compatible list, but could have the sam9x60 identifier
as a fallback if the hardware is compatible.

     Arnd