[PATCH 0/3] arm: remap non-modular uses of module_init properly

[Paul Gortmaker]

The goal is to move module_init/module_exit from init.h and into
module.h -- however in doing so, we uncover several instances in
ARM code where module_init is used somewhat incorrectly by non modular
code, and a file that needs module.h but isn't sourcing it. We need to
make these fixups 1st before changing the headers so that we don't cause
build failures later on.

The changes are largely inert, however we do cause a largely trivial
change in one initcall ordering -- that happens because module_init
is really device_initcall; but I didn't use device_initcall because
subsys_initcall seems somewhat more appropriate.

All modified files were build tested on today's linux next tree.

Paul.
---

Paul Gortmaker (3):
arm: use subsys_initcall in non-modular pl320 IPC code
arm: include module.h in drivers/bus/omap_l3_smx.c
arm: don't use module_init in non-modular mach-vexpress/spc.c code

arch/arm/mach-vexpress/spc.c | 2 +-
drivers/bus/omap_l3_smx.c | 1 +
drivers/mailbox/pl320-ipc.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)

--
1.8.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Paul Gortmaker]

The drivers/mailbox/pl320-ipc.o is dependent on config PL320_MBOX
which is declared as a bool. Hence the code is never going to be
modular. So using module_init as an alias for __initcall can be
somewhat misleading.

Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing. Also add an inclusion of init.h, as
that was previously implicit.

Note that direct use of __initcall is discouraged, vs. one of the
priority categorized subgroups. As __initcall gets mapped onto
device_initcall, our use of subsys_initcall (which seems to make
sense for IPC code) will thus change this registration from a
level 6-device to a level 4-subsys (i.e. slightly earlier).
However no impact of that small difference is expected.

Signed-off-by: Paul Gortmaker <paul.go...@windriver.com>
---
drivers/mailbox/pl320-ipc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mailbox/pl320-ipc.c b/drivers/mailbox/pl320-ipc.c
index d873cbae2fbb..b2737a2df1d3 100644
--- a/drivers/mailbox/pl320-ipc.c
+++ b/drivers/mailbox/pl320-ipc.c
@@ -195,4 +195,4 @@ static int __init ipc_init(void)
{
return amba_driver_register(&pl320_driver);
}
-module_init(ipc_init);
+subsys_initcall(ipc_init);

[Paul Gortmaker]

The spc.o is built for ARCH_VEXPRESS_SPC -- which is bool, and hence
this code is either present or absent. It will never be modular,
so using module_init as an alias for __initcall can be somewhat

misleading.

Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.

Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets

mapped onto device_initcall, our use of device_initcall
directly in this change means that the runtime impact is
zero -- it will remain at level 6 in initcall ordering.

Signed-off-by: Paul Gortmaker <paul.go...@windriver.com>
---

arch/arm/mach-vexpress/spc.c | 2 +-

1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-vexpress/spc.c b/arch/arm/mach-vexpress/spc.c
index c26ef5b92ca7..9312a9b0405b 100644
--- a/arch/arm/mach-vexpress/spc.c
+++ b/arch/arm/mach-vexpress/spc.c
@@ -581,4 +581,4 @@ static int __init ve_spc_clk_init(void)
platform_device_register_simple("vexpress-spc-cpufreq", -1, NULL, 0);
return 0;
}
-module_init(ve_spc_clk_init);
+device_initcall(ve_spc_clk_init);

[Paul Gortmaker]

The config OMAP_INTERCONNECT that this driver depends on (in
drivers/bus/Kconfig) is tristate. So it can be a module.

Also there are module related setup calls within this driver.
Explicitly add module.h to includes so it won't be a build failure
when future cleanups are integrated and the implicit presence
of certain module prototypes disappears.

Signed-off-by: Paul Gortmaker <paul.go...@windriver.com>
---

drivers/bus/omap_l3_smx.c | 1 +
1 file changed, 1 insertion(+)

diff --git a/drivers/bus/omap_l3_smx.c b/drivers/bus/omap_l3_smx.c
index acc216491b8a..8a614332dcb9 100644
--- a/drivers/bus/omap_l3_smx.c
+++ b/drivers/bus/omap_l3_smx.c
@@ -23,6 +23,7 @@
*/

#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>