[PATCH] drivers: pci: remove unused pci_sys_data structures

[Arnd Bergmann]

On Tuesday 10 November 2015 06:19:17 Gabriele Paoloni wrote:
> > Acked-by: Arnd Bergmann <arnd at arndb.de>
> > 
> > On the downside, I just saw how b3a72384fe29 ("ARM/PCI: Replace
> > pci_sys_data->align_resource with global function pointer") manages
> > to get rid of the last user of this, and how this is not the way
> > we had planned for it to be done.
> > 
> > It doesn't matter that much, because there is only a single
> > user of hw->align_resource, but this is now unportable code and
> > cannot easily be separated from hw_pci. It also breaks if we ever
> > get a machine with two different host controllers on ARM that
> > don't use the same pointer here.
> > 
> > I really would have hoped we could put that function pointer
> > into 'struct pci_host_bridge' instead, and eventually killed
> > off the architecture specific pcibios_align_resource function
> > as well.
> 
> say we move that in pci_host_bridge struct,
> 
> Are you suggesting to modify pcibios_init_hw to assign the 
> align_resource function pointer at the end after
> pci_scan_root_bus_msi() has created the host bridge structure;
> then we can retrieve it in pcibios_align_resource using
> pci_find_host_bridge(dev->bus)....?

What I had in mind was more along the lines of removing the
any mention of the align_resource callback from the ARM bios32.c
code and to have the pci-mvebu driver set the pointer manually
at an appropriate point (I did not look what would be that
point). What you suggest above would work too, just doesn't go
as far.

In the long run, I think it would be good to migrate all drivers
in drivers/pci/host/ away from calling pcibios_init_hw() at
all, and just use architecture-independent interfaces and leave
the hw_pci/pci_sys_data based implementation for the traditional
PCI host implementations that we have in arch/arm/mach-* for
platforms that do not use devicetree. This is not something I'm
asking you to do at this point, though any help here is appreciated.

> > Any idea why it was done with a global function pointer for
> > ARM rather than a proper solution?
> 
> Well just because I didn't think about the solution above...
> 
> If you think the above one can work I can send out another
> patch to fix this...

That would be great, yes. As I said, it's currently harmless
but it would be better to get it right.

	Arnd