* realtek,rtl-intc IRQ mapping broken on 5.16-rc1
@ 2021-11-18 15:56 Sander Vanheule
2021-11-18 19:19 ` Marc Zyngier
0 siblings, 1 reply; 8+ messages in thread
From: Sander Vanheule @ 2021-11-18 15:56 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring, Lorenzo Pieralisi, Bjorn Helgaas
Cc: Birger Koblitz, Bert Vermeulen, John Crispin, Thomas Gleixner,
linux-kernel, devicetree, Frank Rowand
Hi everyone,
On 5.16-rc1, the realtek,rtl-intc interrupt controller driver for Realtek RTL8380 SoCs
(and related) appears broken. When booting, I don't get a tty on the serial port, although
serial output works.
The watchdog (currently under review) also cannot acquire the required phase1 interrupt,
and produces the following output:
[ 1.968228] realtek-otto-watchdog 18003150.watchdog: error -EINVAL: Failed to get IRQ 4
for phase1
[ 1.978404] realtek-otto-watchdog: probe of 18003150.watchdog failed with error -22
A bisects points to commit 041284181226 ("of/irq: Allow matching of an interrupt-map local
to an interrupt controller"). Reverting this above commit and follow-up commit
10a20b34d735 ("of/irq: Don't ignore interrupt-controller when interrupt-map failed")
restores the functionality from v5.15.
Below you can find the DTS that I used to reproduce this on my Zyxel GS1900-8.
Best,
Sander
---
// SPDX-License-Identifier: GPL-2.0-or-later
/dts-v1/;
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "zyxel,gs1900-8", "realtek,rtl83xx-soc";
model = "ZyXEL GS1900-8";
aliases {
serial0 = &serial0;
};
baseclk: baseclk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <500000000>;
};
chosen {
stdout-path = "serial0";
bootargs = "earlycon console=ttyS0,115200";
};
cpuintc: cpuintc {
compatible = "mti,cpu-interrupt-controller";
#address-cells = <0>;
#interrupt-cells = <1>;
interrupt-controller;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "mips,mips4KEc";
reg = <0>;
clocks = <&baseclk>;
clock-names = "cpu";
};
};
lx_clk: lx_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <200000000>;
};
memory@0 {
device_type = "memory";
reg = <0x0 0x8000000>;
};
soc: soc@18000000 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x18000000 0x10000>;
serial0: serial@2000 {
compatible = "ns16550a";
reg = <0x2000 0x100>;
clocks = <&lx_clk>;
interrupt-parent = <&intc>;
interrupts = <31>;
reg-io-width = <1>;
reg-shift = <2>;
fifo-size = <1>;
no-loopback-test;
};
intc: interrupt-controller@3000 {
compatible = "realtek,rtl-intc";
reg = <0x3000 0x20>;
interrupt-controller;
#interrupt-cells = <1>;
#address-cells = <0>;
interrupt-map =
<31 &cpuintc 2>, /* UART0 */
<20 &cpuintc 3>, /* SWCORE */
<19 &cpuintc 4>, /* WDT IP1 */
<18 &cpuintc 5>; /* WDT IP2 */
};
watchdog@3150 {
compatible = "realtek,rtl8380-wdt";
reg = <0x3150 0xc>;
realtek,reset-mode = "soc";
clocks = <&lx_clk>;
timeout-sec = <20>;
interrupt-parent = <&intc>;
interrupt-names = "phase1", "phase2";
interrupts = <19>, <18>;
};
};
};
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1 2021-11-18 15:56 realtek,rtl-intc IRQ mapping broken on 5.16-rc1 Sander Vanheule @ 2021-11-18 19:19 ` Marc Zyngier 2021-11-18 19:45 ` Sander Vanheule 0 siblings, 1 reply; 8+ messages in thread From: Marc Zyngier @ 2021-11-18 19:19 UTC (permalink / raw) To: Sander Vanheule Cc: Rob Herring, Lorenzo Pieralisi, Bjorn Helgaas, Birger Koblitz, Bert Vermeulen, John Crispin, Thomas Gleixner, linux-kernel, devicetree, Frank Rowand Hi Sander, On Thu, 18 Nov 2021 15:56:06 +0000, Sander Vanheule <sander@svanheule.net> wrote: > > Hi everyone, > > On 5.16-rc1, the realtek,rtl-intc interrupt controller driver for > Realtek RTL8380 SoCs (and related) appears broken. When booting, I > don't get a tty on the serial port, although serial output works. Thanks for the heads up. > The watchdog (currently under review) also cannot acquire the > required phase1 interrupt, and produces the following output: > [ 1.968228] realtek-otto-watchdog 18003150.watchdog: error -EINVAL: Failed to get IRQ 4 > for phase1 > [ 1.978404] realtek-otto-watchdog: probe of 18003150.watchdog failed with error -22 > > A bisects points to commit 041284181226 ("of/irq: Allow matching of > an interrupt-map local to an interrupt controller"). Reverting this > above commit and follow-up commit 10a20b34d735 ("of/irq: Don't > ignore interrupt-controller when interrupt-map failed") restores the > functionality from v5.15. OK, back to square one, we need to debug this one. [...] > cpuintc: cpuintc { > compatible = "mti,cpu-interrupt-controller"; > #address-cells = <0>; > #interrupt-cells = <1>; > interrupt-controller; > }; > [...] > > intc: interrupt-controller@3000 { > compatible = "realtek,rtl-intc"; > reg = <0x3000 0x20>; > interrupt-controller; > #interrupt-cells = <1>; > > #address-cells = <0>; > interrupt-map = > <31 &cpuintc 2>, /* UART0 */ > <20 &cpuintc 3>, /* SWCORE */ > <19 &cpuintc 4>, /* WDT IP1 */ > <18 &cpuintc 5>; /* WDT IP2 */ > }; Something looks pretty odd. With 5.15, this interrupt-map would be completely ignored. With 5.16-rc1, we should actually honour it. /me digs... Gah, I see. This driver has its own interrupt-map parser and invents something out of thin air. I will bang my own head on the wall for having merged this horror. Can you try applying the patch below and rename the interrupt-map property in your DT to "silly-interrupt-map" and let me know if that helps? That's of course not the right fix, but that's just to confirm the extent of the damage... M. diff --git a/drivers/irqchip/irq-realtek-rtl.c b/drivers/irqchip/irq-realtek-rtl.c index fd9f275592d2..3641cd2b1a2c 100644 --- a/drivers/irqchip/irq-realtek-rtl.c +++ b/drivers/irqchip/irq-realtek-rtl.c @@ -114,7 +114,7 @@ static int __init map_interrupts(struct device_node *node, struct irq_domain *do if (ret || tmp) return -EINVAL; - imap = of_get_property(node, "interrupt-map", &imaplen); + imap = of_get_property(node, "silly-interrupt-map", &imaplen); if (!imap || imaplen % 3) return -EINVAL; -- Without deviation from the norm, progress is not possible. ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1 2021-11-18 19:19 ` Marc Zyngier @ 2021-11-18 19:45 ` Sander Vanheule 2021-11-19 14:48 ` Marc Zyngier 0 siblings, 1 reply; 8+ messages in thread From: Sander Vanheule @ 2021-11-18 19:45 UTC (permalink / raw) To: Marc Zyngier Cc: Rob Herring, Lorenzo Pieralisi, Bjorn Helgaas, Birger Koblitz, Bert Vermeulen, John Crispin, Thomas Gleixner, linux-kernel, devicetree, Frank Rowand Hi Marc, On Thu, 2021-11-18 at 19:19 +0000, Marc Zyngier wrote: > Hi Sander, > > On Thu, 18 Nov 2021 15:56:06 +0000, > Sander Vanheule <sander@svanheule.net> wrote: > > > > Hi everyone, > > > > On 5.16-rc1, the realtek,rtl-intc interrupt controller driver for > > Realtek RTL8380 SoCs (and related) appears broken. When booting, I > > don't get a tty on the serial port, although serial output works. > > Thanks for the heads up. > > > The watchdog (currently under review) also cannot acquire the > > required phase1 interrupt, and produces the following output: > > > [ 1.968228] realtek-otto-watchdog 18003150.watchdog: error -EINVAL: Failed to get > > IRQ 4 > > for phase1 > > [ 1.978404] realtek-otto-watchdog: probe of 18003150.watchdog failed with error -22 > > > > A bisects points to commit 041284181226 ("of/irq: Allow matching of > > an interrupt-map local to an interrupt controller"). Reverting this > > above commit and follow-up commit 10a20b34d735 ("of/irq: Don't > > ignore interrupt-controller when interrupt-map failed") restores the > > functionality from v5.15. > > OK, back to square one, we need to debug this one. > > [...] > > > cpuintc: cpuintc { > > compatible = "mti,cpu-interrupt-controller"; > > #address-cells = <0>; > > #interrupt-cells = <1>; > > interrupt-controller; > > }; > > > > [...] > > > > > intc: interrupt-controller@3000 { > > compatible = "realtek,rtl-intc"; > > reg = <0x3000 0x20>; > > interrupt-controller; > > #interrupt-cells = <1>; > > > > #address-cells = <0>; > > interrupt-map = > > <31 &cpuintc 2>, /* UART0 */ > > <20 &cpuintc 3>, /* SWCORE */ > > <19 &cpuintc 4>, /* WDT IP1 */ > > <18 &cpuintc 5>; /* WDT IP2 */ > > }; > > Something looks pretty odd. With 5.15, this interrupt-map would be > completely ignored. With 5.16-rc1, we should actually honour it. > > /me digs... > > Gah, I see. This driver has its own interrupt-map parser and invents > something out of thin air. I will bang my own head on the wall for > having merged this horror. > > Can you try applying the patch below and rename the interrupt-map > property in your DT to "silly-interrupt-map" and let me know if that > helps? I've dropped the aforementioned reverts, and applied your suggested changes to the DTS and irq-realtek-rtl. Interrupts now appear to work like before; UART console and watchdog work as expected. Best, Sander > > That's of course not the right fix, but that's just to confirm the > extent of the damage... > > M. > > diff --git a/drivers/irqchip/irq-realtek-rtl.c b/drivers/irqchip/irq-realtek-rtl.c > index fd9f275592d2..3641cd2b1a2c 100644 > --- a/drivers/irqchip/irq-realtek-rtl.c > +++ b/drivers/irqchip/irq-realtek-rtl.c > @@ -114,7 +114,7 @@ static int __init map_interrupts(struct device_node *node, struct > irq_domain *do > if (ret || tmp) > return -EINVAL; > > - imap = of_get_property(node, "interrupt-map", &imaplen); > + imap = of_get_property(node, "silly-interrupt-map", &imaplen); > if (!imap || imaplen % 3) > return -EINVAL; > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1 2021-11-18 19:45 ` Sander Vanheule @ 2021-11-19 14:48 ` Marc Zyngier 2021-11-19 19:09 ` Birger Koblitz 2021-11-21 20:33 ` Sander Vanheule 0 siblings, 2 replies; 8+ messages in thread From: Marc Zyngier @ 2021-11-19 14:48 UTC (permalink / raw) To: Sander Vanheule, Rob Herring Cc: Lorenzo Pieralisi, Bjorn Helgaas, Birger Koblitz, Bert Vermeulen, John Crispin, Thomas Gleixner, linux-kernel, devicetree, Frank Rowand On Thu, 18 Nov 2021 19:45:26 +0000, Sander Vanheule <sander@svanheule.net> wrote: > > Hi Marc, > > On Thu, 2021-11-18 at 19:19 +0000, Marc Zyngier wrote: > > Hi Sander, > > > > On Thu, 18 Nov 2021 15:56:06 +0000, > > Sander Vanheule <sander@svanheule.net> wrote: > > > > > > Hi everyone, > > > > > > On 5.16-rc1, the realtek,rtl-intc interrupt controller driver for > > > Realtek RTL8380 SoCs (and related) appears broken. When booting, I > > > don't get a tty on the serial port, although serial output works. > > > > Thanks for the heads up. > > > > > The watchdog (currently under review) also cannot acquire the > > > required phase1 interrupt, and produces the following output: > > > > > [ 1.968228] realtek-otto-watchdog 18003150.watchdog: error -EINVAL: Failed to get > > > IRQ 4 > > > for phase1 > > > [ 1.978404] realtek-otto-watchdog: probe of 18003150.watchdog failed with error -22 > > > > > > A bisects points to commit 041284181226 ("of/irq: Allow matching of > > > an interrupt-map local to an interrupt controller"). Reverting this > > > above commit and follow-up commit 10a20b34d735 ("of/irq: Don't > > > ignore interrupt-controller when interrupt-map failed") restores the > > > functionality from v5.15. > > > > OK, back to square one, we need to debug this one. > > > > [...] > > > > > cpuintc: cpuintc { > > > compatible = "mti,cpu-interrupt-controller"; > > > #address-cells = <0>; > > > #interrupt-cells = <1>; > > > interrupt-controller; > > > }; > > > > > > > [...] > > > > > > > > intc: interrupt-controller@3000 { > > > compatible = "realtek,rtl-intc"; > > > reg = <0x3000 0x20>; > > > interrupt-controller; > > > #interrupt-cells = <1>; > > > > > > #address-cells = <0>; > > > interrupt-map = > > > <31 &cpuintc 2>, /* UART0 */ > > > <20 &cpuintc 3>, /* SWCORE */ > > > <19 &cpuintc 4>, /* WDT IP1 */ > > > <18 &cpuintc 5>; /* WDT IP2 */ > > > }; > > > > Something looks pretty odd. With 5.15, this interrupt-map would be > > completely ignored. With 5.16-rc1, we should actually honour it. > > > > /me digs... > > > > Gah, I see. This driver has its own interrupt-map parser and invents > > something out of thin air. I will bang my own head on the wall for > > having merged this horror. > > > > Can you try applying the patch below and rename the interrupt-map > > property in your DT to "silly-interrupt-map" and let me know if that > > helps? > > I've dropped the aforementioned reverts, and applied your suggested > changes to the DTS and irq-realtek-rtl. Interrupts now appear to > work like before; UART console and watchdog work as expected. Right. So here's the problem: what this interrupt-map property means is "an interrupt descriptor with value 31 really is interrupt 2 on cpuintc, and nothing else matters(tm)". Up to 5.15, the kernel would simply ignore such directive. It now honours it. There are only three solution to this: (1) we change the DT and the driver so that it actually describes the HW rather than some crazy interpretation. This means breaking backward compatibility with older kernels on new DT, as well as new kernels on old DTs. (2) we add a quirk to the core DT parsing code to ignore an interrupt-map property placed in a "realtek,rtl-intc" node. (3) we revert the change and break the Apple M1. I'm obviously not keen on (3). I can (sort of) deal with (2), but I'd rather do (1) because what currently is in the DT doesn't describe the HW in any shape or form. Rob, what do you think? M. -- Without deviation from the norm, progress is not possible. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1 2021-11-19 14:48 ` Marc Zyngier @ 2021-11-19 19:09 ` Birger Koblitz 2021-11-21 20:33 ` Sander Vanheule 1 sibling, 0 replies; 8+ messages in thread From: Birger Koblitz @ 2021-11-19 19:09 UTC (permalink / raw) To: Marc Zyngier, Sander Vanheule, Rob Herring Cc: Lorenzo Pieralisi, Bjorn Helgaas, Bert Vermeulen, John Crispin, Thomas Gleixner, linux-kernel, devicetree, Frank Rowand Hi, I would vote for (2), the somewhat dirty fix, at least for now. We are working on an updated version of this driver for newer Realtek SoCs (RTL839x, RTL930x), which support VSMP and where there are multiple instances of this controller to support per-cpu IRQs. However, this is not ready for prime-time yet. But at that time we would also fix the IRQ map. Cheers, Birger On 19/11/2021 15:48, Marc Zyngier wrote: > On Thu, 18 Nov 2021 19:45:26 +0000, > Sander Vanheule <sander@svanheule.net> wrote: >> >> Hi Marc, >> >> On Thu, 2021-11-18 at 19:19 +0000, Marc Zyngier wrote: >>> Hi Sander, >>> >>> On Thu, 18 Nov 2021 15:56:06 +0000, >>> Sander Vanheule <sander@svanheule.net> wrote: >>>> >>>> Hi everyone, >>>> >>>> On 5.16-rc1, the realtek,rtl-intc interrupt controller driver for >>>> Realtek RTL8380 SoCs (and related) appears broken. When booting, I >>>> don't get a tty on the serial port, although serial output works. >>> >>> Thanks for the heads up. >>> >>>> The watchdog (currently under review) also cannot acquire the >>>> required phase1 interrupt, and produces the following output: >>> >>>> [ 1.968228] realtek-otto-watchdog 18003150.watchdog: error -EINVAL: Failed to get >>>> IRQ 4 >>>> for phase1 >>>> [ 1.978404] realtek-otto-watchdog: probe of 18003150.watchdog failed with error -22 >>>> >>>> A bisects points to commit 041284181226 ("of/irq: Allow matching of >>>> an interrupt-map local to an interrupt controller"). Reverting this >>>> above commit and follow-up commit 10a20b34d735 ("of/irq: Don't >>>> ignore interrupt-controller when interrupt-map failed") restores the >>>> functionality from v5.15. >>> >>> OK, back to square one, we need to debug this one. >>> >>> [...] >>> >>>> cpuintc: cpuintc { >>>> compatible = "mti,cpu-interrupt-controller"; >>>> #address-cells = <0>; >>>> #interrupt-cells = <1>; >>>> interrupt-controller; >>>> }; >>>> >>> >>> [...] >>> >>>> >>>> intc: interrupt-controller@3000 { >>>> compatible = "realtek,rtl-intc"; >>>> reg = <0x3000 0x20>; >>>> interrupt-controller; >>>> #interrupt-cells = <1>; >>>> >>>> #address-cells = <0>; >>>> interrupt-map = >>>> <31 &cpuintc 2>, /* UART0 */ >>>> <20 &cpuintc 3>, /* SWCORE */ >>>> <19 &cpuintc 4>, /* WDT IP1 */ >>>> <18 &cpuintc 5>; /* WDT IP2 */ >>>> }; >>> >>> Something looks pretty odd. With 5.15, this interrupt-map would be >>> completely ignored. With 5.16-rc1, we should actually honour it. >>> >>> /me digs... >>> >>> Gah, I see. This driver has its own interrupt-map parser and invents >>> something out of thin air. I will bang my own head on the wall for >>> having merged this horror. >>> >>> Can you try applying the patch below and rename the interrupt-map >>> property in your DT to "silly-interrupt-map" and let me know if that >>> helps? >> >> I've dropped the aforementioned reverts, and applied your suggested >> changes to the DTS and irq-realtek-rtl. Interrupts now appear to >> work like before; UART console and watchdog work as expected. > > Right. So here's the problem: what this interrupt-map property means > is "an interrupt descriptor with value 31 really is interrupt 2 on > cpuintc, and nothing else matters(tm)". Up to 5.15, the kernel would > simply ignore such directive. It now honours it. > > There are only three solution to this: > > (1) we change the DT and the driver so that it actually describes the > HW rather than some crazy interpretation. This means breaking backward > compatibility with older kernels on new DT, as well as new kernels on > old DTs. > > (2) we add a quirk to the core DT parsing code to ignore an > interrupt-map property placed in a "realtek,rtl-intc" node. > > (3) we revert the change and break the Apple M1. > > I'm obviously not keen on (3). I can (sort of) deal with (2), but I'd > rather do (1) because what currently is in the DT doesn't describe the > HW in any shape or form. > > Rob, what do you think? > > M. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1 2021-11-19 14:48 ` Marc Zyngier 2021-11-19 19:09 ` Birger Koblitz @ 2021-11-21 20:33 ` Sander Vanheule 2021-11-21 21:11 ` John Crispin 1 sibling, 1 reply; 8+ messages in thread From: Sander Vanheule @ 2021-11-21 20:33 UTC (permalink / raw) To: Marc Zyngier, Rob Herring, Birger Koblitz Cc: Lorenzo Pieralisi, Bjorn Helgaas, Bert Vermeulen, John Crispin, Thomas Gleixner, linux-kernel, devicetree, Frank Rowand Hi Marc, Rob, Birger, On Fri, 2021-11-19 at 14:48 +0000, Marc Zyngier wrote: > On Thu, 18 Nov 2021 19:45:26 +0000, > Sander Vanheule <sander@svanheule.net> wrote: > > > > Hi Marc, > > > > On Thu, 2021-11-18 at 19:19 +0000, Marc Zyngier wrote: > > > Hi Sander, > > > > > > On Thu, 18 Nov 2021 15:56:06 +0000, > > > Sander Vanheule <sander@svanheule.net> wrote: > > > > > > > > Hi everyone, > > > > > > > > On 5.16-rc1, the realtek,rtl-intc interrupt controller driver for > > > > Realtek RTL8380 SoCs (and related) appears broken. When booting, I > > > > don't get a tty on the serial port, although serial output works. > > > > > > Thanks for the heads up. > > > > > > > The watchdog (currently under review) also cannot acquire the > > > > required phase1 interrupt, and produces the following output: > > > > > > > [ 1.968228] realtek-otto-watchdog 18003150.watchdog: error -EINVAL: > > > > Failed to get > > > > IRQ 4 > > > > for phase1 > > > > [ 1.978404] realtek-otto-watchdog: probe of 18003150.watchdog failed > > > > with error - > > > > 22 > > > > > > > > A bisects points to commit 041284181226 ("of/irq: Allow matching of > > > > an interrupt-map local to an interrupt controller"). Reverting this > > > > above commit and follow-up commit 10a20b34d735 ("of/irq: Don't > > > > ignore interrupt-controller when interrupt-map failed") restores the > > > > functionality from v5.15. > > > > > > OK, back to square one, we need to debug this one. > > > > > > [...] > > > > > > > cpuintc: cpuintc { > > > > compatible = "mti,cpu-interrupt-controller"; > > > > #address-cells = <0>; > > > > #interrupt-cells = <1>; > > > > interrupt-controller; > > > > }; > > > > > > > > > > [...] > > > > > > > > > > > intc: interrupt-controller@3000 { > > > > compatible = "realtek,rtl-intc"; > > > > reg = <0x3000 0x20>; > > > > interrupt-controller; > > > > #interrupt-cells = <1>; > > > > > > > > #address-cells = <0>; > > > > interrupt-map = > > > > <31 &cpuintc 2>, /* UART0 */ > > > > <20 &cpuintc 3>, /* SWCORE */ > > > > <19 &cpuintc 4>, /* WDT IP1 */ > > > > <18 &cpuintc 5>; /* WDT IP2 */ > > > > }; > > > > > > Something looks pretty odd. With 5.15, this interrupt-map would be > > > completely ignored. With 5.16-rc1, we should actually honour it. > > > > > > /me digs... > > > > > > Gah, I see. This driver has its own interrupt-map parser and invents > > > something out of thin air. I will bang my own head on the wall for > > > having merged this horror. > > > > > > Can you try applying the patch below and rename the interrupt-map > > > property in your DT to "silly-interrupt-map" and let me know if that > > > helps? > > > > I've dropped the aforementioned reverts, and applied your suggested > > changes to the DTS and irq-realtek-rtl. Interrupts now appear to > > work like before; UART console and watchdog work as expected. > > Right. So here's the problem: what this interrupt-map property means > is "an interrupt descriptor with value 31 really is interrupt 2 on > cpuintc, and nothing else matters(tm)". Up to 5.15, the kernel would > simply ignore such directive. It now honours it. At the time we were working on this driver, we were searching for a way to implement the SoC-to-CPU interrupt mapping. "interrupt-map" seemed like a good match. Looking back at the DT spec, my understanding now that it should only be used for one-to-one mappings, like Marc noted. Just to be clear, I'm not the expert on this platform's interrupt handling, but I would like to provide some extra context. Since we don't have any proper documentation, I've been looking at the SDK today to understand how the mapping works. Currently the mapping is written in the DT as: <SOC_IRQ &cpuintc IRR_VALUE>. The SDK only ever sets IRR values 1-5. As for the other values: * 0 doesn't appear to trigger anything, * 6 results in unhandled interrupts on IRQ #7 (MIPS R4K timer), * 7 causes the timer to be unable to claim its interrupt (because this driver already took it?). The IRR_VALUE is currently translated literaly to a CPU IRQ, but it appears that this is wrong. The SDK code for u-boot maps IRR values of {4,5} to respectively CAUSEF_IP{5,6}. I think the IRR values should be seen as interrupt priorities, rather than as literal parent interrupts. Maybe the following would be an option: intc: interrupt-controller@3000 { compatible = "realtek,rtl-intc"; reg = <0x3000 0x20>; #interrupt-cells = <2>; # [SoC interrupt index, interrupt priority] interrupt-parent = <&cpuintc>; # Optionally add "priority6" if the R4K timer is not used interrupt-names = "priority1", "priority2", "priority3", "priority4", "priority5"; # Optionally add <7> if the R4K timer is not used interrupts = <2>, <3>, <4>, <5>, <6>; }; serial@2000 { ... # Use SoC interrupt 31 from intc, with priority 2 interrupt-parent = <&intc> interrupts = <31 2>; }; Although I'm not sure how well this would extend to a CPU with two threads and matching interrupt controllers, while still being able to perform irq balancing. > > There are only three solution to this: > > (1) we change the DT and the driver so that it actually describes the > HW rather than some crazy interpretation. This means breaking backward > compatibility with older kernels on new DT, as well as new kernels on > old DTs. > > (2) we add a quirk to the core DT parsing code to ignore an > interrupt-map property placed in a "realtek,rtl-intc" node. > (3) we revert the change and break the Apple M1. > > I'm obviously not keen on (3). I can (sort of) deal with (2), but I'd > rather do (1) because what currently is in the DT doesn't describe the > HW in any shape or form. I don't feel we should be breaking other people's shiny new toys either :-) As far as I know most (all) users come via OpenWrt, using backported patches. DT sources are also in the OpenWrt tree, so we could convert in one patch series with minimal breakage. The devices themselves don't provide any binary DT, so that's not really an issue. If there's time and this is within the scope of patches for an RC, I would prefer (1). Otherwise we could wait like Birger suggested, until we have a better understaning of how to work with SMT, and do (2) in the meantime. Alternatively, a second compatible could perhaps be introduced and the current one would be deprecated, using (2) to prevent breaking 5.16+ kernels. I don't think that's really worth the effort though. Best, Sander ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1 2021-11-21 20:33 ` Sander Vanheule @ 2021-11-21 21:11 ` John Crispin 2021-11-22 10:33 ` Marc Zyngier 0 siblings, 1 reply; 8+ messages in thread From: John Crispin @ 2021-11-21 21:11 UTC (permalink / raw) To: Sander Vanheule, Marc Zyngier, Rob Herring, Birger Koblitz Cc: Lorenzo Pieralisi, Bjorn Helgaas, Bert Vermeulen, Thomas Gleixner, linux-kernel, devicetree, Frank Rowand On 21.11.21 21:33, Sander Vanheule wrote: > Alternatively, a second compatible could perhaps be introduced and the current > one would be deprecated, using (2) to prevent breaking 5.16+ kernels. I don't > think that's really worth the effort though. > > Best, Hey, I think that what Marc proposed as (1) is the clean solution. We want to describe the HW as it exists. Yes we have zero docs, and the RLT 2.6 sdk kernel is a pain to extract info from, yet we should move fwd with a clean implementation. breaking pseudo owrt dts ABI is imho acceptable. owrt users are well able to reflash their units from uboot, they are at the end flying without wings on bleeding edge. asking for some backward compat for a de-facto broken dts mapping of the HW is imho a no-go. John ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1 2021-11-21 21:11 ` John Crispin @ 2021-11-22 10:33 ` Marc Zyngier 0 siblings, 0 replies; 8+ messages in thread From: Marc Zyngier @ 2021-11-22 10:33 UTC (permalink / raw) To: John Crispin Cc: Sander Vanheule, Rob Herring, Birger Koblitz, Lorenzo Pieralisi, Bjorn Helgaas, Bert Vermeulen, Thomas Gleixner, linux-kernel, devicetree, Frank Rowand On Sun, 21 Nov 2021 21:11:15 +0000, John Crispin <john@phrozen.org> wrote: > > > > On 21.11.21 21:33, Sander Vanheule wrote: > > Alternatively, a second compatible could perhaps be introduced and the current > > one would be deprecated, using (2) to prevent breaking 5.16+ kernels. I don't > > think that's really worth the effort though. > > > > Best, > > Hey, > > I think that what Marc proposed as (1) is the clean solution. We want > to describe the HW as it exists. Yes we have zero docs, and the RLT > 2.6 sdk kernel is a pain to extract info from, yet we should move fwd > with a clean implementation. > > breaking pseudo owrt dts ABI is imho acceptable. owrt users are well > able to reflash their units from uboot, they are at the end flying > without wings on bleeding edge. asking for some backward compat for a > de-facto broken dts mapping of the HW is imho a no-go. I'm afraid this ship has sailed a long time ago. As I found out, there are a number of drivers having perpetuated the same horror: + "CBEA,platform-spider-pic", + "sti,platform-spider-pic", + "realtek,rtl-intc", + "fsl,ls1021a-extirq", + "fsl,ls1043a-extirq", + "fsl,ls1088a-extirq", + "renesas,rza1-irqc", We can't just change the bindings for those. For the first two, the DT is provided by the FW. For the others, there are numerous systems in the wild, and we can't break them (DT and kernel must be upgradable independently). I've posted a quirk patch[1], and I'd appreciate any feedback on whether it fixes your problem. Thanks, M. [1] https://lore.kernel.org/r/20211122103032.517923-1-maz@kernel.org -- Without deviation from the norm, progress is not possible. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-11-22 10:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-18 15:56 realtek,rtl-intc IRQ mapping broken on 5.16-rc1 Sander Vanheule 2021-11-18 19:19 ` Marc Zyngier 2021-11-18 19:45 ` Sander Vanheule 2021-11-19 14:48 ` Marc Zyngier 2021-11-19 19:09 ` Birger Koblitz 2021-11-21 20:33 ` Sander Vanheule 2021-11-21 21:11 ` John Crispin 2021-11-22 10:33 ` Marc Zyngier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).