All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Liviu Dudau <Liviu.Dudau@arm.com>,
	Phil Edworthy <phil.edworthy@renesas.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Russell King <linux@arm.linux.org.uk>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Jingoo Han <jg1.han@samsung.com>,
	Krzysztof Halasa <khalasa@piap.pl>,
	Mohit Kumar <mohit.kumar@st.com>,
	Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [RFC PATCH 0/2] arm: pcibios: remove pci_sys_data domain
Date: Thu, 30 Oct 2014 13:35:38 -0600	[thread overview]
Message-ID: <20141030193538.GK26820@obsidianresearch.com> (raw)
In-Reply-To: <3532414.9PZuBnKWYz@wuerfel>

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.

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 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??

Jason

WARNING: multiple messages have this Message-ID (diff)
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/2] arm: pcibios: remove pci_sys_data domain
Date: Thu, 30 Oct 2014 13:35:38 -0600	[thread overview]
Message-ID: <20141030193538.GK26820@obsidianresearch.com> (raw)
In-Reply-To: <3532414.9PZuBnKWYz@wuerfel>

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.

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 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??

Jason

  reply	other threads:[~2014-10-30 19:36 UTC|newest]

Thread overview: 64+ 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 ` Lorenzo Pieralisi
2014-10-30 11:44 ` [RFC PATCH 1/2] arm: cns3xxx: pci: remove artificial dependency on " Lorenzo Pieralisi
2014-10-30 11:44   ` Lorenzo Pieralisi
2014-11-01 12:32   ` Michał Mirosław
2014-11-01 12:32     ` Michał Mirosław
2014-11-03 10:09     ` Arnd Bergmann
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:44   ` Lorenzo Pieralisi
2014-10-30 11:55   ` Arnd Bergmann
2014-10-30 11:55     ` Arnd Bergmann
2014-10-30 16:20     ` Lorenzo Pieralisi
2014-10-30 16:20       ` Lorenzo Pieralisi
2014-10-30 12:27   ` Yijing Wang
2014-10-30 12:27     ` Yijing Wang
2014-10-30 16:21     ` Lorenzo Pieralisi
2014-10-30 16:21       ` Lorenzo Pieralisi
2014-10-31 13:43   ` Phil Edworthy
2014-10-31 13:43     ` Phil Edworthy
2014-10-31 16:37     ` Bjorn Helgaas
2014-10-31 16:37       ` Bjorn Helgaas
2014-10-31 17:04       ` Phil Edworthy
2014-10-31 17:04         ` Phil Edworthy
2014-11-03 23:26         ` Simon Horman
2014-11-03 23:26           ` Simon Horman
2014-11-04 11:44           ` Liviu Dudau
2014-11-04 11:44             ` Liviu Dudau
2014-11-03 11:06     ` Lorenzo Pieralisi
2014-11-03 11:06       ` Lorenzo Pieralisi
2014-11-03  1:18   ` Jingoo Han
2014-11-03  1:18     ` Jingoo Han
2014-11-03  2:36     ` Karicheri, Muralidharan
2014-11-03  2:36       ` Karicheri, Muralidharan
2014-11-03 11:23     ` Lorenzo Pieralisi
2014-11-03 11:23       ` Lorenzo Pieralisi
2014-11-03 11:33       ` Lucas Stach
2014-11-03 11:33         ` Lucas Stach
2014-11-03 12:13         ` Jingoo Han
2014-11-03 12:13           ` Jingoo Han
2014-11-03  3:48   ` Yijing Wang
2014-11-03  3:48     ` Yijing Wang
2014-11-03 10:49     ` Lorenzo Pieralisi
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:25   ` Jason Gunthorpe
2014-10-30 16:52   ` Lorenzo Pieralisi
2014-10-30 16:52     ` Lorenzo Pieralisi
2014-10-30 17:03     ` Jason Gunthorpe
2014-10-30 17:03       ` Jason Gunthorpe
2014-10-30 17:39       ` Liviu Dudau
2014-10-30 17:39         ` Liviu Dudau
2014-10-30 17:45         ` Jason Gunthorpe
2014-10-30 17:45           ` Jason Gunthorpe
2014-10-30 18:09           ` Lorenzo Pieralisi
2014-10-30 18:09             ` Lorenzo Pieralisi
2014-10-30 18:42             ` Jason Gunthorpe
2014-10-30 18:42               ` Jason Gunthorpe
2014-10-30 19:21           ` Arnd Bergmann
2014-10-30 19:21             ` Arnd Bergmann
2014-10-30 19:35             ` Jason Gunthorpe [this message]
2014-10-30 19:35               ` Jason Gunthorpe
2014-10-30 20:03               ` Arnd Bergmann
2014-10-30 20:03                 ` Arnd Bergmann

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=20141030193538.GK26820@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=jg1.han@samsung.com \
    --cc=khalasa@piap.pl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mohit.kumar@st.com \
    --cc=phil.edworthy@renesas.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.