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 A11A6C4332F for ; Mon, 6 Nov 2023 11:35:50 +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:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject: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=Oawuq9V5WLyhw0PcWOvQ71sW8jkuU4fQtkwjuIuLDLE=; b=wAdXuU22QraHik mYP2OWhrkaDhdkZWoDa6rpcuVqvgq8eSlOuHkOd2fWhRDCbCmqVCJUhGbg+rf/4EE97yOdw97C9wG RSbR56JHDDzN1m392JRzLqZzj2cV3Xdd3HQiK9ZE6yOTXlvAJTpJei7B0mGKhe7Q79qAHTr9vxnuh g3oF/LlsJThP+9l9Uh8LGde8ThzPZj21xOT34b2a9lr/R/7exc+hQxAh1HQTU80PDyrBJGPdh4D4x eCIa41WAvqRIOgIgqdQMK3ktPtBCFPOS3ybQ839o5OUvZeGwuxN2dGsHDkhUzhb6BPvW7G6lPDP3Y VQIJjKH1U4NJkddFa8Fg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qzxtL-00GOfH-02; Mon, 06 Nov 2023 11:35:39 +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 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-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Rafael J . Wysocki" , linux-pci@vger.kernel.org, Atish Kumar Patra , Conor Dooley , linux-riscv@lists.infradead.org, Jiri Slaby , Haibo Xu , Anup Patel , linux-acpi@vger.kernel.org, linux-serial@vger.kernel.org, Catalin Marinas , Andrew Jones , Albert Ou , Will Deacon , Paul Walmsley , Bjorn Helgaas , linux-arm-kernel@lists.infradead.org, Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Palmer Dabbelt , Len Brown Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=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-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv