[RFC PATCH 0/2] arm: pcibios: remove pci_sys_data domain

Jason Gunthorpe jgunthorpe at obsidianresearch.com
Thu Oct 30 10:03:05 PDT 2014


On Thu, Oct 30, 2014 at 04:52:46PM +0000, Lorenzo Pieralisi wrote:
> 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.

Well, it is very unfortunate that things are globally not sequenced to
allow proper resource names :(

But it also isn't really a big deal in the grand scheme of
things. Maybe it can be fixed later :|

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

I'd just drop it entirely then, nobody is going to parse /proc/iomem

Jason



More information about the linux-arm-kernel mailing list