From mboxrd@z Thu Jan 1 00:00:00 1970 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44B32C4332F for ; Mon, 22 Nov 2021 13:54:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239613AbhKVN5c (ORCPT ); Mon, 22 Nov 2021 08:57:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:39838 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229984AbhKVN5b (ORCPT ); Mon, 22 Nov 2021 08:57:31 -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 C59B160C3F; Mon, 22 Nov 2021 13:54:24 +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 1mp9m2-00749T-Hd; Mon, 22 Nov 2021 13:54:22 +0000 Date: Mon, 22 Nov 2021 13:54:22 +0000 Message-ID: <8735no70tt.wl-maz@kernel.org> From: Marc Zyngier To: Geert Uytterhoeven Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, kernel-team@android.com, Rob Herring , John Crispin , Biwen Li , Chris Brandt , linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH] of/irq: Add a quirk for controllers with their own definition of interrupt-map In-Reply-To: References: <20211122103032.517923-1-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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: geert@linux-m68k.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, kernel-team@android.com, robh@kernel.org, john@phrozen.org, biwen.li@nxp.com, chris.brandt@renesas.com, linux-renesas-soc@vger.kernel.org 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 Mon, 22 Nov 2021 13:10:32 +0000, Geert Uytterhoeven wrote: > > Hi Marc, > > On Mon, Nov 22, 2021 at 11:30 AM Marc Zyngier wrote: > > Since 041284181226 ("of/irq: Allow matching of an interrupt-map local > > to an interrupt controller"), a handful of interrupt controllers have > > stopped working correctly. This is due to the DT exposing a non-sensical > > interrupt-map property, and their drivers relying on the kernel ignoring > > this property. > > > > Since we cannot realistically fix this terrible behaviour, add a quirk > > for the limited set of devices that have implemented this monster, > > and document that this is a pretty bad practice. > > > > Cc: Rob Herring > > Cc: John Crispin > > Cc: Biwen Li > > Cc: Chris Brandt > > Cc: Geert Uytterhoeven > > Signed-off-by: Marc Zyngier > > Thanks for your patch! > > > --- a/drivers/of/irq.c > > +++ b/drivers/of/irq.c > > @@ -76,6 +76,36 @@ struct device_node *of_irq_find_parent(struct device_node *child) > > } > > EXPORT_SYMBOL_GPL(of_irq_find_parent); > > > > +/* > > + * These interrupt controllers abuse interrupt-map for unspeakable > > + * reasons and rely on the core code to *ignore* it (the drivers do > > + * their own parsing of the property). > > + * > > + * If you think of adding to the list for something *new*, think > > + * again. There is a high chance that you will be sent back to the > > + * drawing board. > > + */ > > +static const char * const of_irq_imap_abusers[] = { > > + "CBEA,platform-spider-pic", > > + "sti,platform-spider-pic", > > + "realtek,rtl-intc", > > + "fsl,ls1021a-extirq", > > + "fsl,ls1043a-extirq", > > + "fsl,ls1088a-extirq", > > + "renesas,rza1-irqc", > > +}; > > Are you sure "renesas,rza1-irqc" handles this wrong? How should it > be handled instead? I read the other thread[1], but didn't became > any wiser: interrupts are mapped one-to-one with the RZ/A1 IRQC. > > In both v5.15 and v5.16-rc1, interrupts seem to work fine on RSK+RZA1 > and RZA2MEVB, both with gpio-keys and when used as a wake-up interrupt. This is odd. 5.16-rc1 should actively breaks the behaviour, as each interrupt is directly routed to the GIC. Here's an extract of the DT for r7s9210: interrupt-map = <0 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, <1 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, <2 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, <3 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, <4 0 &gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, <5 0 &gic GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, <6 0 &gic GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, <7 0 &gic GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; I expect v5.16-rc1 to honour the routing described here and not involve rza1-irqc, because that's what the DT says. > With this patch applied, I see double keypresses with evtest: when > pressing a key, I get a key-down event, immediately followed by a > key-up event. When releasing the key, I again get two events. > > Good (v5.15 or v5.16-rc1): > > Event: time 1637585631.288990, type 1 (EV_KEY), code 2 (KEY_1), value 1 > Event: time 1637585631.288990, -------------- SYN_REPORT ------------ > Event: time 1637585631.499924, type 1 (EV_KEY), code 2 (KEY_1), value 0 > Event: time 1637585631.499924, -------------- SYN_REPORT ------------ > > Bad (v5.16-rc1 + this patch): > > Event: time 1637585341.946647, type 1 (EV_KEY), code 2 (KEY_1), value 1 > Event: time 1637585341.946647, -------------- SYN_REPORT ------------ > Event: time 1637585341.960256, type 1 (EV_KEY), code 2 (KEY_1), value 0 > Event: time 1637585341.960256, -------------- SYN_REPORT ------------ > Event: time 1637585342.146775, type 1 (EV_KEY), code 2 (KEY_1), value 1 > Event: time 1637585342.146775, -------------- SYN_REPORT ------------ > Event: time 1637585342.160092, type 1 (EV_KEY), code 2 (KEY_1), value 0 > Event: time 1637585342.160092, -------------- SYN_REPORT ------------ Is there any chance you could trace whether rza1-irqc gets called at all when setting up and handling the interrupt? Thanks, M. -- Without deviation from the norm, progress is not possible.