linux-kernel - Re: [PATCH v2 1/2] dt-bindings: interrupt-controller: apple,aic2: Add AICv3

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] [day] [month] [year] [list]

Message-ID: <20260205221918.GA71415@robin.jannau.net>
Date: Thu, 5 Feb 2026 23:19:18 +0100
From: Janne Grunau <j@...nau.net>
To: Sven Peter <sven@...nel.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Neal Gompa <neal@...pa.dev>,
	Thomas Gleixner <tglx@...utronix.de>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, asahi@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: interrupt-controller: apple,aic2:
 Add AICv3

On Thu, Feb 05, 2026 at 07:01:51PM +0100, Sven Peter wrote:
> Hi,
> 
> On 05.02.26 13:50, Krzysztof Kozlowski wrote:
> > On Wed, Jan 28, 2026 at 09:57:08AM +0100, Janne Grunau wrote:
> >> AIC version 3 as found on the Apple M3 (t8122) is very similar to AICv2
> >> in its base functionality. It can use the same device tree bindings as
> >> AICv2 so add it to the AICv2 bindings.
> >> This interrupt controller is used on all Apple SoCs starting with M3 up
> >> to at least M5.
> >> The only apparent difference is the increased IRQ config offset. Apple's
> >> device tree codes this new offset as property of the "aic" node but the
> >> value stayed constant for all SoCs with "aic,3". Since the SoC specific
> >> compatible "apple,t8122-aic3" will be used in the driver this offset can
> >> remain a driver implementation detail.
> >>
> >> Signed-off-by: Janne Grunau <j@...nau.net>
> >> ---
> >>   .../bindings/interrupt-controller/apple,aic2.yaml  | 45 +++++++++++++++++-----
> >>   1 file changed, 36 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml
> >> index ee5a0dfff437816056bda0de5523bf38be4f49ba..a6e2251fcc111340c0a27ab6912452f6b1255be2 100644
> >> --- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml
> >> +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml
> >> @@ -4,10 +4,10 @@
> >>   $id: http://devicetree.org/schemas/interrupt-controller/apple,aic2.yaml#
> >>   $schema: http://devicetree.org/meta-schemas/core.yaml#
> >>   
> >> -title: Apple Interrupt Controller 2
> >> +title: Apple Interrupt Controller 2 and 3
> >>   
> >>   maintainers:
> >> -  - Hector Martin <marcan@...can.st>
> >> +  - Janne Grunau <j@...nau.net>
> >>   
> >>   description: |
> >>     The Apple Interrupt Controller 2 is a simple interrupt controller present on
> >> @@ -28,14 +28,24 @@ description: |
> >>     which do not go through a discrete interrupt controller. It also handles
> >>     FIQ-based Fast IPIs.
> >>   
> >> +  The Apple Interrupt Controller 3 is in its base functionality very similar to
> >> +  the Apple Interrupt Controller 2 and uses the same device tree bindings. It is
> >> +  found on Apple ARM SoCs platforms starting with t8122 (M3).
> >> +
> >>   properties:
> >>     compatible:
> >> -    items:
> >> -      - enum:
> >> -          - apple,t8112-aic
> >> -          - apple,t6000-aic
> >> -          - apple,t6020-aic
> >> -      - const: apple,aic2
> >> +    oneOf:
> >> +      - items:
> >> +          - enum:
> >> +              - apple,t8112-aic
> >> +              - apple,t6000-aic
> >> +              - apple,t6020-aic
> > 
> > If you are re-shuffling these, you can as well sort alphanumerically.
> 
> I don't have a strong opinion here but the last time this came up we 
> agreed that we'd go with release order IIRC for consistency since that 
> order is used in every other binding for this platform.

The intended scheme as documented in some commit messages is first base
Mx SoCs in release order and then Mx Pro/Max/Ultra SoCs in release
order. This scheme isn't used consistently though. I think I fixed that
in one or two bindings already but there are other using a different
order.
I think these unecessarily complex rules are guaranteed to lead to
inconsistencies. I'll resort the entries alphabetically as that's the
only rule with a chance of consistent use.

Janne