On 02/06/2013 10:50 AM, Jason Gunthorpe wrote: > On Wed, Feb 06, 2013 at 06:18:52PM +0100, Thomas Petazzoni wrote: >> Dear Jason Gunthorpe, >> >> On Wed, 6 Feb 2013 10:09:03 -0700, Jason Gunthorpe wrote: >> >>> Link 0 translates like: >>> >>> - Linux driver does inl(0x4) >>> - ARM layer converts that into a read from PCI_IO_VIRT_BASE + 0x4 >>> - The CPU TLB converts that into a read from CPU physical >>> 0xc0000000 + 0x4 >>> - The MBUS window remap register converts that into a read from IO >>> space 0x4 >>> - The address 0x4 is placed in the PCI-E IO transaction of link 0 >>> >>> Link 1 translates like: >>> >>> - Linux driver does inl(0x1004) >>> - ARM layer converts that into a read from PCI_IO_VIRT_BASE + 0x1004 >>> - The CPU TLB converts that into a read from CPU physical >>> 0xc0000000 + 0x11004 (ie the mbus window for the link 1) >>> - The MBUS window remap register converts that into a read from IO >>> space 0x1004 >>> - The address 0x1004 is placed in the PCI-E IO transaction of link 1 >> >> This last step is exactly what I thought would not work. If the PCIe >> device has say 64 bytes of I/O space, then this 0x1004 PCI-E >> transaction will be out of bounds, no? > > No.. PCI end devices are required to decode all 32 bits of address, > less the bits requires for their allocation. So a device with 64 bytes > of IO will match bits 31:6 and then use bits 5:0 for the internal > register. Didn't Arnd say (earlier this thread) that PCI devices using IO BARs were probably fairly legacy and hence might be buggy and might not obey that rule? Now, I'd guess it's safe within the first 64k of IO space though, so perhaps he was only talking about IO BAR bases >= 64k being dubious? That would imply a device might only use bits 15:6 for matching the BAR base and 5:0 for the internal register for a 64-byte BAR. -- 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
