public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/2] arm: pcibios: remove pci_sys_data domain
Date: Thu, 30 Oct 2014 21:03:51 +0100	[thread overview]
Message-ID: <2033107.209JbeZvkg@wuerfel> (raw)
In-Reply-To: <20141030193538.GK26820@obsidianresearch.com>

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:

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

      reply	other threads:[~2014-10-30 20:03 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-30 11:44 [RFC PATCH 0/2] arm: pcibios: remove pci_sys_data domain Lorenzo Pieralisi
2014-10-30 11:44 ` [RFC PATCH 1/2] arm: cns3xxx: pci: remove artificial dependency on " Lorenzo Pieralisi
2014-11-01 12:32   ` Michał Mirosław
2014-11-03 10:09     ` Arnd Bergmann
2014-10-30 11:44 ` [RFC PATCH 2/2] arm: pcibios: move to generic PCI domains Lorenzo Pieralisi
2014-10-30 11:55   ` Arnd Bergmann
2014-10-30 16:20     ` Lorenzo Pieralisi
2014-10-30 12:27   ` Yijing Wang
2014-10-30 16:21     ` Lorenzo Pieralisi
2014-10-31 13:43   ` Phil Edworthy
2014-10-31 16:37     ` Bjorn Helgaas
2014-10-31 17:04       ` Phil Edworthy
2014-11-03 23:26         ` Simon Horman
2014-11-04 11:44           ` Liviu Dudau
2014-11-03 11:06     ` Lorenzo Pieralisi
2014-11-03  1:18   ` Jingoo Han
2014-11-03  2:36     ` Karicheri, Muralidharan
2014-11-03 11:23     ` Lorenzo Pieralisi
2014-11-03 11:33       ` Lucas Stach
2014-11-03 12:13         ` Jingoo Han
2014-11-03  3:48   ` Yijing Wang
2014-11-03 10:49     ` Lorenzo Pieralisi
2014-10-30 16:25 ` [RFC PATCH 0/2] arm: pcibios: remove pci_sys_data domain Jason Gunthorpe
2014-10-30 16:52   ` Lorenzo Pieralisi
2014-10-30 17:03     ` Jason Gunthorpe
2014-10-30 17:39       ` Liviu Dudau
2014-10-30 17:45         ` Jason Gunthorpe
2014-10-30 18:09           ` Lorenzo Pieralisi
2014-10-30 18:42             ` Jason Gunthorpe
2014-10-30 19:21           ` Arnd Bergmann
2014-10-30 19:35             ` Jason Gunthorpe
2014-10-30 20:03               ` Arnd Bergmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2033107.209JbeZvkg@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox