Jun Sun wrote: > > You may control pci_scan_bridge by pcibios_assign_all_busses, just > > return 0 from the latter and the code in pci_scan_bridge assigns all > > numbers itself. > > Do you mean that we call pci_scan_brige first before scaning other devices? > Yes I do. Look at drivers/pci/pci.c. The code does for each bus (by recursion) scan devices on this bus for each bridge on this bus scan bridge scan bus behind bridge The flow is pci_do_scan_bus -> pci_scan_bridge -> pci_do_scan_bus > > You definitely can't mix device discovering and assignment of resources > > in one pass a on a multi-board cPCI system. > > > > I have not given enough thought on 3), but it is certainly desirable. Well, your previous example works here. You perform scanning of devices and assignments in one pass. You find new device unassigned by firmware/another CPU in cPCI system, then you need find a room in a PCI space. You can't do that, because you don't know yet what rooms firmware/another CPU has allocated, so you don't know what rooms are free. Thus, you have to scan pci in two passes. On first pass, just scan devices and collect allocated rooms in PCI spaces. On second pass, assign unassigned devices. Look how Dave Miller did this for ultras in 2.2 when common pci driver didn't do that. You have to implement more or less the same modulo ultras hw and OBP bugs. BTW, it's exactly what current drivers/pci code does. > Like I said before, this is the old style of doing things. There are many > drawbacks in this approach. Among them, one is to require lots of knowledge > about PCI and how the following hookup functions are called. Not every > porting engineer is willing to dive into that. There are some other problems > too. Sorry, your reason doesn't convince me. I believe, a porting engineer must know hardware and operating system internals very well irrespective of what his wishes are. Could you explain other problems, please ? Regards, Gleb.
