On Thursday 07 February 2008 11:41:05 Aurelien Jarno wrote: > On Thu, Feb 07, 2008 at 11:12:13AM +0100, Michael Buesch wrote: > > On Thursday 07 February 2008 10:58:23 Aurelien Jarno wrote: > > > Michael Buesch a écrit : > > > > On Thursday 07 February 2008 01:34:10 Aurelien Jarno wrote: > > > >> Michael Buesch wrote: > > > >> > > > >>> ssb must init after PCI but before the ssb drivers. > > > >>> > > > >>> Signed-off-by: Michael Buesch <mb at bu3sch.de> > > > >>> Cc: Christian Casteyde <casteyde.christan at free.fr> > > > >>> Fixes-bug: #9219 > > > >> Unfortunately this has broken SSB_DRIVER_PCICORE. As SSB is initialized > > > >> after the PCI bus, when the PCI core is initialized, it doesn't see > > > >> any > > > >> device. > > > > > > > > I'm not sure I understand. What's the actual problem? The PCICORE driver > > > > registers a new PCI bus, if it detects one. This is only done on MIPS. > > > > On all other architectures the PCI core is just a passive core used > > > > by the other SSB devices. The PCIcore is initialized after the PCI > > > > subsystem, > > > > but before any SSB devices. So I don't see the problem. > > > > > > The symptom is very simple: when this commit is applied, none of the PCI > > > devices are detected. That includes the USB 2.0 controller, which is > > > used to plug an USB flash drive used as the root partition. So the > > > machine fails to boot. > > > > these devices are on the PCI core? > > > > Yes they are. This is the output of lspci on the machine: > > 00:00.0 Host bridge: Broadcom Corporation BCM5365P Sentry5 Host Bridge > 00:01.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg > NIC (rev 01) > 00:02.0 USB Controller: NEC Corporation USB (rev 43) > 00:02.1 USB Controller: NEC Corporation USB (rev 43) > 00:02.2 USB Controller: NEC Corporation USB 2.0 (rev 04) > > The first one is the SSB PCI core, the others are the PCI devices. >
We can't easily fix this within SSB. The problem is that the MIPS PCI subsystem doesn't seem to allow registering a new bus after its initcal was run. So the bug should probably get fixed there. If you change the ssb initcall back to subsys_initcall(), it will only work by accident anyway, as PCI is subsys_initcall(), too. Reverting this patch would trade one bug for another. -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev