Alexandros Kostopoulos writes: > In mpc8272ads.dts, the ranges property for pci is: > > ranges = <42000000 0 80000000 80000000 0 20000000 > 02000000 0 a0000000 a0000000 0 20000000 > 01000000 0 00000000 f6000000 0 02000000>; > > The third obviously corresponds to IO space. So, shouldn't the res->start for > the host bridge be set to f6000000 ? Because, currently, based on what I've
No. The "addresses" in the resource structs for PCI I/O space are basically PCI I/O port numbers (with a bit of a swizzle for host bridges other than the primary bridge), whereas the "addresses" in resource structs for PCI memory space are actually host physical addresses. This difference is reflected in the difference between inb() and readb(); inb() adds pci_io_base on to the port number, which comes directly from the resource struct. In contrast, to use readb, you get the PCI memory space address from the resource struct and pass that through ioremap to get the cookie (actually the kernel virtual address) to pass to readb, which doesn't add anything to it before dereferencing it. For host bridges other than the primary bridge, we add an offset to the start/end values in the resource structs in pcibios_fixup_resources so inb/outb work as expected. > described in my previous mail, it gets set to 0. It seems to me like a matter > of incorrect parsing of the device tree from pci_process_bridge_OF_ranges() > for IO space. Or am I missing something else here, and it should actually be > 0? It should actually be zero. What you have is a disagreement between the firmware writer (who thinks 0 is a perfectly valid I/O port address assignment) and the driver writer (who thinks 0 isn't valid). Paul. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
