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 77B82C4332F for ; Mon, 6 Nov 2023 11:36:05 +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:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=EdpJwjmQHwm+3qX2ABIIBsrEkjQbfwKA62IrKvhM7LQ=; b=Ms653K+dDTtl/Y L0CfVmudqpJma3OdQ57+iEQDJVi3f/ishzkBmfCZ/X6QSc0IYYeVGcTlDAaeKHJOLXPSiJ9n6k5XB TXkNuFK5XbeNKdmXfjdnCCOeKUVfluQdkELGbcAkq9o88Rs4VTImxflD9ZktHRF7CIJO6kRvKbS1o Q7nyZ6TbtcnK0+aldPINTusfVUEYlk+BsW43ufqqh9B05txKoyhjVEdnmkctjI1be5xvnkDy5OD4k ZP0R52DoQnSACydSVQq3UcqJ1lmFderrJ35gAX/E05GWLvOa1sWbUoIDqpzqkZIx0p6ciCV9+/zWR CGVSVoryz6HTY5PQkUuw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qzxtK-00GOf3-1c; Mon, 06 Nov 2023 11:35:38 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qzxtH-00GOeB-07; Mon, 06 Nov 2023 11:35:36 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 4E80BCE0AD4; Mon, 6 Nov 2023 11:35:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 832BAC433C7; Mon, 6 Nov 2023 11:35:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1699270531; bh=fI4NKuZ1uY8mqL9yZ9YNJndkjv1j7nVGFqh2pflGyYI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cRiY+eu6yXREipoxzeem9UkMf7DbKLyTEsBhihxAIIk9nQ7OhutANlrX0EN63aFg8 ZSOLFibjhi2PMsmJgXzpwOvA3yqj+aXKhPs5qY42O3Uubyo3b9ra3w1ryHOdHG+HiZ lHOvlA1VxBzJlQ/bT8UqOpfVLA184ZKyXm6dfKOVjFk5US/uhLcvJeH9TagyH2mwcu 9b39ZbgDKTEhKmjrt0MJvhXN1mZbmQCjYEQL13faJBplEzfT8BihvSFWhGl8cQUWBC bWSHz+fQSNq7mqI8jiAcEbQjHnTmI/qTbh4GYesnI1QXEQSU6GqcBjGWWa/rNB3tBe ESW6CSQ0mYtcg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qzxtA-00AkGy-HO; Mon, 06 Nov 2023 11:35:28 +0000 Date: Mon, 06 Nov 2023 11:35:27 +0000 Message-ID: <86fs1j15ds.wl-maz@kernel.org> From: Marc Zyngier To: Thomas Gleixner , Bjorn Helgaas Cc: Sunil V L , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, linux-serial@vger.kernel.org, Catalin Marinas , Will Deacon , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Rafael J . Wysocki" , Len Brown , Bjorn Helgaas , Anup Patel , Greg Kroah-Hartman , Jiri Slaby , Conor Dooley , Andrew Jones , Atish Kumar Patra , Haibo Xu Subject: Re: [RFC PATCH v2 13/21] irqchip: riscv-intc: Add ACPI support for AIA In-Reply-To: <87jzr82c3h.ffs@tglx> References: <20231026165150.GA1825130@bhelgaas> <87jzr82c3h.ffs@tglx> 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/29.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tglx@linutronix.de, helgaas@kernel.org, sunilvl@ventanamicro.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org, linux-serial@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, rafael@kernel.org, lenb@kernel.org, bhelgaas@google.com, anup@brainfault.org, gregkh@linuxfoundation.org, jirislaby@kernel.org, conor.dooley@microchip.com, ajones@ventanamicro.com, atishp@rivosinc.com, haibo1.xu@intel.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231106_033535_426638_F26C6D90 X-CRM114-Status: GOOD ( 27.63 ) 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, 27 Oct 2023 18:45:38 +0100, Thomas Gleixner wrote: > > On Thu, Oct 26 2023 at 11:51, Bjorn Helgaas wrote: > > On Thu, Oct 26, 2023 at 01:53:36AM +0530, Sunil V L wrote: > >> The RINTC subtype structure in MADT also has information about other > >> interrupt controllers like MMIO. So, save those information and provide > >> interfaces to retrieve them when required by corresponding drivers. > > > >> @@ -218,7 +306,19 @@ static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header, > > > >> + * MSI controller (IMSIC) in RISC-V is optional. So, unless > >> + * IMSIC is discovered, set system wide MSI support as > >> + * unsupported. Once IMSIC is probed, MSI support will be set. > >> + */ > >> + pci_no_msi(); > > > > It doesn't seem like we should have to tell the PCI core about > > functionality we *don't* have. > > > > I would think IMSIC would be detected before enumerating PCI devices > > that might use it, and if we *haven't* found an IMSIC by the time we > > get to pci_register_host_bridge(), would/should we set > > PCI_BUS_FLAGS_NO_MSI there? > > > > I see Thomas is cc'd; he'd have better insight. > > I was not really involved with this bus and MSI domain logic. Marc > should know. CC'ed. The canonical way of doing this is by the platform expressing that there is no linkage between the PCIe RC and the MSI controller. If there is no MSI domain associated with the RC, then by extension the endpoints don't get one either. There are additional quirks linked to the msi_domain host bridge property, allowing the host bridge driver to indicate that it isn't in charge of MSIs, but that a third party may provide it (in which case a MSI irq domain will be associated with it). In any case, slapping a pci_no_msi() call in an irqchip driver is gross and most probably a sign that this is going in the wrong direction, specially as this is platform-wide. The only cases I'd expect this function to be called are: - Platform or firmware explicitly disallowing MSIs - pci=nomsi on the command line none of which are the business of an irqchip driver. HTH, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel