user/sven/linux.git/include/linux/init.h, branch v4.2.4

module: relocate module_init from init.h to module.h

2015-07-06T03:59:14Z

Modular users will always be users of init functionality, but users of init functionality are not necessarily always modules. Hence any functionality like module_init and module_exit would be more at home in the module.h file. And module.h should explicitly include init.h to make the dependency clear. We've already done all the legwork needed to ensure that this move does not cause any build regressions due to implicit header file include assumptions about where module_init lives. Cc: Rusty Russell Acked-by: Rusty Russell Signed-off-by: Paul Gortmaker

init: delete the __cpuinit related stubs

2015-06-16T18:12:23Z

The __cpuinit support was removed several releases ago in 3.11-rc1 with commit 22f0a27367742f65130c0fb25ef00f7297e032c1 ("init.h: remove __cpuinit sections from the kernel") People have had a chance to update their out of tree code, so now we remove the no-op stubs to ensure no more new use cases can creep back in. Also delete the mention of __cpuinitdata from the tag script. Signed-off-by: Paul Gortmaker

init.h: Clean up the __setup()/early_param() macros

2015-03-05T08:23:12Z

Make it all a bit easier on the eyes: - Move the __setup_param() lines right after their init functions - Use consistent vertical spacing - Use more horizontal spacing to make it look like regular C code - Use standard comment style Cc: Luis R. Rodriguez Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Borislav Petkov Cc: Dave Hansen Cc: David Vrabel Cc: Dexuan Cui Cc: Greg Kroah-Hartman Cc: H. Peter Anvin Cc: Jan Beulich Cc: Joonsoo Kim Cc: Juergen Gross Cc: Linus Torvalds Cc: Pavel Machek Cc: Thomas Gleixner Cc: Tony Lindgren Cc: Toshi Kani Cc: Vlastimil Babka Cc: Xishi Qiu Cc: julia.lawall@lip6.fr Signed-off-by: Ingo Molnar

init.h: Add early_param_on_off()

2015-03-05T07:02:12Z

At times all you need is a kconfig variable to enable a feature, by default but you may want to also enable / disable it through a kernel parameter. In such cases the parameter routines to turn the thing on / off are really simple. Just use a wrapper for this, it lets us generalize the code and makes it easier to associate parameters with related kernel configuration options. Signed-off-by: Luis R. Rodriguez Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Borislav Petkov Cc: Dave Hansen Cc: David Vrabel Cc: Dexuan Cui Cc: Greg Kroah-Hartman Cc: H. Peter Anvin Cc: JBeulich@suse.com Cc: Jan Beulich Cc: Joonsoo Kim Cc: Juergen Gross Cc: Linus Torvalds Cc: Pavel Machek Cc: Thomas Gleixner Cc: Tony Lindgren Cc: Toshi Kani Cc: Vlastimil Babka Cc: Xishi Qiu Cc: julia.lawall@lip6.fr Link: http://lkml.kernel.org/r/1425518654-3403-4-git-send-email-mcgrof@do-not-panic.com Signed-off-by: Ingo Molnar

init.h: Update initcall_sync variants to fix build errors

2014-05-27T21:26:31Z

We are getting randconfig build errors on device drivers with tristate Kconfig option if they are using custom initcall levels. Rather than add ifdeffery into the drivers, let's add the missing initcall_sync variants. As the comment in init.h has kept people from updating the list of initcalls that can be just module_init when the driver is loaded as a loadable module, let's also update the comment a bit to describe valid use cases custom initcall levels. While most drivers should nowadays use just regular module_init because of the deferred probe, we do have quite a few custom initcall levels left that we cannot remove until tested properly. There are also still few valid cases where a custom initcall level might make sense that I'm aware of. For example a bus snooping driver can provide information about invalid bus access and is handy loader early when built in. But there's no hard dependency to have it necessarily built in and a loadable module is a valid option. Another example is a driver implementing a Linux framework like pinctrl framework. That driver may be needed early on some platforms because of legacy reasons, while it can be just a regular module_init on most platforms. Signed-off-by: Tony Lindgren Cc: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

lto, workaround: Add workaround for initcall reordering

2014-02-14T04:24:13Z

Work around a LTO gcc problem: when there is no reference to a variable in a module it will be moved to the end of the program. This causes reordering of initcalls which the kernel does not like. Add a dummy reference function to avoid this. The function is deleted by the linker. This replaces a previous much slower workaround. Thanks to Jan "Honza" Hubička for suggesting this technique. Suggested-by: Jan Hubička Signed-off-by: Andi Kleen Link: http://lkml.kernel.org/r/1391846481-31491-4-git-send-email-ak@linux.intel.com Signed-off-by: H. Peter Anvin

init.h: add missing initcall variants

2013-12-11T06:58:13Z

Add missing initcall variants when building for loadable modules. This fixes this build error on powerpc allmodconfig: drivers/tty/ehv_bytechan.c: error: type defaults to 'int' in declaration of 'console_initcall' [-Werror=implicit-int] Signed-off-by: Randy Dunlap Reported-by: Geert Uytterhoeven Cc: Benjamin Herrenschmidt Acked-by: Timur Tabi Signed-off-by: Greg Kroah-Hartman

init.h: document the existence of __initconst

2013-11-13T03:09:26Z

Initdata can be const since more than 5 years, using the __initconst keyword. Signed-off-by: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

initmpfs: move rootfs code from fs/ramfs/ to init/

2013-09-11T22:59:37Z

When the rootfs code was a wrapper around ramfs, having them in the same file made sense. Now that it can wrap another filesystem type, move it in with the init code instead. This also allows a subsequent patch to access rootfstype= command line arg. Signed-off-by: Rob Landley Cc: Jeff Layton Cc: Jens Axboe Cc: Stephen Warren Cc: Rusty Russell Cc: Jim Cromie Cc: Sam Ravnborg Cc: Greg Kroah-Hartman Cc: "Eric W. Biederman" Cc: Alexander Viro Cc: "H. Peter Anvin" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

init.h: remove __cpuinit sections from the kernel

2013-06-26T16:13:18Z

The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. As an interim step, we can dummy out the macros to be no-ops, and this will allow us to avoid a giant tree-wide patch, and instead we can feed in smaller chunks mainly via the arch/ trees. This is in keeping with commit 78d86c213f28193082b5d8a1a424044b7ba406f1 ("init.h: Remove __dev* sections from the kernel") We don't strictly need to dummy out the macros to do this, but if we don't then some harmless section mismatch warnings may temporarily result. For example, notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c) and are flagged as __cpuinit. And hence the calling functions in the arch specific code are also expected to be __cpuinit -- if not, then we get the section mismatch warning. Two of the three __CPUINIT variants are not used whatsoever, and so they are simply removed directly at this point in time. [1] https://lkml.org/lkml/2013/5/20/589 Signed-off-by: Paul Gortmaker