Previously, VME bridge support was treated as any other driver (using
module_init() macro), but if VME bridge and vme_user (staging) drivers
were compiled into the kernel, then vme_user would attempt to register
itself before the VME core support had been loaded. This would result
in a kernel panic.
The load order of these built-in drivers is based on the order in which
drivers/staging/vme and driver/vme are compiled.
This patch changes the VME core driver to use the subsys_initcall()
macro which ensures that it is loaded before all other VME drivers
regardless of the order in which they are compiled.
Tested-by: Aaron Sierra <asie...@xes-inc.com>
Signed-off-by: Martyn Welch <martyn.we...@ge.com>
---
drivers/vme/Kconfig | 2 +-
drivers/vme/vme.c | 6 +-----
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/vme/Kconfig b/drivers/vme/Kconfig
index c5c2246..a6a6f95 100644
--- a/drivers/vme/Kconfig
+++ b/drivers/vme/Kconfig
@@ -3,7 +3,7 @@
#
menuconfig VME_BUS
- tristate "VME bridge support"
+ bool "VME bridge support"
depends on PCI
---help---
If you say Y here you get support for the VME bridge Framework.
diff --git a/drivers/vme/vme.c b/drivers/vme/vme.c
index f6856b4..c4ad939 100644
--- a/drivers/vme/vme.c
+++ b/drivers/vme/vme.c
@@ -1512,9 +1512,5 @@ static void __exit vme_exit(void)
bus_unregister(&vme_bus_type);
}
-MODULE_DESCRIPTION("VME bridge driver framework");
-MODULE_AUTHOR("Martyn Welch <martyn.we...@ge.com");
-MODULE_LICENSE("GPL");
-
-module_init(vme_init);
+subsys_initcall(vme_init);
module_exit(vme_exit);
--
1.7.9.5
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
