netdev - 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]

Date: Wed, 14 Jun 2023 13:41:56 -0600
From: Rob Herring <robh@...nel.org>
To: Nicolas Ferre <nicolas.ferre@...rochip.com>
Cc: Conor Dooley <conor@...nel.org>, Arnd Bergmann <arnd@...db.de>, 
	Varshini Rajendran <varshini.rajendran@...rochip.com>, Thomas Gleixner <tglx@...utronix.de>, 
	Marc Zyngier <maz@...nel.org>, krzysztof.kozlowski+dt@...aro.org, 
	Conor Dooley <conor+dt@...nel.org>, 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 Mon, Jun 05, 2023 at 02:37:16PM +0200, Nicolas Ferre wrote:
> Arnd, Conor,
> 
> On 04/06/2023 at 23:08, Conor Dooley wrote:
> > 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.
> 
> Yes, That's the case.
> > > 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.
> 
> This is what we did for most of our SoCs families, indeed.
> 
> > If it is the case that what differentiates them is having bits chopped
> > off, and there's no implementation differences that seems fair.
> 
> Ok, thanks.
> 
> > > 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.
> 
> This is exactly what we did for sama5d29 which is not the same silicon vs.
> the other members of the sama5d2 family. We used the more specify sama5d29
> sub-string for describing the changing parts (CAN-FD and Ethernet).
> 
> > > 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.
> 
> Yep, I understand the risk and will try to review the compatibility strings
> that would need more precise description (maybe PMC or AIC).
> 
> > 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?
> 
> sam9x60 was a single SoC, not a member of a "family", so there was no
> meaning of the "0" here. Moreover, the "0" ones are usually not the subset,
> if it even exists.
> So far, we used the silicon string to define the compatibility string,
> adding a more precise string for hardware of family members that needed it
> (as mentioned above for sama5d29).
> 
> > > 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.
> 
> Yep, agreed.

Can we convert this binding to schema so all this is perfectly clear 
what's valid or not.

Rob