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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8AD7C433E6 for ; Fri, 28 Aug 2020 11:23:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9D4D820872 for ; Fri, 28 Aug 2020 11:23:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729209AbgH1LXi (ORCPT ); Fri, 28 Aug 2020 07:23:38 -0400 Received: from foss.arm.com ([217.140.110.172]:46836 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729178AbgH1LWs (ORCPT ); Fri, 28 Aug 2020 07:22:48 -0400 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 10BC931B; Fri, 28 Aug 2020 04:21:52 -0700 (PDT) Received: from e121166-lin.cambridge.arm.com (e121166-lin.cambridge.arm.com [10.1.196.255]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 03F763F66B; Fri, 28 Aug 2020 04:21:47 -0700 (PDT) Date: Fri, 28 Aug 2020 12:21:42 +0100 From: Lorenzo Pieralisi To: Bjorn Helgaas Cc: Thomas Gleixner , LKML , x86@kernel.org, Joerg Roedel , iommu@lists.linux-foundation.org, linux-hyperv@vger.kernel.org, Haiyang Zhang , Jon Derrick , Lu Baolu , Wei Liu , "K. Y. Srinivasan" , Stephen Hemminger , Steve Wahl , Dimitri Sivanich , Russ Anderson , linux-pci@vger.kernel.org, Bjorn Helgaas , Konrad Rzeszutek Wilk , xen-devel@lists.xenproject.org, Juergen Gross , Boris Ostrovsky , Stefano Stabellini , Marc Zyngier , Greg Kroah-Hartman , "Rafael J. Wysocki" , Megha Dey , Jason Gunthorpe , Dave Jiang , Alex Williamson , Jacob Pan , Baolu Lu , Kevin Tian , Dan Williams , Rob Herring Subject: Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable Message-ID: <20200828112142.GA14208@e121166-lin.cambridge.arm.com> References: <20200826112333.992429909@linutronix.de> <20200827182040.GA2049623@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200827182040.GA2049623@bjorn-Precision-5520> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-hyperv-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-hyperv@vger.kernel.org On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote: [...] > And I can't figure out what's special about tegra, rcar, and xilinx > that makes them need it as well. Is there something I could grep for > to identify them? Is there a way to convert them so they don't need > it? I think DT binding and related firmware support are needed to setup the MSI IRQ domains correctly, there is nothing special about tegra, rcar and xilinx AFAIK (well, all native host controllers MSI handling is *special* just to be polite but let's gloss over this for the time being). struct msi_controller, to answer the first question. I have doubts about pci_mvebu too, they do allocate an msi_controller but without methods so it looks pretty much useless. Hyper-V code too seems questionable, maybe there is room for more clean-ups. Lorenzo > > --- a/include/linux/msi.h > > +++ b/include/linux/msi.h > > @@ -193,17 +193,38 @@ void pci_msi_mask_irq(struct irq_data *d > > void pci_msi_unmask_irq(struct irq_data *data); > > > > /* > > - * The arch hooks to setup up msi irqs. Those functions are > > - * implemented as weak symbols so that they /can/ be overriden by > > - * architecture specific code if needed. > > + * The arch hooks to setup up msi irqs. Default functions are implemented > > s/msi/MSI/ to match the one below. > > > + * as weak symbols so that they /can/ be overriden by architecture specific > > + * code if needed. These hooks must be enabled by the architecture or by > > + * drivers which depend on them via msi_controller based MSI handling.