Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0DA6C433EF for ; Fri, 19 Nov 2021 14:48:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C9461615E2 for ; Fri, 19 Nov 2021 14:48:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236202AbhKSOvc convert rfc822-to-8bit (ORCPT ); Fri, 19 Nov 2021 09:51:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:41952 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236135AbhKSOvR (ORCPT ); Fri, 19 Nov 2021 09:51:17 -0500 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6063B610F8; Fri, 19 Nov 2021 14:48:15 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mo5BU-006ZBc-Jy; Fri, 19 Nov 2021 14:48:13 +0000 Date: Fri, 19 Nov 2021 14:48:12 +0000 Message-ID: <877dd46w2b.wl-maz@kernel.org> From: Marc Zyngier To: Sander Vanheule , Rob Herring Cc: Lorenzo Pieralisi , Bjorn Helgaas , Birger Koblitz , Bert Vermeulen , John Crispin , Thomas Gleixner , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Frank Rowand Subject: Re: realtek,rtl-intc IRQ mapping broken on 5.16-rc1 In-Reply-To: References: <87ilwp6zm6.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sander@svanheule.net, robh+dt@kernel.org, lorenzo.pieralisi@arm.com, bhelgaas@google.com, mail@birger-koblitz.de, bert@biot.com, john@phrozen.org, tglx@linutronix.de, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, frowand.list@gmail.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 18 Nov 2021 19:45:26 +0000, Sander Vanheule 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 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.