Hi Bjorn,
I'm currently working on virtual PCI support for Hyper-V ARM64 guests.
Similar to virtual PCI on x86 Hyper-V guests, the PCI root bus is not
probed via ACPI (or of), it's probed from Hyper-V VMbus, therefore it
doesn't have config window.
Since ARM64 is a CONFIG_PCI_DOMAINS_GENERIC=y, PCI core code always
treats as the root bus has a config window. So we need to resolve this
and want to reuse the code as much as possible. My current solution is
introducing a pci_ops::use_arch_sysdata, and if it's true, the PCI core
code treats the pci_bus::sysdata as an arch-specific sysdata (rather
than pci_config_window) for CONFIG_PCI_DOMAINS_GENERIC=y architectures.
This allows us to reuse the existing code for Hyper-V PCI controller.
This is simply a proposal, I'm open to any suggestion.
Thanks!
Regards,
Boqun
Boqun Feng (2):
arm64: PCI: Allow use arch-specific pci sysdata
PCI: hv: Tell PCI core arch-specific sysdata is used
arch/arm64/include/asm/pci.h | 29 +++++++++++++++++++++++++++++
arch/arm64/kernel/pci.c | 15 ++++++++++++---
drivers/pci/controller/pci-hyperv.c | 3 +++
include/linux/pci.h | 3 +++
4 files changed, 47 insertions(+), 3 deletions(-)
--
2.30.2
Use the newly introduced ->use_arch_sysdata to tell PCI core, we still
use the arch-specific sysdata way to set up root PCI buses on
CONFIG_PCI_DOMAINS_GENERIC=y architectures, this is preparation fo
Hyper-V ARM64 guest virtual PCI support.
Signed-off-by: Boqun Feng (Microsoft) <redacted>
---
drivers/pci/controller/pci-hyperv.c | 3 +++
1 file changed, 3 insertions(+)
Currently, if an architecture selects CONFIG_PCI_DOMAINS_GENERIC, the
->sysdata in bus and bridge will be treated as struct pci_config_window,
which is created by generic ECAM using the data from acpi.
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 [off-list ref]
Signed-off-by: Boqun Feng (Microsoft) <redacted>
---
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(-)
@@ -74,15 +74,24 @@ struct acpi_pci_generic_root_info {intacpi_pci_bus_find_domain_nr(structpci_bus*bus){structpci_config_window*cfg=bus->sysdata;-structacpi_device*adev=to_acpi_device(cfg->parent);-structacpi_pci_root*root=acpi_driver_data(adev);+structpci_sysdata*sd=bus->sysdata;+structacpi_device*adev;+structacpi_pci_root*root;++/* struct pci_sysdata has domain nr in it */+if(bus->ops->use_arch_sysdata)+returnsd->domain;++/* or pci_config_window is used as sysdata */+adev=to_acpi_device(cfg->parent);+root=acpi_driver_data(adev);returnroot->segment;}intpcibios_root_bridge_prepare(structpci_host_bridge*bridge){-if(!acpi_disabled){+if(!acpi_disabled&&bridge->ops->use_arch_sysdata){structpci_config_window*cfg=bridge->bus->sysdata;structacpi_device*adev=to_acpi_device(cfg->parent);structdevice*bus_dev=&bridge->bus->dev;
On Sat, Mar 20, 2021 at 12:19:54AM +0800, Boqun Feng wrote:
Hi Bjorn,
I'm currently working on virtual PCI support for Hyper-V ARM64 guests.
Similar to virtual PCI on x86 Hyper-V guests, the PCI root bus is not
probed via ACPI (or of), it's probed from Hyper-V VMbus, therefore it
Prime example of why "OF" should be capitalized to prevent the
confusion of reading it as an English word, where it looks like a typo
and makes no sense. Capitalizing it gives me and other uninitiates a
hint that it's an initialism. Also applies to your commit logs and
code comments.
[+cc Arnd (author of 37d6a0a6f470 ("PCI: Add
pci_register_host_bridge() interface"), which I think would make my
idea below possible), Marc (IRQ domains maintainer)]
On Sat, Mar 20, 2021 at 12:19:55AM +0800, Boqun Feng wrote:
Currently, if an architecture selects CONFIG_PCI_DOMAINS_GENERIC, the
->sysdata in bus and bridge will be treated as struct pci_config_window,
which is created by generic ECAM using the data from acpi.
It might be a mistake that we put the struct pci_config_window
pointer, which is really arch-independent, in the ->sysdata element,
which normally contains a pointer to arch- or host bridge-dependent
data.
quoted hunk
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 [off-list ref]
Signed-off-by: Boqun Feng (Microsoft) <redacted>
---
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(-)
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.
quoted hunk
#ifdef CONFIG_PCI
static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
{
@@ -31,8 +41,27 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel) static inline int pci_proc_domain(struct pci_bus *bus) {+ if (bus->ops->use_arch_sysdata)+ return pci_domain_nr(bus); return 1;
I don't understand this. pci_proc_domain() returns a boolean and
determines whether the /proc/bus/pci/ directory contains, e.g.,
/proc/bus/pci/00 or
/proc/bus/pci/0000:00
On arm64, pci_proc_domain() currently always returns 1, so the
directory contains "0000:00". After these patches, pci_proc_domain()
returns 0 if CONFIG_PCI_DOMAINS_GENERIC=y and "bus" is in domain 0,
so buses in domain 0 will be "00" instead of "0000:00".
This doesn't make sense to me, but at the very least, this
user-visible change needs to be explained.
}
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+static inline void *_pci_root_bus_fwnode(struct pci_bus *bus)
+{
+ struct pci_sysdata *sd = bus->sysdata;
+
+ if (bus->ops->use_arch_sysdata)
+ return sd->fwnode;
+
+ /*
+ * bus->sysdata is not struct pci_sysdata, fwnode should be able to
+ * be queried from of/acpi.
+ */
+ return NULL;
+}
+#define pci_root_bus_fwnode _pci_root_bus_fwnode
Ugh. pci_root_bus_fwnode() is another callback to find the
irq_domain. Only one call, from pci_host_bridge_msi_domain(), which
itself is only called from pci_set_bus_msi_domain(). This feels like
another case where we could simplify things by having the host bridge
driver figure out the irq_domain explicitly when it creates the
pci_host_bridge. It seems like that's where we have the most
information about how to find the irq_domain.
@@ -74,15 +74,24 @@ struct acpi_pci_generic_root_info {intacpi_pci_bus_find_domain_nr(structpci_bus*bus){structpci_config_window*cfg=bus->sysdata;-structacpi_device*adev=to_acpi_device(cfg->parent);-structacpi_pci_root*root=acpi_driver_data(adev);+structpci_sysdata*sd=bus->sysdata;+structacpi_device*adev;+structacpi_pci_root*root;++/* struct pci_sysdata has domain nr in it */+if(bus->ops->use_arch_sysdata)+returnsd->domain;++/* or pci_config_window is used as sysdata */+adev=to_acpi_device(cfg->parent);+root=acpi_driver_data(adev);
My comments above are a lot of hand-waving without a very clear way
forward. Would it simplify things to just add a "struct
pci_config_window *ecam_info" to pci_host_bridge, so we wouldn't have
to overload sysdata?
On Fri, Mar 19, 2021 at 5:22 PM Boqun Feng [off-list ref] wrote:
Currently, if an architecture selects CONFIG_PCI_DOMAINS_GENERIC, the
->sysdata in bus and bridge will be treated as struct pci_config_window,
which is created by generic ECAM using the data from acpi.
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 [off-list ref]
Signed-off-by: Boqun Feng (Microsoft) <redacted>
I think this takes it in the opposite direction of where it should be going.
I think none of these members belong into sysdata or architecture specific
code. The fact that a pci_host_bridge belongs to a particular NUMA node
or i associated with a firmware description is neither specific to a
host bridge implementation nor a CPU instruction set!
Moreover, you cannot assume that all PCI host bridges on any given
architecture can share the pci_sysdata pointer, it is purely specific to
the bridge driver.
A good start would be to move the members (one at a time) into struct
pci_host_bridge and out of the sysdata of individual host bridge drivers.
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-20 12:55:23
Thanks Bjorn for looping me in.
On Fri, 19 Mar 2021 21:12:46 +0000,
Bjorn Helgaas [off-list ref] wrote:
[+cc Arnd (author of 37d6a0a6f470 ("PCI: Add
pci_register_host_bridge() interface"), which I think would make my
idea below possible), Marc (IRQ domains maintainer)]
On Sat, Mar 20, 2021 at 12:19:55AM +0800, Boqun Feng wrote:
quoted
Currently, if an architecture selects CONFIG_PCI_DOMAINS_GENERIC, the
->sysdata in bus and bridge will be treated as struct pci_config_window,
which is created by generic ECAM using the data from acpi.
It might be a mistake that we put the struct pci_config_window
pointer, which is really arch-independent, in the ->sysdata element,
which normally contains a pointer to arch- or host bridge-dependent
data.
quoted
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 [off-list ref]
Signed-off-by: Boqun Feng (Microsoft) <redacted>
---
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(-)
Why isn't this more strongly typed? pci_host_bridge_msi_domain()
definitely expects this to be the real thing. And the comment is
wrong.
[...]
quoted
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+static inline void *_pci_root_bus_fwnode(struct pci_bus *bus)
+{
+ struct pci_sysdata *sd = bus->sysdata;
+
+ if (bus->ops->use_arch_sysdata)
+ return sd->fwnode;
+
+ /*
+ * bus->sysdata is not struct pci_sysdata, fwnode should be able to
+ * be queried from of/acpi.
+ */
+ return NULL;
+}
+#define pci_root_bus_fwnode _pci_root_bus_fwnode
Ugh. pci_root_bus_fwnode() is another callback to find the
irq_domain. Only one call, from pci_host_bridge_msi_domain(), which
itself is only called from pci_set_bus_msi_domain(). This feels like
another case where we could simplify things by having the host bridge
driver figure out the irq_domain explicitly when it creates the
pci_host_bridge. It seems like that's where we have the most
information about how to find the irq_domain.
Urgh. This is a perfect copy paste of the x86 horror, warts and all.
I can't say I'm thrilled (another way to say "Gawd, Noes! Never!").
One thing I am sure of is that I do not want to add more custom
indirection to build the MSI topology. We barely got rid of the
msi_controller structure, and this is the same thing by another
name. Probably worse, actually.
In this case, I don't see the point in going via a fwnode indirection
given that there is no firmware tables the first place.
As for finding the irq domain from the host bridge, that's not doable
in most cases on arm64, as it is pretty likely that the host bridge
knows nothing about MSIs when they are implemented in the GIC (see my
recent msi_controller removal series that has a few patches about
that).
Having an optional callback to host bridges to obtain the MSI domain
may be possible in some cases though (there might be a chicken/egg
problem for some drivers though...).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
On Fri, Mar 19, 2021 at 10:14 PM Bjorn Helgaas [off-list ref] wrote:
quoted
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 [off-list ref]
Signed-off-by: Boqun Feng (Microsoft) <redacted>
---
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(-)
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
On Sat, Mar 20, 2021 at 1:54 PM Marc Zyngier [off-list ref] wrote:
On Fri, 19 Mar 2021 21:12:46 +0000,
quoted
Ugh. pci_root_bus_fwnode() is another callback to find the
irq_domain. Only one call, from pci_host_bridge_msi_domain(), which
itself is only called from pci_set_bus_msi_domain(). This feels like
another case where we could simplify things by having the host bridge
driver figure out the irq_domain explicitly when it creates the
pci_host_bridge. It seems like that's where we have the most
information about how to find the irq_domain.
Urgh. This is a perfect copy paste of the x86 horror, warts and all.
I can't say I'm thrilled (another way to say "Gawd, Noes! Never!").
One thing I am sure of is that I do not want to add more custom
indirection to build the MSI topology. We barely got rid of the
msi_controller structure, and this is the same thing by another
name. Probably worse, actually.
In this case, I don't see the point in going via a fwnode indirection
given that there is no firmware tables the first place.
As for finding the irq domain from the host bridge, that's not doable
in most cases on arm64, as it is pretty likely that the host bridge
knows nothing about MSIs when they are implemented in the GIC (see my
recent msi_controller removal series that has a few patches about
that).
Having an optional callback to host bridges to obtain the MSI domain
may be possible in some cases though (there might be a chicken/egg
problem for some drivers though...).
I would expect that the host bridge driver can find the MSI domain
at probe time and just add a pointer into the pci_host_bridge
structure.
Arnd
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-20 13:30:18
On Sat, 20 Mar 2021 13:03:13 +0000,
Arnd Bergmann [off-list ref] wrote:
On Sat, Mar 20, 2021 at 1:54 PM Marc Zyngier [off-list ref] wrote:
quoted
On Fri, 19 Mar 2021 21:12:46 +0000,
quoted
quoted
Ugh. pci_root_bus_fwnode() is another callback to find the
irq_domain. Only one call, from pci_host_bridge_msi_domain(), which
itself is only called from pci_set_bus_msi_domain(). This feels like
another case where we could simplify things by having the host bridge
driver figure out the irq_domain explicitly when it creates the
pci_host_bridge. It seems like that's where we have the most
information about how to find the irq_domain.
Urgh. This is a perfect copy paste of the x86 horror, warts and all.
I can't say I'm thrilled (another way to say "Gawd, Noes! Never!").
One thing I am sure of is that I do not want to add more custom
indirection to build the MSI topology. We barely got rid of the
msi_controller structure, and this is the same thing by another
name. Probably worse, actually.
In this case, I don't see the point in going via a fwnode indirection
given that there is no firmware tables the first place.
As for finding the irq domain from the host bridge, that's not doable
in most cases on arm64, as it is pretty likely that the host bridge
knows nothing about MSIs when they are implemented in the GIC (see my
recent msi_controller removal series that has a few patches about
that).
Having an optional callback to host bridges to obtain the MSI domain
may be possible in some cases though (there might be a chicken/egg
problem for some drivers though...).
I would expect that the host bridge driver can find the MSI domain
at probe time and just add a pointer into the pci_host_bridge
structure.
In most cases, it doesn't implement it itself, and I'd be reluctant to
duplicate information that can already be retrieved from somewhere
else in a generic way (i.e. no PCI specific).
M.
--
Without deviation from the norm, progress is not possible.
On Sat, Mar 20, 2021 at 2:23 PM Marc Zyngier [off-list ref] wrote:
On Sat, 20 Mar 2021 13:03:13 +0000,
Arnd Bergmann [off-list ref] wrote:
quoted
On Sat, Mar 20, 2021 at 1:54 PM Marc Zyngier [off-list ref] wrote:
quoted
On Fri, 19 Mar 2021 21:12:46 +0000,
Having an optional callback to host bridges to obtain the MSI domain
may be possible in some cases though (there might be a chicken/egg
problem for some drivers though...).
I would expect that the host bridge driver can find the MSI domain
at probe time and just add a pointer into the pci_host_bridge
structure.
In most cases, it doesn't implement it itself, and I'd be reluctant to
duplicate information that can already be retrieved from somewhere
else in a generic way (i.e. no PCI specific).
At the moment, the information is retried through a maze of different
functions, and already duplicated in both the pci_host_bridge and the
pci_bus structures. If we can change everything to use
CONFIG_GENERIC_MSI_IRQ_DOMAIN, then most of that code
can probably just go away, leaving only the part in the phb.
Arnd
On Sat, Mar 20, 2021 at 1:54 PM Arnd Bergmann [off-list ref] wrote:
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.
I've uploaded my series to
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
pci-probe-rework-20210320
The purpose of this series is mostly to simplify what variations of
host probe methods exist, towards using pci_host_probe() as the
only method. It does provide some simplifications based on that
that, including a way to universally have access to the pci_host_bridge
pointer during the probe function.
Arnd
From: Marc Zyngier <maz@kernel.org> Date: 2021-03-20 17:15:21
On Sat, 20 Mar 2021 14:24:06 +0000,
Arnd Bergmann [off-list ref] wrote:
On Sat, Mar 20, 2021 at 2:23 PM Marc Zyngier [off-list ref] wrote:
quoted
On Sat, 20 Mar 2021 13:03:13 +0000,
Arnd Bergmann [off-list ref] wrote:
quoted
On Sat, Mar 20, 2021 at 1:54 PM Marc Zyngier [off-list ref] wrote:
quoted
On Fri, 19 Mar 2021 21:12:46 +0000,
Having an optional callback to host bridges to obtain the MSI domain
may be possible in some cases though (there might be a chicken/egg
problem for some drivers though...).
I would expect that the host bridge driver can find the MSI domain
at probe time and just add a pointer into the pci_host_bridge
structure.
In most cases, it doesn't implement it itself, and I'd be reluctant to
duplicate information that can already be retrieved from somewhere
else in a generic way (i.e. no PCI specific).
At the moment, the information is retried through a maze of different
functions, and already duplicated in both the pci_host_bridge and the
pci_bus structures. If we can change everything to use
CONFIG_GENERIC_MSI_IRQ_DOMAIN, then most of that code
can probably just go away, leaving only the part in the phb.
Fine by me, as long as you don't assume that there is a single MSI
domain per PHB (both OF and IORT mandate that you can segment the RID
space to hit multiple controllers).
M.
--
Without deviation from the norm, progress is not possible.
Hi Arnd,
On Sat, Mar 20, 2021 at 05:09:10PM +0100, Arnd Bergmann wrote:
On Sat, Mar 20, 2021 at 1:54 PM Arnd Bergmann [off-list ref] wrote:
quoted
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.
I've uploaded my series to
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
pci-probe-rework-20210320
The purpose of this series is mostly to simplify what variations of
host probe methods exist, towards using pci_host_probe() as the
only method. It does provide some simplifications based on that
that, including a way to universally have access to the pci_host_bridge
pointer during the probe function.
Thanks for the suggestion and code. I spend some time to catch up. Yes,
Bjorn and you are correct, the better way is having a 'domain_nr' in the
'pci_host_bridge' and making sure every driver fill that correctly
before probe. I definitly will use this approach.
However, I may start small: I plan to introduce 'domain_nr' and only
fill the field at probe time for PCI_DOMAINS_GENERIC=y archs, and leave
other archs and driver alone. (honestly, I was shocked by the number of
pci_scan_root_bus_bridge() and pci_host_probe() that I need to adjust if
I really want to unify the 'domain_nr' handling for every arch and
driver ;-)). This will fulfil my requirement for Hyper-V PCI controller
on ARM64. And later on, we can switch each arch to this approach one by
one and keep the rest still working.
Thoughts?
Regards,
Boqun
On Mon, Mar 29, 2021 at 4:32 PM Boqun Feng [off-list ref] wrote:
Hi Arnd,
On Sat, Mar 20, 2021 at 05:09:10PM +0100, Arnd Bergmann wrote:
quoted
On Sat, Mar 20, 2021 at 1:54 PM Arnd Bergmann [off-list ref] wrote:
quoted
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.
I've uploaded my series to
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
pci-probe-rework-20210320
The purpose of this series is mostly to simplify what variations of
host probe methods exist, towards using pci_host_probe() as the
only method. It does provide some simplifications based on that
that, including a way to universally have access to the pci_host_bridge
pointer during the probe function.
Thanks for the suggestion and code. I spend some time to catch up. Yes,
Bjorn and you are correct, the better way is having a 'domain_nr' in the
'pci_host_bridge' and making sure every driver fill that correctly
before probe. I definitly will use this approach.
However, I may start small: I plan to introduce 'domain_nr' and only
fill the field at probe time for PCI_DOMAINS_GENERIC=y archs, and leave
other archs and driver alone. (honestly, I was shocked by the number of
pci_scan_root_bus_bridge() and pci_host_probe() that I need to adjust if
I really want to unify the 'domain_nr' handling for every arch and
driver ;-)). This will fulfil my requirement for Hyper-V PCI controller
on ARM64. And later on, we can switch each arch to this approach one by
one and keep the rest still working.
Thoughts?