Message ID | 20180817102645.3839621-1-arnd@arndb.de (mailing list archive) |
---|---|
Headers | show |
Series | PCI: turn some __weak functions into callbacks | expand |
On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote: > Hi Bjorn and others, > > Triggered by Christoph's patches, I had another go at converting > all of the remaining pci host bridge implementations to be based > on pci_alloc_host_bridge and a separate registration function. I really like the idea behind this series. > I'm adding a bit of duplication into the less maintained code > here, but it makes everything more consistent, and gives an > easy place to hook up callback functions etc. I wonder if there is a way to avoid some of that by adding a few more helpers, but even without the helpers that approach looks ok to me. Do you have a git tree somewhere to play around with the changes?
On Tue, Aug 21, 2018 at 8:14 AM Christoph Hellwig <hch@infradead.org> wrote: > > On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote: > > Hi Bjorn and others, > > > > Triggered by Christoph's patches, I had another go at converting > > all of the remaining pci host bridge implementations to be based > > on pci_alloc_host_bridge and a separate registration function. > > I really like the idea behind this series. > > > I'm adding a bit of duplication into the less maintained code > > here, but it makes everything more consistent, and gives an > > easy place to hook up callback functions etc. > > I wonder if there is a way to avoid some of that by adding a few > more helpers, but even without the helpers that approach looks > ok to me. Ok, thanks for taking a first look. One core part that gets duplicated a lot (also in existing drivers) is the chunk that could be handled by this: int pci_host_bridge_init(struct pci_host_bridge *bridge, struct device *parent, int bus, struct pci_ops *ops, void *sysdata, struct list_head *resource_list) { if (resources) list_splice_init(resources, &bridge->windows); bridge->dev.parent = parent; bridge->sysdata = sysdata; bridge->busnr = bus; bridge->ops = ops; } That would probably help, but we should think carefully about the set of fields that we want pass here, specifically because the idea of splitting the probing into two parts was to avoid having to come up with a new interface every time that list changes due to some rework. For instance, the numa node is something that might get passed here, and if we decide to split out the operations into a separate pci_host_bridge_ops structure, the pointer to that would also be something we'd want to pass this way. > Do you have a git tree somewhere to play around with the changes? I now uploaded it (with fixes incorporated) to https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git pci-probe-rework arnd
On Mon, 2018-08-20 at 23:14 -0700, Christoph Hellwig wrote: > On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote: > > Hi Bjorn and others, > > > > Triggered by Christoph's patches, I had another go at converting > > all of the remaining pci host bridge implementations to be based > > on pci_alloc_host_bridge and a separate registration function. > > I really like the idea behind this series. Hm... are you turning direct calls into retpolined indirect calls?
On Tue, Aug 21, 2018 at 12:30:50PM +0100, David Woodhouse wrote: > On Mon, 2018-08-20 at 23:14 -0700, Christoph Hellwig wrote: > > On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote: > > > Hi Bjorn and others, > > > > > > Triggered by Christoph's patches, I had another go at converting > > > all of the remaining pci host bridge implementations to be based > > > on pci_alloc_host_bridge and a separate registration function. > > > > I really like the idea behind this series. > > Hm... are you turning direct calls into retpolined indirect calls? He does. But not anywhere near the fast path.
On Fri, Aug 17, 2018 at 12:26:30PM +0200, Arnd Bergmann wrote: > Hi Bjorn and others, > > Triggered by Christoph's patches, I had another go at converting > all of the remaining pci host bridge implementations to be based > on pci_alloc_host_bridge and a separate registration function. > > This is made possible through work from Lorenzo and others to > convert many of the existing drivers, as well as the removal > of some of the older architectures that nobody used. > > I'm adding a bit of duplication into the less maintained code > here, but it makes everything more consistent, and gives an > easy place to hook up callback functions etc. > > The three parts of this series are: > > a) push up the registration into the callers (this is where > code gets added) > b) clean up some of the more common host bridge > implementations again to integrate that code better. > This could be done for the rest as well, or we could just > leave them alone. > c) start moving the __weak functions into callbacks in > pci_host_bridge. This is intentionally incomplete, since > it is a lot of work to do it for all those functions, > and I want to get consensus on the approach first, as well > as maybe get other developers to help out with the rest. > > Please have a look. > > Arnd > > [1] https://lore.kernel.org/lkml/4288331.jNpl6KXlNO@wuerfel/ > [2] https://patchwork.kernel.org/patch/10555657/ > > Arnd Bergmann (15): > PCI: clean up legacy host bridge scan functions > PCI: move pci_scan_bus into callers > PCI: move pci_scan_root_bus into callers > PCI: export pci_register_host_bridge > PCI: move pci_create_root_bus into callers > powerpc/pci: fold pci_create_root_bus into pcibios_scan_phb > PCI/ACPI: clean up acpi_pci_root_create() > x86: PCI: clean up pcibios_scan_root() > PCI: xenfront: clean up pcifront_scan_root() > sparc/PCI: simplify pci_scan_one_pbm > PCI: hyperv: convert to pci_scan_root_bus_bridge > PCI: make pcibios_bus_add_device() a callback function > PCI: turn pcibios_alloc_irq into a callback > PCI: make pcibios_root_bridge_prepare a callback > PCI: make pcibios_add_bus/remove_bus callbacks > > arch/arm64/kernel/pci.c | 40 ++----- > arch/ia64/pci/pci.c | 25 +---- > arch/ia64/sn/kernel/io_init.c | 27 +++++ > arch/microblaze/pci/pci-common.c | 27 +++++ > arch/powerpc/include/asm/pci-bridge.h | 3 + > arch/powerpc/kernel/pci-common.c | 60 +++++------ > arch/s390/pci/pci.c | 30 +++++- > arch/sh/drivers/pci/pci.c | 1 + > arch/sh/drivers/pci/pcie-sh7786.c | 3 +- > arch/sh/include/asm/pci.h | 2 + > arch/sparc/kernel/pci.c | 40 ++++--- > arch/sparc/kernel/pcic.c | 35 ++++++ > arch/x86/pci/acpi.c | 15 +-- > arch/x86/pci/common.c | 42 ++++---- > arch/xtensa/kernel/pci.c | 27 +++++ > drivers/acpi/pci_root.c | 43 +++++--- > drivers/parisc/dino.c | 28 +++++ > drivers/parisc/lba_pci.c | 28 +++++ > drivers/pci/bus.c | 8 +- > drivers/pci/controller/pci-hyperv.c | 47 ++++---- > drivers/pci/controller/vmd.c | 30 +++++- > drivers/pci/hotplug/ibmphp_core.c | 35 ++++++ > drivers/pci/pci-driver.c | 13 ++- > drivers/pci/probe.c | 150 +++++++++----------------- > drivers/pci/xen-pcifront.c | 40 +++---- > include/linux/acpi.h | 2 + > include/linux/pci.h | 17 ++- > 27 files changed, 514 insertions(+), 304 deletions(-) Sorry for the late response to this. I think I'm generally on-board with this. I admit I'm a little hesitant about adding 200 lines of code when this is really more "cleanup" than new functionality, but I think a lot of that is because this series contains costs (e.g., duplicating code) for everybody but only has the corresponding benefits for a few (ACPI, x86, xenfront). Those cases are much closer to parity in terms of lines added/removed. I saw some minor comments that suggested you had some updates, so I'll watch for an updated posting. Bjorn