Message-ID:
 <TY2PPF5CB9A1BE69B07F90DFB245FAB735DF299A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Thu, 5 Feb 2026 09:49:29 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: 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>,
	Paul Walmsley <pjw@...nel.org>, Palmer Dabbelt <palmer@...belt.com>, Albert
 Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
	"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>, "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>
Subject: RE: [PATCH 0/4] Add AST2700 INTC0/INTC1 support


> Subject: Re: [PATCH 0/4] Add AST2700 INTC0/INTC1 support
> 
> On Thu, Feb 05, 2026 at 02:07:18PM +0800, Ryan Chen wrote:
> > This series replaces the existing AST2700 interrupt controller binding
> > and driver. The original implementation was focused on a narrow,
> > PSP-centric view and could not fully describe the complexity of the
> > AST2700 interrupt fabric:
> >
> > * It was focused primarily on the perspective of the Primary Service
> >   Processor (PSP).
> > * It could not handle interrupt route configuration.
> > * It could not handle interrupt register protection.
> >
> > By contrast, the new bindings and drivers describe the interrupt
> > controllers at the block-function level and provide a unified binding
> > design that can be used from the perspective of any of the four
> > integrated processors (the Primary, Secondary and Tertiary Service
> > Processors, and the Boot MCU):
> 
> Where and how did you address last feedback given to you here:
> 
> https://lore.kernel.org/all/20250814-auspicious-thundering-jaybird-b76f4f@ku
> oka/
> 
> "This binding is not improving. You are not responding to REAL problems
> described to you. What's more, you send it in a way making our life difficult,
> look:"
> 
> So how did you make our life easier now?
> 
Hi Krzysztof,

Thanks for your feedback.

The series you commented on in Aug 2025 (v4 1/2) attempted to model
The hardware by introducing parent compatibles (aspeed,ast2700-intc0 /
aspeed,ast2700-intc1) with child "interrupt-controller@" nodes using
aspeed,ast2700-intc-ic. In hindsight, that approach did not align well
with the actual hardware structure and resulted in inconsistencies
between the diagrams, the schema, and the register layout (including
unit-address issues). It was also difficult to review in isolation.

This series addresses that feedback by changing the approach entirely:

First, the artificial parent/child split has been removed. The new
binding exposes only the two interrupt controller designs that exist in
hardware, INTC0 and INTC1. There are no intermediate interrupt-controller
child nodes introduced for grouping or driver convenience.

Second, the role of aspeed,interrupt-ranges has been clarified and
narrowed. The property now describes only the fixed hardware
connections between interrupt controllers (i.e. post-routing
connectivity), rather than attempting to encode routing policy in the
devicetree. Route selection itself is implemented in the INTC0 driver,
based on information such as the interrupt-parent of the running
firmware environment.

Finally, to make the intent explicit and easier to review, this series: the new binding and drivers are added
first, and the legacy binding and driver are removed in the same series.

In short, the earlier parent/child model—which did not correspond
cleanly to hardware resource boundaries—has been dropped entirely, and
the binding now directly reflects the hardware blocks present in the
AST2700.

Best regards,
Ryan

Powered by blists - more mailing lists