Messages in this thread | | | Subject | Re: Potential issue with some implementations of pci_resource_start() | From | Jes Sorensen <> | Date | 17 Nov 2004 04:58:38 -0500 |
| |
>>>>> "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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |