From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Krzysztof Halasa <khalasa@piap.pl>, Arnd Bergmann <arnd@arndb.de>,
Phil Edworthy <phil.edworthy@renesas.com>,
Jingoo Han <jg1.han@samsung.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Russell King <linux@arm.linux.org.uk>,
Mohit Kumar <mohit.kumar@st.com>
Subject: Re: [RFC PATCH 0/2] arm: pcibios: remove pci_sys_data domain
Date: Thu, 30 Oct 2014 12:42:50 -0600 [thread overview]
Message-ID: <20141030184250.GI26820@obsidianresearch.com> (raw)
In-Reply-To: <20141030180941.GA17911@red-moon>
On Thu, Oct 30, 2014 at 06:09:41PM +0000, Lorenzo Pieralisi wrote:
> It is done through core code in pci_create_root_bus(), that in turn
> calls pci_bus_assign_domain_nr() which is implemented now in pcibios
> for arm, it is all in patch 2. What Liviu is saying is correct, it
> all
Does request_resources have to be called before pci_create_root_bus
for everything to work right? I didn't trace too deeply, but
pci_create_root_bus is doing all sorts of things with the resource
list..
We already know that missing the request_resource causes some subtle
misbehavior in the PCI core...
Also:
+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+{
+ int domain = of_get_pci_domain_nr(parent->of_node);
+
+ if (domain >= 0) {
+ dt_domain_found = true;
+ } else if (dt_domain_found == true) {
+ dev_err(parent, "Node %s is missing \"linux,pci-domain\" property in DT\n",
+ parent->of_node->full_name);
+ return;
There isn't any way to return an error from pci_bus_assign_domain_nr,
so I'd think it must always assign something to bus->domain_nr?
Or does higher level code bail out of there are duplicate domains?
Should this error case call pci_get_new_domain_nr() anyhow?
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 12:42:50 -0600 [thread overview]
Message-ID: <20141030184250.GI26820@obsidianresearch.com> (raw)
In-Reply-To: <20141030180941.GA17911@red-moon>
On Thu, Oct 30, 2014 at 06:09:41PM +0000, Lorenzo Pieralisi wrote:
> It is done through core code in pci_create_root_bus(), that in turn
> calls pci_bus_assign_domain_nr() which is implemented now in pcibios
> for arm, it is all in patch 2. What Liviu is saying is correct, it
> all
Does request_resources have to be called before pci_create_root_bus
for everything to work right? I didn't trace too deeply, but
pci_create_root_bus is doing all sorts of things with the resource
list..
We already know that missing the request_resource causes some subtle
misbehavior in the PCI core...
Also:
+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+{
+ int domain = of_get_pci_domain_nr(parent->of_node);
+
+ if (domain >= 0) {
+ dt_domain_found = true;
+ } else if (dt_domain_found == true) {
+ dev_err(parent, "Node %s is missing \"linux,pci-domain\" property in DT\n",
+ parent->of_node->full_name);
+ return;
There isn't any way to return an error from pci_bus_assign_domain_nr,
so I'd think it must always assign something to bus->domain_nr?
Or does higher level code bail out of there are duplicate domains?
Should this error case call pci_get_new_domain_nr() anyhow?
Jason
next prev parent reply other threads:[~2014-10-30 18:43 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 [this message]
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
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=20141030184250.GI26820@obsidianresearch.com \
--to=jgunthorpe@obsidianresearch.com \
--cc=Liviu.Dudau@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=lorenzo.pieralisi@arm.com \
--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.