On Wed, Nov 12, 2014 at 07:23:49AM +0000, Benjamin Herrenschmidt wrote: > On Mon, 2014-11-10 at 16:04 -0700, Bjorn Helgaas wrote: > > But I'm not sure I have this right. If the procfs offset is either > > the > > CPU physical address or the BAR value, then pci_resource_to_user() > > should be (depending on the arch) either a no-op or use > > pci_resource_to_bus(). > > > > But that's not how it's implemented. Maybe it *could* be? If > > pci_resource_to_user() gives you something that's not a CPU physical > > address and not a bus address, what *does* it give you, and why would > > we > > need this third kind of thing? > > > > FWIW, I think the discussion leading up to pci_resource_to_user() is > > here: > > http://lkml.iu.edu/hypermail/linux/kernel/0504.3/0467.html > > Oh, man... I remember that was all a giant trainwreck and some stuff > just couldn't be made completely right due to broken assumptions by > the proc code and users of it... but I don't remember all the details. > > I think /proc users don't necessarily pass a BAR value but something > they try to somewhat translates themselves via the "resources" file, > which ends up working ... or not, depending on various factors such > as 32 vs 64 bit etc... > > I wonder who still uses this interface.... +1, even though I do not think that leaving it as it is is a good idea, hence I posted this series. I tried to fix it while fixing the way ARM pcibios code handles pci_mmap_page_range() (for both procfs and sysfs mappings). I will do what Bjorn suggested, more comments from arches maintainers are welcome. Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
