Thread (32 messages) 32 messages, 12 authors, 2014-11-04
STALE4251d
Revisions (3)
  1. rfc [diff vs current]
  2. rfc current
  3. v3 [diff vs current]

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

From: arnd@arndb.de (Arnd Bergmann)
Date: 2014-10-30 20:03:51
Also in: linux-pci
Subsystem: pci subsystem, the rest · Maintainers: Bjorn Helgaas, Linus Torvalds

On Thursday 30 October 2014 13:35:38 Jason Gunthorpe wrote:
On Thu, Oct 30, 2014 at 08:21:40PM +0100, Arnd Bergmann wrote:
quoted
quoted
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:
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);
 }
 
 /*

	Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help