From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Liviu Dudau <Liviu.Dudau@arm.com>,
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 16:52:46 +0000 [thread overview]
Message-ID: <20141030165246.GC2048@red-moon> (raw)
In-Reply-To: <20141030162552.GC26820@obsidianresearch.com>
[Dropped Anton, his email address bounces]
On Thu, Oct 30, 2014 at 04:25:52PM +0000, Jason Gunthorpe wrote:
> On Thu, Oct 30, 2014 at 11:44:46AM +0000, Lorenzo Pieralisi wrote:
>
> > Code in drivers/pci/pci-mvebu.c has been changed to add a domain
> > number to PCI resources by using the nr value coming from the setup
> > pcibios32 callback, which may not be correct and should be considered
> > a temporary solution waiting for review comments.
>
> The intent of the string was to have the domain number so that
> resources in /proc/iomem can be correlated with lspci.
>
> This would be a 'best practice' - all PCI drivers need to request
> resource, and the resource should be relatable back to the PCI
> domain... So it would be best if the domain number was available at
> this point in a driver's flow.
It is not available with the new approach and the generic PCI domains since
the set-up hook is called before creating the pci_bus. That's why
I mentioned that in the cover letter, and that's good it caught your
attention.
On a side note, when the resources are parsed from DT ranges, ie in:
of_pci_get_host_bridge_resources()
the resources won't contain the domain number you are looking for here, for
the records, so we'd better find an agreement sooner rather than later.
> > - snprintf(pcie->mem_name, sizeof(pcie->mem_name), "PCI MEM %04x",
> > - domain);
> > + snprintf(pcie->mem_name, sizeof(pcie->mem_name), "PCI MEM %04x", nr);
>
> I'm not sure what 'nr' is in this context, if it is not the domain
> number then I'd just drop the 0x04x entirely rather than include
> some nonsense number...
nr is the index (0 to nr_controllers) in struct hw_pci of the controller
being set-up. For this driver it is always 0, and BTW, sys->domain was 0 too
and I do not see any code that can change its value to anything other
than 0, at least in the mainline kernel.
So basically I could go as far as sticking 0000 to the string given the
current code. I did not drop the 0x04x entirely since I do not want to break
userspace, I was tempted though, let me know if I am allowed to do that.
Thanks,
Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/2] arm: pcibios: remove pci_sys_data domain
Date: Thu, 30 Oct 2014 16:52:46 +0000 [thread overview]
Message-ID: <20141030165246.GC2048@red-moon> (raw)
In-Reply-To: <20141030162552.GC26820@obsidianresearch.com>
[Dropped Anton, his email address bounces]
On Thu, Oct 30, 2014 at 04:25:52PM +0000, Jason Gunthorpe wrote:
> On Thu, Oct 30, 2014 at 11:44:46AM +0000, Lorenzo Pieralisi wrote:
>
> > Code in drivers/pci/pci-mvebu.c has been changed to add a domain
> > number to PCI resources by using the nr value coming from the setup
> > pcibios32 callback, which may not be correct and should be considered
> > a temporary solution waiting for review comments.
>
> The intent of the string was to have the domain number so that
> resources in /proc/iomem can be correlated with lspci.
>
> This would be a 'best practice' - all PCI drivers need to request
> resource, and the resource should be relatable back to the PCI
> domain... So it would be best if the domain number was available at
> this point in a driver's flow.
It is not available with the new approach and the generic PCI domains since
the set-up hook is called before creating the pci_bus. That's why
I mentioned that in the cover letter, and that's good it caught your
attention.
On a side note, when the resources are parsed from DT ranges, ie in:
of_pci_get_host_bridge_resources()
the resources won't contain the domain number you are looking for here, for
the records, so we'd better find an agreement sooner rather than later.
> > - snprintf(pcie->mem_name, sizeof(pcie->mem_name), "PCI MEM %04x",
> > - domain);
> > + snprintf(pcie->mem_name, sizeof(pcie->mem_name), "PCI MEM %04x", nr);
>
> I'm not sure what 'nr' is in this context, if it is not the domain
> number then I'd just drop the 0x04x entirely rather than include
> some nonsense number...
nr is the index (0 to nr_controllers) in struct hw_pci of the controller
being set-up. For this driver it is always 0, and BTW, sys->domain was 0 too
and I do not see any code that can change its value to anything other
than 0, at least in the mainline kernel.
So basically I could go as far as sticking 0000 to the string given the
current code. I did not drop the 0x04x entirely since I do not want to break
userspace, I was tempted though, let me know if I am allowed to do that.
Thanks,
Lorenzo
next prev parent reply other threads:[~2014-10-30 16:52 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 [this message]
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
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=20141030165246.GC2048@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=jg1.han@samsung.com \
--cc=jgunthorpe@obsidianresearch.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.