![]() | |||||||||||||
Messages in this thread |
>>>>> "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/ | ||||||||||||
| Last update: 2005-03-22 14:08 [from the cache] ©2003-2008 | |||||||||||||