RE: Potential issue with some implementations of pci_resource_start()

[James . Smart]

Ok, the question was to flush out what to expect from pci_resource_start(), and if it is functioning as desired, update the documentation to reflect what it actually returns. It is too ambiguous as is (and in many cases, it is the contents of the bar register). The fact it's a cookie is not well known, as it was not the definition I received from private questions to several kernel developers.

Can someone please update Documentation/pci.txt so that it has correct definitions for pci_resource_start() and pci_resource_end()...

FYI: In our case, we have an adapter that can use adapter or host memory for messaging. It detects the use of adapter memory by comparing the bus address given by the driver to it's bar values. So yes - we had to read the config space registers directly to give the adapter the proper values.

-- James S


> From: jes@xxxxxxxxxxxxxxxxxx [mailto:jes@xxxxxxxxxxxxxxxxxx]
>
> James> Are these platform bugs that need to be corrected ? or is it a
> James> change in the pci_resource_start() definition ?
> 
> pci_resource_start will rather give you a cookie that you can pass to
> iomap() (ioremap() in the old API) etc. You shouldn't be relying on
> the physical bar content for anything in a Linux driver.
> 
> Cheers,
> Jes


> From: linux-os [mailto:linux-os@xxxxxxxxxxxxxxxxxx]
> 
> pic_resource_start() is supposed to give you something that
> ioremap() can use. On 64-bit platforms it is unlikely to be
> a physical address, but a "cookie" that ioremap() knows about.
> 
> If you want the physical address you are going to have to read
> the registers directly. It will give you a number that is useless
> as an address, though.
> 
> Cheers,
> Dick Johnson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/