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 39669C46467 for ; Mon, 9 May 2022 09:30:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237142AbiEIJdN (ORCPT ); Mon, 9 May 2022 05:33:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238238AbiEIJNd (ORCPT ); Mon, 9 May 2022 05:13:33 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84141201EA8; Mon, 9 May 2022 02:09:33 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B9285B810A6; Mon, 9 May 2022 09:09:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 72612C385AB; Mon, 9 May 2022 09:09:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652087369; bh=rYlTPSQ6FXF7zF9p7LDZTYP/JQglCROOG1/iNS2upeo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fkuJHZv3/usYj/OGKMcXT2qWre9/pHK4qg5n16+A6fFX+IDvUi8SI9RV5GRCWCshT WOZKLk1Y13ZwwbjkGw0qlEfxoSM7yG4L6cvqL0tz5pUhXKX/eXT6GUAvuQxyTtJJne Bx5AuXTil4kjjnugWv8OQJaYJD9DC8tAGIAzbXxipGExl9NWlQGFd7favllpB/NRpN j01O7gs2TjlJiWP9SzMDRzDHYLBR7SKB3NJ8uAkyoTCoH3OhqHlbm35U6YcaUbZKsc /9HtUeroHAVvTdVK4auEZnSnF9hT2mZbP9jd573dccqjDg+HEETQQ0ssMe3zqRjvVW C2n0H3hWWU4RA== 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 1nnzOQ-009uuU-VM; Mon, 09 May 2022 10:09:27 +0100 Date: Mon, 09 May 2022 10:09:26 +0100 Message-ID: <87h75z6pix.wl-maz@kernel.org> From: Marc Zyngier To: Mark Rutland Cc: Lukas Wunner , Linus Walleij , Bartosz Golaszewski , linux-gpio@vger.kernel.org, Octavian Purdila , linux-kernel@vger.kernel.org, aou@eecs.berkeley.edu, catalin.marinas@arm.com, deanbo422@gmail.com, green.hu@gmail.com, guoren@kernel.org, jonas@southpole.se, kernelfans@gmail.com, linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, nickhu@andestech.com, palmer@dabbelt.com, paul.walmsley@sifive.com, shorne@gmail.com, stefan.kristiansson@saunalahti.fi, tglx@linutronix.de, tsbogend@alpha.franken.de, vgupta@kernel.org, vladimir.murzin@arm.com, will@kernel.org Subject: Re: [PATCH v2 17/17] irq: remove handle_domain_{irq,nmi}() In-Reply-To: References: <20211026092504.27071-1-mark.rutland@arm.com> <20211026092504.27071-18-mark.rutland@arm.com> <20220506203242.GA1855@wunner.de> 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: mark.rutland@arm.com, lukas@wunner.de, linus.walleij@linaro.org, brgl@bgdev.pl, linux-gpio@vger.kernel.org, octavian.purdila@nxp.com, linux-kernel@vger.kernel.org, aou@eecs.berkeley.edu, catalin.marinas@arm.com, deanbo422@gmail.com, green.hu@gmail.com, guoren@kernel.org, jonas@southpole.se, kernelfans@gmail.com, linux-arm-kernel@lists.infradead.org, linux@armlinux.org.uk, nickhu@andestech.com, palmer@dabbelt.com, paul.walmsley@sifive.com, shorne@gmail.com, stefan.kristiansson@saunalahti.fi, tglx@linutronix.de, tsbogend@alpha.franken.de, vgupta@kernel.org, vladimir.murzin@arm.com, will@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, 09 May 2022 09:54:21 +0100, Mark Rutland wrote: > > On Fri, May 06, 2022 at 10:32:42PM +0200, Lukas Wunner wrote: > > On Tue, Oct 26, 2021 at 10:25:04AM +0100, Mark Rutland wrote: > > > Now that entry code handles IRQ entry (including setting the IRQ regs) > > > before calling irqchip code, irqchip code can safely call > > > generic_handle_domain_irq(), and there's no functional reason for it to > > > call handle_domain_irq(). > > > > > > Let's cement this split of responsibility and remove handle_domain_irq() > > > entirely, updating irqchip drivers to call generic_handle_domain_irq(). > > > > > > For consistency, handle_domain_nmi() is similarly removed and replaced > > > with a generic_handle_domain_nmi() function which also does not perform > > > any entry logic. > > > > > > Previously handle_domain_{irq,nmi}() had a WARN_ON() which would fire > > > when they were called in an inappropriate context. So that we can > > > identify similar issues going forward, similar WARN_ON_ONCE() logic is > > > added to the generic_handle_*() functions, and comments are updated for > > > clarity and consistency. > > [...] > > > int generic_handle_domain_irq(struct irq_domain *domain, unsigned int hwirq) > > > { > > > + WARN_ON_ONCE(!in_irq()); > > > return handle_irq_desc(irq_resolve_mapping(domain, hwirq)); > > > } > > > EXPORT_SYMBOL_GPL(generic_handle_domain_irq); > > > > Why isn't the WARN_ON_ONCE() conditional on handle_enforce_irqctx()? > > (See handle_irq_desc() and c16816acd086.) > > I did this for consistency with the in_nmi() check in > generic_handle_domain_nmi(); I was unaware of commit c16816acd086 and > IRQD_HANDLE_ENFORCE_IRQCTX. > > I'll have ot leave it to Marc and Thomas as to what we should do there. My preference would be to not introduce things that result in different behaviours for drivers, specially for things that are evidently cross-architecture such as USB drivers (which seems to be the case here). I'd rather do something that allows these to be handled in the right context such as a self-IPI. This would certainly work for the GIC. No idea whether this is valid for x86, which is the other user. Thanks, M. -- Without deviation from the norm, progress is not possible.