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 26EA3C433F5 for ; Tue, 10 May 2022 23:37:22 +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:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5Xbusxk91oq+tABrCOAd8dYbjbwOvbH1S54HheKyp5g=; b=qkHMz9MF1ctFlD eK8ZsrmOQs+aQtNEL6ni1EZcvzlfFWAJrqxRz9Orv9hzm3wyab9jBKp6/b8LFVpcBeDgM52x5x2T0 Bt2XtrjR5kSsiUJi0BEOqcvHfmMmdbCSa+YcEzhsh79I3aTkTentkGgYDUqcfSfyMiOQlvsZ2iCws KYLFQD5OL5sl3nAVBMb7suUl/wFV0gJGgl/XJKrCyCdoTk7T6F1mGiK7AxhzT0cdfOGWLezBMRfE1 fGDpow0/Vs45N+KUnU4WVeCaOdrVWuJpNq8tK1EDHCP8k9RmlwiR3BJLlt74ArhjakM2W9rKY1Xvd S/noVg030frquMI41owg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1noZOv-004Od6-Da; Tue, 10 May 2022 23:36:21 +0000 Received: from galois.linutronix.de ([2a0a:51c0:0:12e:550::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1noZOr-004OcO-Rp for linux-arm-kernel@lists.infradead.org; Tue, 10 May 2022 23:36:19 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1652225775; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H/EYKbD+5m5rYtUrz9cU8ph/+xjuJsYLEKLmP4yizks=; b=Td0jh6UQTEdUYRd5xnaHNw8KSgjFmg4k8FSTVAaMadw81+zaBWQ1honj/GMlAoXcWJtq6o 8WtVlmhVnMJUcJ+3ZFJZT/HuvbaGkgXgXpkOqYvWJn6bJEpAHPL8cFA/mXzRAqc15QkQ+V MpINp1sRCn8JHKegPRxjlhmce5H94xLcR1BsZ0TI3Z27hDK4Q9hAPyBAc3yST38VLP/m+W KmybeJK3EBvlbJe2V3CT+xFea/dh0T84L7k/J+sNwtAGwcNbg1UsdbVuh17vUmUvMSKZgP jwzPX5ryEapaebK7rRAXz8kD7xFpnnMSZP3hts7BT+yNwLRwagTkCi433Envrg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1652225775; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=H/EYKbD+5m5rYtUrz9cU8ph/+xjuJsYLEKLmP4yizks=; b=/YfHHXkuqYRdWRMkvYVqBbEJaYYHN2qJOO5lbQ5LiAh5X/kNvBy4PxtPsKnSvZPQFqAflL qZ7ojYQ76UfcH0Aw== To: Marc Zyngier , 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, 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: <87h75z6pix.wl-maz@kernel.org> References: <20211026092504.27071-1-mark.rutland@arm.com> <20211026092504.27071-18-mark.rutland@arm.com> <20220506203242.GA1855@wunner.de> <87h75z6pix.wl-maz@kernel.org> Date: Wed, 11 May 2022 01:36:15 +0200 Message-ID: <877d6tot8w.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220510_163618_081780_680B1672 X-CRM114-Status: GOOD ( 21.28 ) 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 Mon, May 09 2022 at 10:09, Marc Zyngier wrote: > On Mon, 09 May 2022 09:54:21 +0100, > Mark Rutland wrote: >> > 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). No. USB drivers which synthesize their interrupts from a received packet work perfectly fine on all architectures because the interrupt domain and interrupt chip they are using are a software construct designed for the purpose and have no hard interrupt context requirements. The reason why this is done is to leverage the interrupt driven PHY status changes instead of enforcing timer based polling. The charm is that the phy code does not have to grow another wart and just uses the offered synthetic interrupt. There are other places which do similar things for the same reason. This also provides the beloved statistics in /proc/interrupt, tracepoints etc. out of the box without having to add extra muck into yet another subsystem. > 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. This interrupt is neither directly nor indirectly connected to GIC or APIC. It's synthesized. So what would the self-IPI help? And no, I don't want to create infrastructure to allocate a pseudo device vector on x86 just to be able to self-IPI this USB synthesized interrupt. That'd be yet another horrorshow and worse a horrorshow for no reason and zero value. IRQD_HANDLE_ENFORCE_IRQCTX was introduced to be able to differentiate between interrupt chips which require a particular context and chips which can handle it perfectly fine to have e.g. their software retrigger handled by directly invoking the handler from an arbitrary context. I wish this would be the case on x86. That would eliminate a boatload of horrible code. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel