RE: [PATCH 0/4] Add AST2700 INTC0/INTC1 support

[Ryan Chen]

> 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