From 4711e2f9caedaa07e7cdcb5e058a18762d6be9b1 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:49 -0400 Subject: x86: don't use module_init in non-modular intel_mid_vrtc.c The X86_INTEL_MID option 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 is rather 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. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x86@kernel.org Signed-off-by: Paul Gortmaker --- arch/x86/platform/intel-mid/intel_mid_vrtc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/platform/intel-mid/intel_mid_vrtc.c b/arch/x86/platform/intel-mid/intel_mid_vrtc.c index 32947ba0f62d..ee40fcb6e54d 100644 --- a/arch/x86/platform/intel-mid/intel_mid_vrtc.c +++ b/arch/x86/platform/intel-mid/intel_mid_vrtc.c @@ -173,5 +173,4 @@ static int __init intel_mid_device_create(void) return platform_device_register(&vrtc_device); } - -module_init(intel_mid_device_create); +device_initcall(intel_mid_device_create); -- cgit v1.2.3 From d54b675a6b0007422dc13acbecdb1ca2b1a53aeb Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:49 -0400 Subject: x86: don't use module_init in non-modular devicetree.c code The devicetree.o is built for "OF" -- 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. Reported-by: kbuild test robot Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x86@kernel.org Signed-off-by: Paul Gortmaker --- arch/x86/kernel/devicetree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c index 6367a780cc8c..3743b92089de 100644 --- a/arch/x86/kernel/devicetree.c +++ b/arch/x86/kernel/devicetree.c @@ -65,7 +65,7 @@ static int __init add_bus_probe(void) return of_platform_bus_probe(NULL, ce4100_ids, NULL); } -module_init(add_bus_probe); +device_initcall(add_bus_probe); #ifdef CONFIG_PCI struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus) -- cgit v1.2.3 From 8f6b9512ceadc6bd52777c299111dc642b4c65b6 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:49 -0400 Subject: powerpc: use device_initcall for registering rtc devices Currently these two RTC devices are in core platform code where it is not possible for them to be modular. 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 -- they will remain at level 6 in initcall ordering. Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Geoff Levand Acked-by: Geoff Levand Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Paul Gortmaker --- arch/powerpc/kernel/time.c | 2 +- arch/powerpc/platforms/ps3/time.c | 3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 56f44848b044..43922509a483 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -1124,4 +1124,4 @@ static int __init rtc_init(void) return PTR_ERR_OR_ZERO(pdev); } -module_init(rtc_init); +device_initcall(rtc_init); diff --git a/arch/powerpc/platforms/ps3/time.c b/arch/powerpc/platforms/ps3/time.c index ce73ce865613..791c6142c4a7 100644 --- a/arch/powerpc/platforms/ps3/time.c +++ b/arch/powerpc/platforms/ps3/time.c @@ -92,5 +92,4 @@ static int __init ps3_rtc_init(void) return PTR_ERR_OR_ZERO(pdev); } - -module_init(ps3_rtc_init); +device_initcall(ps3_rtc_init); -- cgit v1.2.3 From a390a2f18147533359d4e45cb13438d42580da84 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:49 -0400 Subject: powerpc: don't use module_init in non-modular 83xx suspend code The suspend.o is built for SUSPEND -- 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. Cc: Scott Wood Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Paul Gortmaker --- arch/powerpc/platforms/83xx/suspend.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/83xx/suspend.c b/arch/powerpc/platforms/83xx/suspend.c index c9adbfb65006..fcbea4b51a78 100644 --- a/arch/powerpc/platforms/83xx/suspend.c +++ b/arch/powerpc/platforms/83xx/suspend.c @@ -445,5 +445,4 @@ static int pmc_init(void) { return platform_driver_register(&pmc_driver); } - -module_init(pmc_init); +device_initcall(pmc_init); -- cgit v1.2.3 From 4a0ece7ceceab251e92e7f98e7926642a065727b Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:49 -0400 Subject: arm: don't use module_init in non-modular mach-vexpress/spc.c code 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. Cc: Russell King Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Paul Gortmaker --- 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 f61158c6ce71..5766ce2be32b 100644 --- a/arch/arm/mach-vexpress/spc.c +++ b/arch/arm/mach-vexpress/spc.c @@ -589,4 +589,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); -- cgit v1.2.3 From 2e21fa2d11ab61e1827bd5bb1e0e2484931d68e1 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:49 -0400 Subject: ia64: don't use module_init for non-modular core kernel/mca.c code The mca.c code is always built in. It will never be modular, so using module_init as an alias for __initcall is rather 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. Direct use of __initcall is discouraged, vs prioritized ones. Use of device_initcall is consistent with what __initcall maps onto, and hence does not change the init order, making the impact of this change zero. Should someone with real hardware for boot testing want to change it later to arch_initcall or something different, they can do that at a later date. Cc: Tony Luck Cc: Fenghua Yu Cc: linux-ia64@vger.kernel.org Signed-off-by: Paul Gortmaker --- arch/ia64/sn/kernel/mca.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/ia64/sn/kernel/mca.c b/arch/ia64/sn/kernel/mca.c index 27793f7aa99c..5b799d4deb74 100644 --- a/arch/ia64/sn/kernel/mca.c +++ b/arch/ia64/sn/kernel/mca.c @@ -142,5 +142,4 @@ static int __init sn_salinfo_init(void) salinfo_platform_oemdata = &sn_salinfo_platform_oemdata; return 0; } - -module_init(sn_salinfo_init) +device_initcall(sn_salinfo_init); -- cgit v1.2.3 From 2a177fd1d92f669f8f493a61e195ff4e3c50f95f Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:50 -0400 Subject: ia64: don't use module_init in non-modular sim/simscsi.c code The simscsi.o is built for HP_SIMSCSI -- 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. And since it can't be modular, we remove all the __exitcall stuff related to module_exit() -- it is dead code that won't ever be executed. Cc: Tony Luck Cc: Fenghua Yu Cc: linux-ia64@vger.kernel.org Signed-off-by: Paul Gortmaker --- arch/ia64/hp/sim/simscsi.c | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/arch/ia64/hp/sim/simscsi.c b/arch/ia64/hp/sim/simscsi.c index 3a428f19a001..085047f3a545 100644 --- a/arch/ia64/hp/sim/simscsi.c +++ b/arch/ia64/hp/sim/simscsi.c @@ -368,13 +368,4 @@ simscsi_init(void) scsi_host_put(host); return error; } - -static void __exit -simscsi_exit(void) -{ - scsi_remove_host(host); - scsi_host_put(host); -} - -module_init(simscsi_init); -module_exit(simscsi_exit); +device_initcall(simscsi_init); -- cgit v1.2.3 From 73de14e8cdc733bbc8eda006f813d5aa51511139 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:50 -0400 Subject: cris: don't use module_init for non-modular core intmem.c code The intmem.c code is always built in. It will never be modular, so using module_init as an alias for __initcall is rather 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. Direct use of __initcall is discouraged, vs prioritized ones. Use of device_initcall is consistent with what __initcall maps onto, and hence does not change the init order, making the impact of this change zero. Should someone with real hardware for boot testing want to change it later to arch_initcall or something different, they can do that at a later date. Reported-by: kbuild test robot Cc: Mikael Starvik Cc: Jesper Nilsson Acked-by: Jesper Nilsson Cc: linux-cris-kernel@axis.com Signed-off-by: Paul Gortmaker --- arch/cris/arch-v32/mm/intmem.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/cris/arch-v32/mm/intmem.c b/arch/cris/arch-v32/mm/intmem.c index 1b17d92cef8e..9ef56092a4c5 100644 --- a/arch/cris/arch-v32/mm/intmem.c +++ b/arch/cris/arch-v32/mm/intmem.c @@ -145,6 +145,5 @@ unsigned long crisv32_intmem_virt_to_phys(void* addr) (unsigned long)intmem_virtual + MEM_INTMEM_START + RESERVED_SIZE); } - -module_init(crisv32_intmem_init); +device_initcall(crisv32_intmem_init); -- cgit v1.2.3 From aed6850a1390c2b208b91b2fae0199fc14b94a26 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:50 -0400 Subject: parisc: don't use module_init for non-modular core pdc_cons code The pdc_cons.c code is always built in. It will never be modular, so using module_init as an alias for __initcall is rather 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. Direct use of __initcall is discouraged, vs prioritized ones. Use of device_initcall is consistent with what __initcall maps onto, and hence does not change the init order, making the impact of this change zero. Should someone with real hardware for boot testing want to change it later to arch_initcall or something different, they can do that at a later date. Reported-by: kbuild test robot Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: linux-parisc@vger.kernel.org Signed-off-by: Paul Gortmaker --- arch/parisc/kernel/pdc_cons.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/parisc/kernel/pdc_cons.c b/arch/parisc/kernel/pdc_cons.c index d5cae55195ec..10a5ae9553fd 100644 --- a/arch/parisc/kernel/pdc_cons.c +++ b/arch/parisc/kernel/pdc_cons.c @@ -207,8 +207,7 @@ static int __init pdc_console_tty_driver_init(void) return 0; } - -module_init(pdc_console_tty_driver_init); +device_initcall(pdc_console_tty_driver_init); static struct tty_driver * pdc_console_device (struct console *c, int *index) { -- cgit v1.2.3 From 15becabd89fa3fec6aa864fbd1b50b5b1871eee2 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:50 -0400 Subject: parisc64: don't use module_init for non-modular core perf code The perf.c code depends on CONFIG_64BIT, so it is either built-in or absent. It will never be modular, so using module_init as an alias for __initcall is rather 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. Aside from it not making sense, it also causes a ~10% increase in CPP overhead due to module.h having a large list of headers itself -- for example compare line counts: device_initcall() and 20238 arch/parisc/kernel/perf.i module_init() and 22194 arch/parisc/kernel/perf.i Direct use of __initcall is discouraged, vs prioritized ones. Use of device_initcall is consistent with what __initcall maps onto, and hence does not change the init order, making the impact of this change zero. Should someone with real hardware for boot testing want to change it later to arch_initcall or something different, they can do that at a later date. Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: linux-parisc@vger.kernel.org Signed-off-by: Paul Gortmaker --- arch/parisc/kernel/perf.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/parisc/kernel/perf.c b/arch/parisc/kernel/perf.c index ba0c053e25ae..518f4f5f1f43 100644 --- a/arch/parisc/kernel/perf.c +++ b/arch/parisc/kernel/perf.c @@ -543,6 +543,7 @@ static int __init perf_init(void) return 0; } +device_initcall(perf_init); /* * perf_start_counters(void) @@ -847,5 +848,3 @@ printk("perf_rdr_write\n"); } printk("perf_rdr_write done\n"); } - -module_init(perf_init); -- cgit v1.2.3 From 1b4d5beecbeb4608a0fdb77c3b8ba182f0cfb4b6 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:50 -0400 Subject: mn10300: don't use module_init in non-modular flash.c code The flash.o is built for obj-y -- and hence this code is always present. 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. Reported-by: kbuild test robot Cc: David Howells Acked-by: David Howells Cc: Koichi Yasutake Cc: linux-am33-list@redhat.com Signed-off-by: Paul Gortmaker --- arch/mn10300/unit-asb2303/flash.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/mn10300/unit-asb2303/flash.c b/arch/mn10300/unit-asb2303/flash.c index 17fe083fcb6f..b03d8738d67c 100644 --- a/arch/mn10300/unit-asb2303/flash.c +++ b/arch/mn10300/unit-asb2303/flash.c @@ -96,5 +96,4 @@ static int __init asb2303_mtd_init(void) platform_device_register(&asb2303_sysflash); return 0; } - -module_init(asb2303_mtd_init); +device_initcall(asb2303_mtd_init); -- cgit v1.2.3 From b205118bdb4b515b4b4f5058aa9f5a12668386c3 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:50 -0400 Subject: sh: don't use module_init in non-modular psw.c code The psw.o is built for obj-y -- and hence this code is always present. 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. Reported-by: kbuild test robot Cc: Paul Mundt Cc: linux-sh@vger.kernel.org Signed-off-by: Paul Gortmaker --- arch/sh/boards/mach-landisk/psw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sh/boards/mach-landisk/psw.c b/arch/sh/boards/mach-landisk/psw.c index bef83522f958..5192b1f43ada 100644 --- a/arch/sh/boards/mach-landisk/psw.c +++ b/arch/sh/boards/mach-landisk/psw.c @@ -140,4 +140,4 @@ static int __init psw_init(void) { return platform_add_devices(psw_devices, ARRAY_SIZE(psw_devices)); } -module_init(psw_init); +device_initcall(psw_init); -- cgit v1.2.3 From 30e3c6428f18b5b8e78602a5a7cc653aee3bfe99 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:50 -0400 Subject: xtensa: don't use module_init for non-modular core network.c code The network.c code is piggybacking off of the arch independent CONFIG_NET, which is bool. So the code is either built in or absent. It will never be modular, so using module_init as an alias for __initcall is rather 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. Direct use of __initcall is discouraged, vs prioritized ones. Use of device_initcall is consistent with what __initcall maps onto, and hence does not change the init order, making the impact of this change zero. Should someone with real hardware for boot testing want to change it later to arch_initcall or something different, they can do that at a later date. Cc: Chris Zankel Cc: Max Filippov Cc: Thomas Meyer Cc: linux-xtensa@linux-xtensa.org Signed-off-by: Paul Gortmaker --- arch/xtensa/platforms/iss/network.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/xtensa/platforms/iss/network.c b/arch/xtensa/platforms/iss/network.c index 17b1ef3232e4..8ab021b1f141 100644 --- a/arch/xtensa/platforms/iss/network.c +++ b/arch/xtensa/platforms/iss/network.c @@ -681,6 +681,4 @@ static int iss_net_init(void) return 1; } - -module_init(iss_net_init); - +device_initcall(iss_net_init); -- cgit v1.2.3 From 791ed0bb5558dfdc4040563bd0b7dc24450fa732 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 1 May 2015 20:05:51 -0400 Subject: drivers/clk: don't use module_init in clk-nomadik.c which is non-modular The clk-nomadik.o is built for ARCH_NOMADIK -- 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. Cc: Mike Turquette Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Paul Gortmaker --- drivers/clk/clk-nomadik.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c index 05e04ce0f148..c9487179f25f 100644 --- a/drivers/clk/clk-nomadik.c +++ b/drivers/clk/clk-nomadik.c @@ -503,8 +503,7 @@ static int __init nomadik_src_clk_init_debugfs(void) NULL, NULL, &nomadik_src_clk_debugfs_ops); return 0; } - -module_init(nomadik_src_clk_init_debugfs); +device_initcall(nomadik_src_clk_init_debugfs); #endif -- cgit v1.2.3 From 4d38e5c48f4095be21343869ad741676ab4e518f Mon Sep 17 00:00:00 2001 From: James Hogan Date: Fri, 5 Jun 2015 22:17:18 +0100 Subject: tty/metag_da: Avoid module_init/module_exit in non-modular code MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The metag_da TTY driver can't get built as a module at the moment, but it still uses module_init() and module_exit(). Those macros are moving to module.h which isn't included by metag_da.c, which will result in the following build warnings (remarkably no build errors) and an apparent failure to boot as the TTY driver won't be loaded. drivers/tty/metag_da.c:660: warning: data definition has no type or storage class drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration of ‘module_init’ drivers/tty/metag_da.c:660: warning: parameter names (without types) in function declaration drivers/tty/metag_da.c:661: warning: data definition has no type or storage class drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration of ‘module_exit’ drivers/tty/metag_da.c:661: warning: parameter names (without types) in function declaration drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used drivers/tty/metag_da.c In function ‘dash_console_write’: drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ discards qualifiers from pointer target type Instead of just adding the module.h include, now would be a good time to remove the use of these macros, replacing the module_init with device_initcall, and removing the exit function altogether since it isn't needed. If module support is added later the code can always be resurrected. Reported-by: Guenter Roeck Tested-by: Guenter Roeck Signed-off-by: James Hogan Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-metag@vger.kernel.org Cc: Paul Gortmaker Signed-off-by: Paul Gortmaker --- drivers/tty/metag_da.c | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-) diff --git a/drivers/tty/metag_da.c b/drivers/tty/metag_da.c index 3774600741d8..9325262289f9 100644 --- a/drivers/tty/metag_da.c +++ b/drivers/tty/metag_da.c @@ -640,25 +640,7 @@ err_destroy_ports: put_tty_driver(channel_driver); return ret; } - -static void dashtty_exit(void) -{ - int nport; - struct dashtty_port *dport; - - del_timer_sync(&put_timer); - kthread_stop(dashtty_thread); - del_timer_sync(&poll_timer); - tty_unregister_driver(channel_driver); - for (nport = 0; nport < NUM_TTY_CHANNELS; nport++) { - dport = &dashtty_ports[nport]; - tty_port_destroy(&dport->port); - } - put_tty_driver(channel_driver); -} - -module_init(dashtty_init); -module_exit(dashtty_exit); +device_initcall(dashtty_init); #ifdef CONFIG_DA_CONSOLE -- cgit v1.2.3 From 84c3e5bf1defc035d63869bbb0f5f80d276c1fc7 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Sun, 14 Jun 2015 16:55:25 -0400 Subject: cris: don't use module_init for non-modular core eeprom.c code The eeprom.c code is compiled based on the Kconfig setting ETRAX_I2C_EEPROM, which is bool. So the code is either built in or absent. It will never be modular, so using module_init as an alias for __initcall is rather 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. Direct use of __initcall is discouraged, vs prioritized ones. Use of device_initcall is consistent with what __initcall maps onto, and hence does not change the init order, making the impact of this change zero. Should someone with real hardware for boot testing want to change it later to arch_initcall or something different, they can do that at a later date. Cc: Mikael Starvik Cc: Jesper Nilsson Cc: linux-cris-kernel@axis.com Signed-off-by: Paul Gortmaker --- arch/cris/arch-v10/drivers/eeprom.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/cris/arch-v10/drivers/eeprom.c b/arch/cris/arch-v10/drivers/eeprom.c index 5047a33043bd..f679a19dfeb8 100644 --- a/arch/cris/arch-v10/drivers/eeprom.c +++ b/arch/cris/arch-v10/drivers/eeprom.c @@ -848,5 +848,4 @@ static void eeprom_disable_write_protect(void) /* Write protect disabled */ } } - -module_init(eeprom_init); +device_initcall(eeprom_init); -- cgit v1.2.3 From 33d69ca12b44ef3c7be8f948ffa5a35652e1f2ff Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Mon, 15 Jun 2015 16:48:22 -0500 Subject: drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c This file is built for a bool Kconfig variable, and hence this code is either present or absent. It currently can 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. And since it can't be modular, we remove all the __exitcall stuff related to module_exit() -- it is dead code that won't ever be executed. Cc: Bryan Wu Cc: Richard Purdie Cc: Jacek Anaszewski Acked-by: Jacek Anaszewski Cc: linux-leds@vger.kernel.org Signed-off-by: Paul Gortmaker --- drivers/leds/leds-cobalt-raq.c | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/leds/leds-cobalt-raq.c b/drivers/leds/leds-cobalt-raq.c index 06dbe18a2065..b316df4a8c1e 100644 --- a/drivers/leds/leds-cobalt-raq.c +++ b/drivers/leds/leds-cobalt-raq.c @@ -108,20 +108,8 @@ err_null: return retval; } -static int cobalt_raq_led_remove(struct platform_device *pdev) -{ - led_classdev_unregister(&raq_power_off_led); - led_classdev_unregister(&raq_web_led); - - if (led_port) - led_port = NULL; - - return 0; -} - static struct platform_driver cobalt_raq_led_driver = { .probe = cobalt_raq_led_probe, - .remove = cobalt_raq_led_remove, .driver = { .name = "cobalt-raq-leds", }, @@ -131,5 +119,4 @@ static int __init cobalt_raq_led_init(void) { return platform_driver_register(&cobalt_raq_led_driver); } - -module_init(cobalt_raq_led_init); +device_initcall(cobalt_raq_led_init); -- cgit v1.2.3 From b0c6d93014c8f2f53b70e9362b9fbec13b8e3aa0 Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Mon, 15 Jun 2015 09:56:26 -0400 Subject: MIPS: don't use module_init in non-modular cobalt/mtd.c file As of commit 34b1252bd91851f77f89fbb6829a04efad900f41 ("MIPS: Cobalt: Do not build MTD platform device registration code as module.") this file became built-in instead of modular. So we should also stop using module_init as an alias for __initcall as that can be rather 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. Direct use of __initcall is discouraged, vs prioritized ones. Use of device_initcall is consistent with what __initcall maps onto, and hence does not change the init order, making the impact of this change zero. Cc: Ralf Baechle Cc: linux-mips@linux-mips.org Signed-off-by: Paul Gortmaker --- arch/mips/cobalt/mtd.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/mips/cobalt/mtd.c b/arch/mips/cobalt/mtd.c index 8db7b5d81560..83e1b1093d5f 100644 --- a/arch/mips/cobalt/mtd.c +++ b/arch/mips/cobalt/mtd.c @@ -57,5 +57,4 @@ static int __init cobalt_mtd_init(void) return 0; } - -module_init(cobalt_mtd_init); +device_initcall(cobalt_mtd_init); -- cgit v1.2.3