linux-kernel - RE: [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add parent node compatibles and refine documentation

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:
 <OS8PR06MB754125722911782DBB3CFEFCF25FA@OS8PR06MB7541.apcprd06.prod.outlook.com>
Date: Wed, 23 Jul 2025 08:18:46 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Krzysztof Kozlowski <krzk@...nel.org>, Thomas Gleixner
	<tglx@...utronix.de>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski
	<krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Joel Stanley
	<joel@....id.au>, Andrew Jeffery <andrew@...econstruct.com.au>, Kevin Chen
	<kevin_chen@...eedtech.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>
Subject: RE: [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add
 parent node compatibles and refine documentation

> Subject: Re: [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add
> parent node compatibles and refine documentation
> 
> On 22/07/2025 11:51, Ryan Chen wrote:
> > The AST2700 SoC contains two independent top-level interrupt
> > controllers
> > (INTC0 and INTC1), each responsible for handling different peripheral
> > groups and occupying separate register spaces. Above them, PSP(CA35)
> > GIC controller acts as the root interrupt aggregator. Accurately
> > describing this hierarchical hardware structure in the device tree
> > requires distinct compatible strings for the parent nodes of INTC0 and INTC1.
> >
> > - Adds 'aspeed,ast2700-intc0' and 'aspeed,ast2700-intc1' compatible
> > strings for parent interrupt controller nodes. (in addition to the
> > existing 'aspeed,ast2700-intc-ic' for child nodes)
> 
> I don't understand how this solves your problem at all. Look at old diagram - is
> it correct? If not, what makes you think that new diagram is correct?
> 
> What is the meaning of existing binding and existing intc-ic compatible?
> 
The new parent nodes (aspeed,ast2700-intc0/intc1) make the device tree layout match the
actual hardware separation shown in the SoC datasheet.
This allows us to register the full resource region, allocate platform resources properly,
and cleanly extend/debug in the future.

The previous "aspeed,ast2700-intc-ic" compatible only describes the interrupt controller instance,
not the full register block. In practice, with only a single child node, there is no way to:
map and manage the entire address space for each INTC block (0x12100000 and 0x14c18000),
or cleanly expose debug features that must access routing/protection registers outside the intc-ic range.

The old diagram was incomplete, since it implied that the interrupt controller block had only the intc-ic instance,
but in hardware each INTC region contains multiple functions and register ranges.

This binding change is mainly for clarity and correctness, aligning DT and driver with the real SoC register map
and future-proofing for debug/maintenance.
> 
> > - Clarifies the relationship and function of INTC0 parent
> >  (intc0_0~x: child), INTC1 parent (intc1_0~x: child), and the GIC  in
> > the documentation.
> > - Updates block diagrams and device tree examples to illustrate  the
> > hierarchy and compatible usage.
> > - Refines documentation and example formatting.
> >
> > This change allows the device tree and driver to distinguish between
> > parent (top-level) and child (group) interrupt controller nodes,
> > enabling more precise driver matching SOC register space allocation.
> 
> And how it was not possible before? That's poor argument especially that DT
> does not have to ever distinguish that.
> 
> 
> Best regards,
> Krzysztof