Re: [PATCH] ssb: Fix initcall ordering
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. -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix initcall ordering
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? -- Greetings Michael. ___ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
Re: [PATCH] ssb: Fix initcall ordering
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
