From: Arnd Bergmann <arnd@arndb.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Boqun Feng <boqun.feng@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux on Hyper-V List <linux-hyperv@vger.kernel.org>,
linux-pci <linux-pci@vger.kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
"K. Y. Srinivasan" <kys@microsoft.com>,
Haiyang Zhang <haiyangz@microsoft.com>,
Stephen Hemminger <sthemmin@microsoft.com>,
Wei Liu <wei.liu@kernel.org>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Rob Herring <robh@kernel.org>, Clint Sbisa <csbisa@amazon.com>,
Ard Biesheuvel <ardb@kernel.org>,
Sunil Muthuswamy <sunilmut@microsoft.com>,
Marc Zyngier <maz@kernel.org>
Subject: Re: [RFC 1/2] arm64: PCI: Allow use arch-specific pci sysdata
Date: Sat, 20 Mar 2021 13:54:50 +0100 [thread overview]
Message-ID: <CAK8P3a3qj=9KEN=X2uGCq0TrOGpyPw1Gwipmn=Gqx4LAfqUEDQ@mail.gmail.com> (raw)
In-Reply-To: <20210319211246.GA250618@bjorn-Precision-5520>
On Fri, Mar 19, 2021 at 10:14 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > However, for a virtualized PCI bus, there might be no enough data in of
> > or acpi table to create a pci_config_window. This is similar to the case
> > where CONFIG_PCI_DOMAINS_GENERIC=n, IOW, architectures use their own
> > structure for sysdata, so no apci table lookup is required.
> >
> > In order to enable Hyper-V's virtual PCI (which doesn't have acpi table
> > entry for PCI) on ARM64 (which selects CONFIG_PCI_DOMAINS_GENERIC), we
> > introduce arch-specific pci sysdata (similar to the one for x86) for
> > ARM64, and allow the core PCI code to detect the type of sysdata at the
> > runtime. The latter is achieved by adding a pci_ops::use_arch_sysdata
> > field.
> >
> > Originally-by: Sunil Muthuswamy <sunilmut@microsoft.com>
> > Signed-off-by: Boqun Feng (Microsoft) <boqun.feng@gmail.com>
> > ---
> > arch/arm64/include/asm/pci.h | 29 +++++++++++++++++++++++++++++
> > arch/arm64/kernel/pci.c | 15 ++++++++++++---
> > include/linux/pci.h | 3 +++
> > 3 files changed, 44 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > index b33ca260e3c9..dade061a0658 100644
> > --- a/arch/arm64/include/asm/pci.h
> > +++ b/arch/arm64/include/asm/pci.h
> > @@ -22,6 +22,16 @@
> >
> > extern int isa_dma_bridge_buggy;
> >
> > +struct pci_sysdata {
> > + int domain; /* PCI domain */
> > + int node; /* NUMA Node */
> > +#ifdef CONFIG_ACPI
> > + struct acpi_device *companion; /* ACPI companion device */
> > +#endif
> > +#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
> > + void *fwnode; /* IRQ domain for MSI assignment */
> > +#endif
> > +};
>
> Our PCI domain code is really a mess (mostly my fault) and I hate to
> make it even more complicated by adding more switches, e.g.,
> ->use_arch_sysdata.
>
> I think the design problem is that PCI host bridge drivers should
> supply the PCI domain up front instead of having callbacks to extract
> it.
>
> We could put "int domain_nr" in struct pci_host_bridge, and the arch
> code or host bridge driver (pcibios_init_hw(), *_pcie_probe(), VMD,
> HV, etc) could fill in pci_host_bridge.domain_nr before calling
> pci_scan_root_bus_bridge() or pci_host_probe().
>
> Then maybe we could get rid of pci_bus_find_domain_nr() and some of
> the needlessly arch-specific implementations of pci_domain_nr().
> I think we likely could get rid of CONFIG_PCI_DOMAINS_GENERIC, too,
> eventually.
Agreed. I actually still have a (not really tested) patch series to clean up
the pci host bridge registration, and this should make this a lot easier
to add on top.
I should dig that out of my backlog and post for review.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-20 12:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 16:19 [RFC 0/2] PCI: Introduce pci_ops::use_arch_sysdata Boqun Feng
2021-03-19 16:19 ` [RFC 1/2] arm64: PCI: Allow use arch-specific pci sysdata Boqun Feng
2021-03-19 21:12 ` Bjorn Helgaas
2021-03-20 12:54 ` Marc Zyngier
2021-03-20 13:03 ` Arnd Bergmann
2021-03-20 13:23 ` Marc Zyngier
2021-03-20 14:24 ` Arnd Bergmann
2021-03-20 17:14 ` Marc Zyngier
2021-03-20 12:54 ` Arnd Bergmann [this message]
2021-03-20 16:09 ` Arnd Bergmann
2021-03-29 14:32 ` Boqun Feng
2021-03-29 14:43 ` Arnd Bergmann
2021-03-20 12:52 ` Arnd Bergmann
2021-03-19 16:19 ` [RFC 2/2] PCI: hv: Tell PCI core arch-specific sysdata is used Boqun Feng
2021-03-19 19:04 ` [RFC 0/2] PCI: Introduce pci_ops::use_arch_sysdata Bjorn Helgaas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK8P3a3qj=9KEN=X2uGCq0TrOGpyPw1Gwipmn=Gqx4LAfqUEDQ@mail.gmail.com' \
--to=arnd@arndb.de \
--cc=ardb@kernel.org \
--cc=bhelgaas@google.com \
--cc=boqun.feng@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=csbisa@amazon.com \
--cc=haiyangz@microsoft.com \
--cc=helgaas@kernel.org \
--cc=kys@microsoft.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=maz@kernel.org \
--cc=robh@kernel.org \
--cc=sthemmin@microsoft.com \
--cc=sunilmut@microsoft.com \
--cc=wei.liu@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).