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: <0cc9bd0a-958b-4e63-b2ed-959a3ea43440@kernel.org>
Date: Fri, 6 Feb 2026 15:44:30 +0100
From: Sven Peter <sven@...nel.org>
To: Janne Grunau <j@...nau.net>
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 05.02.26 23:19, Janne Grunau wrote:
> 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.

Sure, I'm totally fine with just using alphanumeric order everywhere as 
well.


Sven