[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<TY2PPF5CB9A1BE65F13FC00C09F5C1FAE68F2F0A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Date: Thu, 23 Oct 2025 08:20:33 +0000
From: Ryan Chen <ryan_chen@...eedtech.com>
To: Thomas Gleixner <tglx@...utronix.de>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
Joel Stanley <joel@....id.au>, Andrew Jeffery <andrew@...econstruct.com.au>,
"jk@...econstruct.com.au" <jk@...econstruct.com.au>, Kevin Chen
<kevin_chen@...eedtech.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
<linux-aspeed@...ts.ozlabs.org>
Subject: RE: [PATCH v5 2/3] Irqchip/ast2700-intc: add debugfs support for
routing/protection display
> Subject: Re: [PATCH v5 2/3] Irqchip/ast2700-intc: add debugfs support for
> routing/protection display
>
> On Wed, Oct 22 2025 at 14:55, Ryan Chen wrote:
>
> The prefix is: irqchip/ast....:
I'll use irqchip/aspeed-intc:
>
> > AST2700 INTC0/INTC1 nodes ("aspeed,ast2700-intc0/1") not only include
> > the interrupt controller child node ("aspeed,ast2700-intc-ic"), but
> > also provide interrupt routing and register protection features.
>
> Lacks a new line to open a new paragraph.
I'll split the opening sentence and the follow-up paragraph in
the commit message.
>
> > Adds debugfs entries for interrupt routing and protection status for
>
> Add
Will update
>
> > AST2700 INTC0/INTC1.
>
> But what you are failing to explain is why this is required and useful. Just
> adding code because we can is not a real good reason.
The INTC0/INTC1 routing and protection registers are set up by early firmware
and are not modified by Linux.
When routing is off, interrupts get merged/misdirected silently.
A minimal kernel-side visibility helps confirm that the upstream interrupt
topology (e.g., which INTC1 groups are funneled to which INTC0 inputs / GIC SPIs)
matches what the DT and drivers assume.
The protection bits gate which CPU can write/read specific INTC
windows (PSP/SSP/TSP). When those are mis-programmed,
Linux can neither steer nor even read status in places it expects to.
A raw readout lets us verify that Linux isn't boxed out by mistake.
>
> Thanks,
>
> tglx
Powered by blists - more mailing lists