Re: Potential issue with some implementations of pci_resource_start()

[Jes Sorensen <jes@wildopensource.com>]

>>>>> "James" == James Smart <James.Smart@Emulex.Com> writes:

James> According to Documentation/pci.txt: pci_resource_start() is to
James> return the bus start address of the bar. It should essentially
James> be a portable way to obtain the bar value without reading PCI
James> config space directly.

According to Documentation/pci.txt:
pci_resource_start()            Returns bus start address for a given
PCI region

James> We have encountered at least 2 platforms (HP Integrity (IA-64)
James> Olympia rx8620 partition, and a dual-processor IBM eServer
James> pSeries p615) - where the contents of pci_resource_start() vary
James> from the contents of the BARs in config space. For example: on
James> IA64 Olympia: pci_resource_start(pcidev,0) =
James> 0x00000f0030040000; pci bar0 word 0xf0040004, bar1 word 0x0 On
James> PPC eServer: pci_resource_start(pcidev,0) = 0x000003fd80000000;
James> pci bar0 word 0xc0000004, bar1 word 0x0

James> We have demonstrated this on both the 2.4.21 and 2.6.5 kernels.

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.

Are you unable to access the space after mapping it?

Cheers,
Jes