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:

quoted

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