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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 464ECC433F5 for ; Mon, 9 May 2022 08:55:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=44NW+yC0rlWy4GOnYExpXxnjPNCgca4AXYbI9FebQ2E=; b=1vyhwK84kkPCX2 6lhI7Sjb4Nia1jBK4kaOhf9vyN3Wfr9M1PvSr5Vh6A45XosdFn9NRzgX76JwMFgdr2OYAwqQxUzio q6b1N+ybcrRdUDaml6359pOBnXzpaUFeaw4VUyHdcHWOBLK6dcyL0FfDuN/oJXk4FmDJ00gD33xOa /k+s0m2W2CksYdSxkS5To+o/xWXfZ9TjD/FrDMCd/t5TqrNMu30G45r9GTquSDpmtXjuIaBi0/J3y JY1ddtSWKN/cnmRCqF5bhsCJCwJlGhciVznyJPX80Pz+22A5nUT618wqEc440lvXS0pJYdsXrEcOs y/weAMxVAPV1bq/nAG/g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nnzA6-00DFgh-Ka; Mon, 09 May 2022 08:54:39 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nnzA1-00DFe4-QU for linux-arm-kernel@lists.infradead.org; Mon, 09 May 2022 08:54:35 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EF85F1042; Mon, 9 May 2022 01:54:32 -0700 (PDT) Received: from FVFF77S0Q05N (unknown [10.57.3.22]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 203253F66F; Mon, 9 May 2022 01:54:28 -0700 (PDT) Date: Mon, 9 May 2022 09:54:21 +0100 From: Mark Rutland To: Lukas Wunner Cc: maz@kernel.org, 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}() Message-ID: References: <20211026092504.27071-1-mark.rutland@arm.com> <20211026092504.27071-18-mark.rutland@arm.com> <20220506203242.GA1855@wunner.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220506203242.GA1855@wunner.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220509_015433_936740_6519B4CF X-CRM114-Status: GOOD ( 22.42 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. > I believe the above change causes a regression in drivers/gpio/gpio-dln2.c > such that a gratuitous WARN splat is now emitted. Do you mean you beleive that from inspection, or are you actually seeing this go wrong in practice? If it's the latter, are you able to give a copy of the dmesg splat? Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel