[RFC,0/2] arm: pcibios: remove pci_sys_data domain

Commit Message

Arnd Bergmann Oct. 30, 2014, 8:03 p.m. UTC

On Thursday 30 October 2014 13:35:38 Jason Gunthorpe wrote:
> On Thu, Oct 30, 2014 at 08:21:40PM +0100, Arnd Bergmann wrote:
> 
> > > So how does mvebu now allocate a unique domain number per mvebu_pcie?
> > 
> > I believe the answer to that is that the mvebu PCIe driver currently only
> > supports one domain, and it will have the unique number '0', which is the
> > default.
> 
> It is like most of the the other new drivers, each mvebu_pcie_probe
> expects to create a new domain with a unique bus number set for that
> platform_device. AFAIK everything is uniq'd to the struct mcebu_pcie,
> so there is nothing precluding the driver from being instantiated
> twice.
> 
> Indeed, the way mvebu hardware works you could actually create a DT
> that assigned some ports to one domain and some other ports to a
> different domain, using two platform_devices. All that was missing
> from the driver was to increment the domain number.

Right, makes sense.

> I think Lorenzo's patches improve this, at least it appears that
> unique domain numbers are now being assigned, I'm not sure - I'm a
> little confused how we can safely blindly apply the new domain logic
> without the driver opt'ing in....

I think it will just work: the host driver should not care about
the particular domain number, it just needs to be unique, which
the core now ensures.

> I thought older PCI platforms tended to call pci_common_init for each
> physical PCI bus, and we don't want them to suddenly have non-zero
> domain numbers??

Only cns3xxx calls pci_common_init with fixed domain numbers, and
Lorenzo's patch 1/2 changes it. All other drivers fall into one
of three categories:

a) there is only ever one host bridge
b) There are multiple host bridges, but they are all in the same
   domain, and the driver calls pci_common_init() once to initialize
   them all, and pci_common_init calls back into the driver with
   the hw_pci->setup() function passing the instance number.
c) The driver calls pci_common_init_dev() for each new host bridge
   and assigns a new domain every time but never has more than one
   host bridge per domain.

a) and b) are not impacted by this patch, while c) becomes simpler.

BTW, pci-mvebu is currently the only driver using c) with pci_common_init
rather than pci_common_init_dev. We should probably apply this trivial
patch to make it more consistent:



	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index b1315e197ffb..efe4bd370b37 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -825,7 +825,7 @@  static void mvebu_pcie_enable(struct mvebu_pcie *pcie)
 	hw.align_resource = mvebu_pcie_align_resource;
 	hw.add_bus        = mvebu_pcie_add_bus;
 
-	pci_common_init(&hw);
+	pci_common_init_dev(&pcie->pdev.dev, &hw);
 }
 
 /*