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

Ryan Chen ryan_chen at aspeedtech.com
Sat Jul 26 18:47:34 PDT 2025


> Subject: Re: [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add parent
> node compatibles and refine documentation
> 
> On 23/07/2025 10:08, Ryan Chen wrote:
> >> 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:
> >>> +  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
> >>
> >> You binding also said intc1 is the parent of intc-ic, so where is here intc-ic?
> >>
> >> This diagram and new binding do not match at all.
> >
> > The corresponded compatible is following.
> >
> >   +-----+   +---------+
> >   | GIC |---|  INTC0  | -> (parent : aspeed,ast2700-intc0)
> >   +-----+   +---------+
> >             +---------+
> >             |        |---module0
> >             | INTC0_0 |---module1
> > 			(child : aspeed,ast2700-intc-ic)
> >             |        |---...
> >             +---------+---module31
> >             |---....  |
> >             +---------+
> >             |         |    					 +---------+
> >             | INTC0_11 | +----------------------------	| INTC1   |  -> ->
> (parent : aspeed,ast2700-intc1)
> 
> AGAIN (second time): that's not what your binding said.
> 
> Your binding is explicit here, which is what we want in general. It says that inct1 is
> one of the parents of intc-ic.
> 
> Let me be clear, because you will be dragging this talk with irrelevant arguments
> forever - changing this binding is close to no. If you come with correct arguments,
> maybe would work. But the main point is that you probably do not have to even
> change the binding to achieve proper hardware description. Work on that.
> 

If I do not change the binding, I think the yaml and dts can still fit the interrupt
nesting architecture by using both interrupts and interrupts-extended.

For first-level controllers, use the standard interrupts property
(e.g. with the GIC as the parent).

For second-level INTC-IC instances, use interrupts-extended to refer to the
first-level INTC-IC, following common Linux practice for stacked interrupt controllers.
For example:
dts
// First level
intc0_11: interrupt-controller at 12101b00 {
    compatible = "aspeed,ast2700-intc-ic";
    reg = <...>;
    interrupt-controller;
    #interrupt-cells = <2>;
    interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>, ...;
};

// Second level, cascaded
intc1_0: interrupt-controller at 14c18100 {
    compatible = "aspeed,ast2700-intc-ic";
    reg = <...>;
    interrupt-controller;
    #interrupt-cells = <2>;
    interrupts-extended = <&intc0_11 0 IRQ_TYPE_LEVEL_HIGH>;
};
In yaml, I can use:
oneOf:
  - required: [interrupts]
  - required: [interrupts-extended]
This allows both cases to be valid.

Please let me know if this is the recommended approach,
or if further changes are needed.

> Best regards,
> Krzysztof


More information about the linux-arm-kernel mailing list