pci in arch/powerpc vs arch/ppc

[Paul Mackerras]

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.