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

Reply via email to