[PATCH] dt-bindings: interrupt-controller: aspeed: Refine AST2700 binding description and example

[Ryan Chen]

> Subject: Re: [PATCH] dt-bindings: interrupt-controller: aspeed: Refine AST2700
> binding description and example
> 
> On 14/07/2025 09:17, Ryan Chen wrote:
> > - Update block diagram for better readability and accuracy.
> > - Clarify the relationship and function of INTC0, INTC1, and the GIC.
> > - Documentation and example refine.
> >
> > This enhances the documentation quality and helps developers
> > understand the interrupt controller hierarchy and usage.
> 
> Changing ABI (compatibles) is not enhancing quality and is not explained here.
> 
Sorry, I would add following in description.
- add '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.

> >
> > Signed-off-by: Ryan Chen <ryan_chen at aspeedtech.com>
> > ---
> >  .../aspeed,ast2700-intc.yaml                  | 155
> +++++++++++++-----
> >  1 file changed, 112 insertions(+), 43 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast270
> > 0-intc.yaml
> > b/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast270
> > 0-intc.yaml index 55636d06a674..751a07d49c90 100644
> > ---
> > a/Documentation/devicetree/bindings/interrupt-controller/aspeed,ast270
> > 0-intc.yaml
> > +++ b/Documentation/devicetree/bindings/interrupt-controller/aspeed,as
> > +++ t2700-intc.yaml
> > @@ -10,6 +10,33 @@ description:
> >    This interrupt controller hardware is second level interrupt controller
> that
> >    is hooked to a parent interrupt controller. It's useful to combine multiple
> >    interrupt sources into 1 interrupt to parent interrupt controller.
> > +  Depend to which INTC0 or INTC1 used.
> > +  INTC0 and INTC1 are two kinds of interrupt controller with enable
> > + and raw  status registers for use.
> > +  INTC0 is used to assert GIC if interrupt in INTC1 asserted.
> > +  INTC1 is used to assert INTC0 if interrupt of modules asserted.
> > +  +-----+   +---------+
> > +  | GIC |---|  INTC0  |
> > +  +-----+   +---------+
> > +            +---------+
> > +            |         |---module0
> > +            | INTC0_0 |---module1
> > +            |         |---...
> > +            +---------+---module31
> > +            |---....  |
> > +            +---------+
> > +            |         |     +---------+
> > +            | INTC0_11| +---| INTC1   |
> > +            |         |     +---------+
> > +            +---------+     +---------+---module0
> > +                            | INTC1_0 |---module1
> > +                            |         |---...
> > +                            +---------+---module31
> > +                            ...
> > +                            +---------+---module0
> > +                            | INTC1_5 |---module1
> > +                            |         |---...
> > +                            +---------+---module31
> >
> >  maintainers:
> >    - Kevin Chen <kevin_chen at aspeedtech.com> @@ -17,49 +44,67 @@
> > maintainers:
> >  properties:
> >    compatible:
> >      enum:
> > -      - aspeed,ast2700-intc-ic
> > +      - aspeed,ast2700-intc0
> > +      - aspeed,ast2700-intc1
> 
> No, you cannot change compatibles.
> 
> You just rewrite entire bindings just because of wish to "refine"?
> Hardware changed? What happened here?
> 

Thank you for your feedback.
There is no hardware change.
My intention was to clarify the interrupt controller hierarchy
by introducing separate compatible strings for the parent nodes.

Sorry, I don't change original compatibles, I add parent compatibles aspeed,ast2700-intc0, aspeed,ast2700-intc1.
Modify original to be child nodes, and still keep the same compatible aspeed,ast2700-intc-ic

> You need to clearly describe ABI impact and reasons, like possible bugs you
> address. You cannot just rewrite existing binding into something entirely else.
> 
> Best regards,
> Krzysztof