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: <20230604-cohesive-unmoving-032da3272620@spud>
Date:   Sun, 4 Jun 2023 22:08:02 +0100
From:   Conor Dooley <conor@...nel.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Varshini Rajendran <varshini.rajendran@...rochip.com>,
        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 Sun, Jun 04, 2023 at 11:49:48AM +0200, Arnd Bergmann wrote:
> 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

s/penally/perennially/

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

If it is the case that what differentiates them is having bits chopped
off, and there's no implementation differences that seems fair.

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

Ye, seems fair to me. Nicolas/Claudiu etc, is there a convention to use
the "0" model as the compatible (like the 9x60 did) or have "random"
things been done so far?

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

Aye.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)