From: Paul Gortmaker <hidden> Date: 2014-01-14 00:22:04
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
From: Paul Gortmaker <hidden> Date: 2014-01-14 00:20:43
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 <redacted>
---
drivers/bus/omap_l3_smx.c | 1 +
1 file changed, 1 insertion(+)
From: Paul Gortmaker <hidden> Date: 2014-01-14 00:20:45
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 <redacted>
---
drivers/mailbox/pl320-ipc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Paul Gortmaker <hidden> Date: 2014-01-14 00:22:05
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 <redacted>
---
arch/arm/mach-vexpress/spc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)