>    From: Anton Blanchard <anton@samba.org>
>    Date: Mon, 3 Jun 2002 14:27:27 +1000
>    
>    On ppc64 I found that pcibios_init was being called before
>    pci_driver_init, maybe its happening on alpha too. I am using the
>    following hack for the moment, I'll leave it to Patrick to fix it properly.
>    
> It's happening on every platform.  It should be done before
> arch_initcalls actually, but after core_initcalls.  I would suggest to
> rename unused_initcall into postcore_iniscall, then use it for this
> and sys_bus_init which has the same problem.
Can't it go the other way? Instead of mass-promotion of the setup 
functions, can't we demote the ones that are causing the problems? 
The initcalls levels were determined by looking at the explicit calls in
init/main.c. Recall that they were:
early_arch
mem
subsys
arch
fs
device
late
with the default being device_initcall. I initially thought that most
things in init/main.c could become initcalls. But, I failed to realize
that init is started before the initcalls are done (duh). (Most things in 
start_kernel() could become initcalls also, but it would require a 
separate initcall section).
Sometime in March, the ACPI people promoted their initialization above 
the initialization of the device model core. This caused a few things to 
fail, and Linus changed the initcall levels to what we have today:
core
unused
arch
subsys
fs
device
late
core is used for what's in drivers/base/*.c. unused is unused. 
arch can be used for arch- and platform-specific initialization. For PCI 
on x86, these determine things like the config space access method. 
subsys is intended primarily for initializing and advertising the 
existence of bus types and device class types (network, input, etc). 
Device probing doesn't necessarily have to take place here, and in some 
cases, it can't: e.g. when the firmware is used to inform the system of 
the PCI buses present.
Theoretically, we should be able to demote bus probing until after 
subsys_initcall. Right? By making them device_initcalls and relying on 
link order, we can guarantee that buses get probed before drivers are 
initialized and start looking for devices they support. (Or, we could make 
a driver_initcall just for drivers; or a bus_initcall for probing buses.)
Thoughts?
	-pat
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/