> No, because as I said, res->start is relative to the start of IO-space. > The in/out functions add isa_io_base to the address. >
Hi Scott, please allow me to insist a little bit more on this. 1. As far as the device tree is concerned, it is defined that the first 3 numbers in every line of the ranges property (for our case, with #address- cells=3) is the PCI address of the device (in this case, host bridge), the next one is the local bus base address and the last two the local region size. In the case of memory space, res->start for the host bridge takes as a value ranges[3], which is actually the local bus base address. Why does the code for IO space uses ranges[2]. Shouldn't these two use the same field of the corresponding ranges property line? 2. As far as isa_io_base is concerned: When primary (what does this actually mean? primary PCI bus ?) is 1, then indeed isa_io_base=ranges[na+2]=ranges[3] (in this case) as it should (while res- >start=ranges[2] for some reason I don't understand, as I said earlier). And this is indeed added in the i/o address of the device during in/out operations. However, the driver I use, drivers/net/tulip/dmfe.c, actually checks whether res->start for the PCI device is zero, and if it is so, it fails. So, assuming that the pci_process_OF_bridges code is correct as is, then there is some problem with the driver? Because the same driver worked in arch/ppc, which makes me think that there, res->start was NOT 0, but was already offset to the actual I/O space of the local bus. I would really appreciate your comments (and forgive me for insisting on this :) ) Alex > > Because, currently, based on what I've > > 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. > > It is not, at least not in this case. It does appear to be ignoring the > possibility that it needs to do further translation of the address > through parent buses, though. > > -Scott > -- _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev