Alexandros Kostopoulos wrote: > I've noticed the following: In function pci_process_bridge_OF_ranges, > when parsing the ranges for MEM and I/O space, the res->start for mem > is correctly set to ranges[na+2], which is the cpu address in the > ranges property. However, in I/O related code, res->start is set to > ranges[2], which is in the PCI address field of the ranges property > (and in my case is 0, as is also for the mpc8272ads case as well). > Thus, the res->start of the I/O of the bridge is 0, which leads to the > first device with I/O space (a davicom ethernet device) been also > assigned a I/O region starting at 0. Finally, the dmfe (davicom > ethernet driver over PCI) fails with "dmfe: I/O base is zero". So, is > the implementation of pci_process_bridge_OF_ranges correct ? shouldn't > res->start = ranges[na+2] for I/O as well?
Ideally, yes -- but currently IO-space resources are relative to the start of the primary bus's IO-space. As a workaround, try not setting the primary flag when calling pci_process_bridge_OF_ranges. Note that this means that any legacy I/O ports that may exist on cards you plug in (such as VGA cards) will not be found. The proper solution is probably to refuse pre-existing BARs that are lower than PCIBIOS_MIN_IO, and/or provide a flag to tell the PCI layer to completely ignore pre-existing BARs. -Scott _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
