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:42 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 [this message]
2014-10-30 19:21 ` Arnd Bergmann
2014-10-30 19:35 ` Jason Gunthorpe
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=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;
as well as URLs for NNTP newsgroup(s).