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 F01E3C433FE for ; Fri, 25 Nov 2022 00:11:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229648AbiKYALK (ORCPT ); Thu, 24 Nov 2022 19:11:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229542AbiKYALH (ORCPT ); Thu, 24 Nov 2022 19:11:07 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD1226F0C2; Thu, 24 Nov 2022 16:11:03 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669335062; 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=rxSVflZ18PlqJMx8oWzcA732KZVFL71UoUUiiLTILXQ=; b=yurYLRMCRLJGDk8CJFNPQWjf/jy4ahKrCP1f1c71Jp3BX5h41lcuiBIsTbfS3KfGe2xH2Q gmzEyDMq45hG4l7QUTUiBHBKYyy/lk18jGYdG7LRFMvWoaGSdodK/MnKVpIF0Whrl0pjcS F4TzwrsX8FKusvObbj326QZ5/a2ez0P4uokzAKnEjiv672BwZA/AkCK8LL1xTuhUWpCYcS OwJDX8PqSw/nLZQLBGR4YA4ntf7wlI27jXmnnYkSSIzuzO8oubsDLnlDUaxxZwm0J0fuX+ B07IqVxTn/PuqnFUV3eBQkuttdlQmtYRr1zxL0xOFQu5P0bXthbC9H/eJ+Wt9w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669335062; 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=rxSVflZ18PlqJMx8oWzcA732KZVFL71UoUUiiLTILXQ=; b=uDlLaBXfkmTGZACcqFghOT2Vd+CefArCf3vqfkNV8sj5GMejeu7zKbsyQqtUPMvW6q3wxI 4RgNCI64sJ130vCQ== To: Marc Zyngier Cc: LKML , Will Deacon , linux-pci@vger.kernel.org, Bjorn Helgaas , Lorenzo Pieralisi , Greg Kroah-Hartman , Jason Gunthorpe , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Ammar Faizi , Robin Murphy , Lorenzo Pieralisi , Nishanth Menon , Tero Kristo , Santosh Shilimkar , linux-arm-kernel@lists.infradead.org, Vinod Koul , Sinan Kaya , Andy Gross , Bjorn Andersson , Mark Rutland , Shameerali Kolothum Thodi , Zenghui Yu , Shawn Guo , Sascha Hauer , Fabio Estevam Subject: Re: [patch V2 06/40] PCI/MSI: Provide static key for parent mask/unmask In-Reply-To: <86zgcgmpzl.wl-maz@kernel.org> References: <20221121135653.208611233@linutronix.de> <20221121140048.659849460@linutronix.de> <8635a8o65q.wl-maz@kernel.org> <87bkowcx0z.ffs@tglx> <86zgcgmpzl.wl-maz@kernel.org> Date: Fri, 25 Nov 2022 01:11:01 +0100 Message-ID: <87v8n3c2qy.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 24 2022 at 13:38, Marc Zyngier wrote: > On Thu, 24 Nov 2022 13:17:00 +0000, > Thomas Gleixner wrote: >> > I find this a bit odd. If anything, I'd rather drop the masking at the >> > PCI level and keep it local to the interrupt controller, because this >> > is likely to be more universal than the equivalent PCI operation >> > (think multi-MSI, for example, which cannot masks individual MSIs). >> > >> > Another thing is that the static key is a global state. Nothing says >> > that masking one way or the other is a universal thing, specially when >> > you have multiple interrupt controllers dealing with MSIs in different >> > ways. For example, GICv3 can use both the ITS and the GICv3-MBI frame >> > at the same time for different PCI RC. OK, they happen to deal with >> > MSIs in the same way, but you hopefully get my point. >> >> I'm fine with dropping that. I did this because basically all of the >> various ARM PCI/MSI domain implementation have a copy of the same >> functions. Some of them have pointlessly the wrong order because copy & >> pasta is so wonderful.... >> >> So the alternative solution is to provide _ONE_ set of correct callbacks >> and let the domain initialization code override the irq chip callbacks >> of the default PCI/MSI template. > > If the various irqchips can tell the core code whether they want > things to be masked at the PCI level or at the irqchip level, this > would be a move in the right direction. For the GIC, I'd definitely > want things masked locally. > > What I'd like to get rid off is the double masking, as I agree it is > on the "pretty dumb" side of things. Not necessarily. It mitigates the problem of MSI interrupts which can't be masked because the implementers decided to spare the gates. MSI allows that as masking is opt-in... Let me think about it. Thanks, tglx 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 E08D5C433FE for ; Fri, 25 Nov 2022 00:12:35 +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=w9xmCme6IYgNlH2q/1YPHrt5LkeM5YEbLqGbX9yeN8g=; b=3t6cLpl91BSrSb 28K37e0+feJn8y3cjND+t1naizfm7DFlrPiUsliavKOWKOokatqt2vKzr1OApcLsJbjxSoDyNkHyl ORxwAmpCv0J4Q8buBo+uXFKhvQdJOmu8oJ3yk6Ovqxom2yNx7dvdLARzRhH6NnmxHHBvb/iTezYIF lR0bBDjS5FCyvgW5TFt8LkcBnyAnKLCF44HNVlg9STjPcnl5I9ne2mGbPJHLKRJpoyXLLfRfuQgw/ lHJrRBwwLM96I3/Vab7awaLcZ1r+udiJOTQ4qBySR7lzad6aXMyfmcVTET2W+zbnLIE5IH+VYa1yE 30F9BVZVKOlhfULoK9dA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oyMJE-00BtOL-HJ; Fri, 25 Nov 2022 00:11:12 +0000 Received: from galois.linutronix.de ([193.142.43.55]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oyMJB-00BtNR-AD for linux-arm-kernel@lists.infradead.org; Fri, 25 Nov 2022 00:11:10 +0000 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669335062; 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=rxSVflZ18PlqJMx8oWzcA732KZVFL71UoUUiiLTILXQ=; b=yurYLRMCRLJGDk8CJFNPQWjf/jy4ahKrCP1f1c71Jp3BX5h41lcuiBIsTbfS3KfGe2xH2Q gmzEyDMq45hG4l7QUTUiBHBKYyy/lk18jGYdG7LRFMvWoaGSdodK/MnKVpIF0Whrl0pjcS F4TzwrsX8FKusvObbj326QZ5/a2ez0P4uokzAKnEjiv672BwZA/AkCK8LL1xTuhUWpCYcS OwJDX8PqSw/nLZQLBGR4YA4ntf7wlI27jXmnnYkSSIzuzO8oubsDLnlDUaxxZwm0J0fuX+ B07IqVxTn/PuqnFUV3eBQkuttdlQmtYRr1zxL0xOFQu5P0bXthbC9H/eJ+Wt9w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669335062; 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=rxSVflZ18PlqJMx8oWzcA732KZVFL71UoUUiiLTILXQ=; b=uDlLaBXfkmTGZACcqFghOT2Vd+CefArCf3vqfkNV8sj5GMejeu7zKbsyQqtUPMvW6q3wxI 4RgNCI64sJ130vCQ== To: Marc Zyngier Cc: LKML , Will Deacon , linux-pci@vger.kernel.org, Bjorn Helgaas , Lorenzo Pieralisi , Greg Kroah-Hartman , Jason Gunthorpe , Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Ammar Faizi , Robin Murphy , Lorenzo Pieralisi , Nishanth Menon , Tero Kristo , Santosh Shilimkar , linux-arm-kernel@lists.infradead.org, Vinod Koul , Sinan Kaya , Andy Gross , Bjorn Andersson , Mark Rutland , Shameerali Kolothum Thodi , Zenghui Yu , Shawn Guo , Sascha Hauer , Fabio Estevam Subject: Re: [patch V2 06/40] PCI/MSI: Provide static key for parent mask/unmask In-Reply-To: <86zgcgmpzl.wl-maz@kernel.org> References: <20221121135653.208611233@linutronix.de> <20221121140048.659849460@linutronix.de> <8635a8o65q.wl-maz@kernel.org> <87bkowcx0z.ffs@tglx> <86zgcgmpzl.wl-maz@kernel.org> Date: Fri, 25 Nov 2022 01:11:01 +0100 Message-ID: <87v8n3c2qy.ffs@tglx> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221124_161109_539691_87705363 X-CRM114-Status: GOOD ( 21.99 ) 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 Thu, Nov 24 2022 at 13:38, Marc Zyngier wrote: > On Thu, 24 Nov 2022 13:17:00 +0000, > Thomas Gleixner wrote: >> > I find this a bit odd. If anything, I'd rather drop the masking at the >> > PCI level and keep it local to the interrupt controller, because this >> > is likely to be more universal than the equivalent PCI operation >> > (think multi-MSI, for example, which cannot masks individual MSIs). >> > >> > Another thing is that the static key is a global state. Nothing says >> > that masking one way or the other is a universal thing, specially when >> > you have multiple interrupt controllers dealing with MSIs in different >> > ways. For example, GICv3 can use both the ITS and the GICv3-MBI frame >> > at the same time for different PCI RC. OK, they happen to deal with >> > MSIs in the same way, but you hopefully get my point. >> >> I'm fine with dropping that. I did this because basically all of the >> various ARM PCI/MSI domain implementation have a copy of the same >> functions. Some of them have pointlessly the wrong order because copy & >> pasta is so wonderful.... >> >> So the alternative solution is to provide _ONE_ set of correct callbacks >> and let the domain initialization code override the irq chip callbacks >> of the default PCI/MSI template. > > If the various irqchips can tell the core code whether they want > things to be masked at the PCI level or at the irqchip level, this > would be a move in the right direction. For the GIC, I'd definitely > want things masked locally. > > What I'd like to get rid off is the double masking, as I agree it is > on the "pretty dumb" side of things. Not necessarily. It mitigates the problem of MSI interrupts which can't be masked because the implementers decided to spare the gates. MSI allows that as masking is opt-in... Let me think about it. Thanks, tglx _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel