mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ryan Chen <ryan_chen@aspeedtech.com>
To: Krzysztof Kozlowski <krzk@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>, Joel Stanley <joel@jms.id.au>,
	Andrew Jeffery <andrew@codeconstruct.com.au>,
	Kevin Chen <kevin_chen@aspeedtech.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-aspeed@lists.ozlabs.org" <linux-aspeed@lists.ozlabs.org>
Subject: RE: [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add parent node compatibles and refine documentation
Date: Sun, 27 Jul 2025 01:47:34 +0000	[thread overview]
Message-ID: <OS8PR06MB75418BD29DCD6E93F2A44903F25BA@OS8PR06MB7541.apcprd06.prod.outlook.com> (raw)
In-Reply-To: <384635a3-c6ed-44f8-a54a-2b20e20694cd@kernel.org>

> 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@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@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

  reply	other threads:[~2025-07-27  1:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-22  9:51 [PATCH v3 0/2] irqchip: aspeed: Add AST2700 INTC debugfs support and yaml update Ryan Chen
2025-07-22  9:51 ` [PATCH v3 1/2] dt-bindings: interrupt-controller: aspeed: Add parent node compatibles and refine documentation Ryan Chen
2025-07-22 15:28   ` Thomas Gleixner
2025-07-23  7:47     ` Ryan Chen
2025-07-23  5:01   ` Rob Herring
2025-07-23  7:56     ` Ryan Chen
2025-07-23  6:11   ` Krzysztof Kozlowski
2025-07-23  8:18     ` Ryan Chen
2025-07-25  7:18       ` Ryan Chen
2025-07-25  7:41         ` Krzysztof Kozlowski
2025-07-23  6:13   ` Krzysztof Kozlowski
2025-07-23  8:08     ` Ryan Chen
2025-07-25  7:40       ` Krzysztof Kozlowski
2025-07-27  1:47         ` Ryan Chen [this message]
2025-07-27  9:36           ` Krzysztof Kozlowski
2025-07-28  2:54             ` Ryan Chen
2025-07-22  9:51 ` [PATCH v3 2/2] irqchip: aspeed: add debugfs support and AST2700 INTC0/INTC1 routing/protection display Ryan Chen
2025-07-22 15:27   ` Thomas Gleixner
2025-07-23  6:02     ` Ryan Chen
2025-07-23 17:37       ` Thomas Gleixner
2025-07-24  2:19         ` Ryan Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OS8PR06MB75418BD29DCD6E93F2A44903F25BA@OS8PR06MB7541.apcprd06.prod.outlook.com \
    --to=ryan_chen@aspeedtech.com \
    --cc=andrew@codeconstruct.com.au \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=joel@jms.id.au \
    --cc=kevin_chen@aspeedtech.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®