Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
GIT c5901c20eb0341722035975a272a2a7b647fbb32 commit eeb64c14275e52740d6410632e62e0ad9b88ca70 Author: Samuel Thibault <[email protected]> Date: Sat Jun 6 11:44:39 2015 -0700 tty/vt/keyboard: define LED triggers for VT keyboard lock states In addition to defining triggers for VT LED states, let's define triggers for VT keyboard lock states, such as "kbd-shiftlock", "kbd-altgrlock", etc. This permits to fix #7063 from userland by using a modifier to implement proper CapsLock behavior and have the keyboard caps lock led show that modifier state. Signed-off-by: Samuel Thibault <[email protected]> Tested-by: Pavel Machek <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> commit 5235552273e6b68abbed3b3047af6344e2e60c2c Author: Samuel Thibault <[email protected]> Date: Mon Mar 16 21:19:44 2015 -0700 tty/vt/keyboard: define LED triggers for VT LED states Now that input core allows controlling keyboards LEDs via standard LED subsystem triggers let's switch VT keyboard code to make use of this feature. We will define the following standard triggers: "kbd-scrollock", "kbd-numlock", "kbd-capslock", and "kbd-kanalock" which are default triggers for respective LEDs on keyboards. Signed-off-by: Samuel Thibault <[email protected]> Tested-by: Pavel Machek <[email protected]> Acked-by: Pavel Machek <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> commit 10e87dc42a086c256b25334b6c1c89214feba9a7 Author: Andrew Duggan <[email protected]> Date: Tue Jun 16 14:08:41 2015 -0700 HID: rmi: Disable populating F30 when the touchpad has physical buttons Physical buttons do not use F30 to report their state and in some cases the data reported in F30 is incorrect and inconsistent with what is reported by the HID descriptor. When physical buttons are present, ignore F30 and let hid-input report buttons based on what is defined in the HID descriptor. Signed-off-by: Andrew Duggan <[email protected]> Reviewed-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> commit ba8d134e75deb1904b146a4decb0bc6a217333cd Author: Nishanth Menon <[email protected]> Date: Mon Apr 20 19:51:34 2015 -0500 rtc: ds1307: Enable the mcp794xx alarm after programming time Alarm interrupt enable register is at offset 0x7, while the time registers for the alarm follow that. When we program Alarm interrupt enable prior to programming the time, it is possible that previous time value could be close or match at the time of alarm enable resulting in interrupt trigger which is unexpected (and does not match the time we expect it to trigger). To prevent this scenario from occuring, program the ALM0_EN bit only after the alarm time is appropriately programmed. Ofcourse, I2C programming is non-atomic, so there are loopholes where the interrupt wont trigger if the time requested is in the past at the time of programming the ALM0_EN bit. However, we will not have unexpected interrupts while the time is programmed after the interrupt are enabled. Signed-off-by: Nishanth Menon <[email protected]> Reviewed-by: Grygorii Strashko <[email protected]> Signed-off-by: Alexandre Belloni <[email protected]> commit b7ae128d728c42583dac9db48dce9a44bc0fb900 Author: Robert Richter <[email protected]> Date: Fri Jun 5 19:49:26 2015 +0200 ahci: Add support for Cavium's ThunderX host controller This patch adds support for Cavium's ThunderX host controller. The controller resides on the SoC and is a AHCI compatible SATA controller with one port, compliant with Serial ATA 3.1 and AHCI Revision 1.31. There can exists multiple SATA controllers on the SoC. The controller depends on MSI-X support since the PCI ECAM controller on the SoC does not implement MSI nor lagacy intx interrupt support. Thus, during device initialization, if MSI fails MSI-X will be used to enable the device's interrupts. The controller uses non-standard BAR0 for its register range. The already existing device lookup (vendor and device id) that is already implemented for other host controllers is used to change the PCI BAR. Signed-off-by: Robert Richter <[email protected]> Signed-off-by: Tejun Heo <[email protected]> commit ee2aad42e4b6eaa9721196f07f7d5d8d049e6530 Author: Robert Richter <[email protected]> Date: Fri Jun 5 19:49:25 2015 +0200 ahci: Add generic MSI-X support for single interrupts to SATA PCI driver This patch adds generic MSI-X support for single interrupts to the SATA PCI driver. MSI-X support is needed for host controller that only have MSI-X support implemented, but no MSI or intx. This patch only adds support for single interrupts, multiple per-port MSI-X interrupts are not yet implemented. The new implementation still initializes MSIs first. Only if that fails, the code tries to enable MSI-X. If that fails too, setup is continued with intx interrupts. To not break other chips by this generic code change, there are the following precautions: * Interrupt ranges are not enabled at all. * Only single interrupt mode is enabled for msix cap devices. Thus, only one interrupt will be setup. * During the discussion with Tejun we agreed to change the init sequence from msix-msi-intx to msi-msix-intx. Thus, if a device offers msi and init does not fail, the msix init code will not be executed. This is equivalent to current code. With this, the code only setups single mode msix as a last resort if msi fails. No interrupt range is enabled at all. Only one interrupt will be enabled. tj: comment edits. Changes of the patch series: v5: * updated patch subject that the patch only implements single IRQ * moved Cavium specific code to a separate patch * detect Cavium ThunderX device with PCI_CLASS_STORAGE_SATA_AHCI instead of vendor/dev id * added more comments to the code * enable single msix support for all kind of devices (removing strict check) * rebased onto update libata/for-4.2 with patch 1, 2 applied v4: * removed implementation of ahci_init_intx() * improved patch descriptions * rebased onto libata/for-4.2 v3: * store irq number in struct ahci_host_priv * change initialization order from msix-msi-intx to msi-msix-intx * improve comments in ahci_init_msix() * improve error message in ahci_init_msix() * do not enable MSI-X if MSI is actively disabled for the device v2: * determine irq vector from pci_dev->msi_list Based on a patch from Sunil Goutham <[email protected]>. Signed-off-by: Robert Richter <[email protected]> Signed-off-by: Tejun Heo <[email protected]> commit e0dd268a2c983acf2b52130b489b3b5724e26b39 Author: Uwe Kleine-König <[email protected]> Date: Fri Jun 12 00:35:43 2015 -0700 leds: aat1290: pass flags parameter to devm_gpiod_get Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. In this case the driver cannot easily be simplified but as the flags parameter will become mandatory soon this change is necessary beforehand. Signed-off-by: Uwe Kleine-König <[email protected]> Acked-by: Jacek Anaszewski <[email protected]> Signed-off-by: Bryan Wu <[email protected]> commit c8e27605c687d2d628217bef721e955d4baa1ce1 Author: Uwe Kleine-König <[email protected]> Date: Fri Jun 12 00:32:23 2015 -0700 leds: ktd2692: pass flags parameter to devm_gpiod_get Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. In this case the driver cannot easily be simplified but as the flags parameter will become mandatory soon this change is necessary beforehand. Signed-off-by: Uwe Kleine-König <[email protected]> Acked-by: Jacek Anaszewski <[email protected]> Signed-off-by: Bryan Wu <[email protected]> commit bc3e452003d02b8ec21546490aaed36003a83864 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:13:42 2015 -0400 module: relocate module_init from init.h to module.h 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 <[email protected]> Acked-by: Rusty Russell <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit b0c6d93014c8f2f53b70e9362b9fbec13b8e3aa0 Author: Paul Gortmaker <[email protected]> Date: Mon Jun 15 09:56:26 2015 -0400 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 <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 33d69ca12b44ef3c7be8f948ffa5a35652e1f2ff Author: Paul Gortmaker <[email protected]> Date: Mon Jun 15 16:48:22 2015 -0500 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 <[email protected]> Cc: Richard Purdie <[email protected]> Cc: Jacek Anaszewski <[email protected]> Acked-by: Jacek Anaszewski <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 32e805e7c6a343894c95a3431973e8ddad4aa2cf Author: Paul Gortmaker <[email protected]> Date: Fri Jun 5 09:37:19 2015 -0400 tile: add init.h to usb.c to avoid compile failure Pending header cleanups will reveal this file is using the init.h content implicitly with the following fail: arch/tile/kernel/usb.c:69:1: warning: data definition has no type or storage class [enabled by default] arch/tile/kernel/usb.c:69:1: error: type defaults to 'int' in declaration of 'arch_initcall' arch/tile/kernel/usb.c:69:1: warning: parameter names (without types) in function declaration [enabled by default] arch/tile/kernel/usb.c:62:19: warning: 'tilegx_usb_init' defined but not used Explicitly add init.h to get arch_initcall and avoid this. Reported-by: kbuild test robot <[email protected]> Cc: Chris Metcalf <[email protected]> Acked-by: Chris Metcalf <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit 9b9cf81a2d1f5336de2bebae71a9f2b8d5f1a8de Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:13:42 2015 -0400 arm: fix implicit #include <linux/init.h> in entry asm. They use the "_INIT" macro and friends, and hence need to source this header file, vs. relying on getting it implicitly. Cc: Russell King <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 70c4f78b23c69013c908222d55a07c96fea4bba1 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:13:42 2015 -0400 x86: replace __init_or_module with __init in non-modular vsmp_64.c The __init_or_module is from commit 05e12e1c4c09cd35ac9f4e6af1e ("x86: fix 27-rc crash on vsmp due to paravirt during module load"). But as of commit 70511134f61bd6e5eed19f767381f9fb3e762d49 ("Revert "x86: don't compile vsmp_64 for 32bit") this file became obj-y and hence is now only for built-in. That makes any "_or_module" support no longer necessary. We need to distinguish between the two in order to do some header reorganization between init.h and module.h and we don't want to be including module.h in non-modular code. Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 77459a0feca4ae8757a905fd1791f039479e8e1e Author: Paul Gortmaker <[email protected]> Date: Wed Jun 3 11:20:05 2015 -0400 drivers/clk: convert sunxi/clk-mod0.c to use builtin_platform_driver This driver builds based on obj-y and hence will not ever be modular. Change it to use the non-modular registration so that it won't suffer a compile fail once a header move places the modular registration within the module.h file. Cc: "Emilio López" <[email protected]> Cc: Mike Turquette <[email protected]> Cc: Stephen Boyd <[email protected]> Acked-by: Stephen Boyd <[email protected]> Cc: Maxime Ripard <[email protected]> Acked-by: Maxime Ripard <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit e35415e59f86d6b546a3681e2cda4f22b5b142c0 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:10:58 2015 -0400 drivers/power: Convert non-modular syscon-reboot to use builtin_platform_driver This file depends on Kconfig options all of which are a bool, so we use the appropriate registration function, which avoids us relying on an implicit inclusion of <module.h> which we are doing currently. While this currently works, we really don't want to be including the module.h header in non-modular code, which we'd be forced to do, pending some upcoming code relocation from init.h into module.h. So we fix it now by using the non-modular equivalent. Cc: Sebastian Reichel <[email protected]> Acked-By: Sebastian Reichel <[email protected]> Cc: Dmitry Eremin-Solenikov <[email protected]> Cc: David Woodhouse <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 0159ae95e6a923f565937f10518aa3c919527733 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:10:57 2015 -0400 drivers/soc: Convert non-modular soc-realview to use builtin_platform_driver This file depends on Kconfig SOC_REALVIEW which is a bool, so we use the appropriate registration function, which avoids us relying on an implicit inclusion of <module.h> which we are doing currently. While this currently works, we really don't want to be including the module.h header in non-modular code, which we'd be forced to do, pending some upcoming code relocation from init.h into module.h. So we fix it now by using the non-modular equivalent. Cc: Arnd Bergmann <[email protected]> Cc: Linus Walleij <[email protected]> Acked-by: Linus Walleij <[email protected]> Cc: Axel Lin <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit 7d4d9ed6ef5219857865dd57d425f9729d0a39ff Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:10:57 2015 -0400 drivers/soc: Convert non-modular tegra/pmc to use builtin_platform_driver This file depends on Kconfig ARCH_TEGRA which is a bool, so we use the appropriate registration function, which avoids us relying on an implicit inclusion of <module.h> which we are doing currently. While this currently works, we really don't want to be including the module.h header in non-modular code, which we'd be forced to do, pending some upcoming code relocation from init.h into module.h. So we fix it now by using the non-modular equivalent. Cc: Stephen Warren <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Alexandre Courbot <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 5b64127e0529387d4538ecc3dfd49248baf619c5 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:10:57 2015 -0400 drivers/cpufreq: Convert non-modular s5pv210-cpufreq.c to use builtin_platform_driver This file depends on a Kconfig option which is a bool, so we use the appropriate registration function, which avoids us relying on an implicit inclusion of <module.h> which we are doing currently. While this currently works, we really don't want to be including the module.h header in non-modular code, which we'd be forced to do, pending some upcoming code relocation from init.h into module.h. So we fix it now by using the non-modular equivalent. Cc: "Rafael J. Wysocki" <[email protected]> Cc: Viresh Kumar <[email protected]> Acked-by: Viresh Kumar <[email protected]> Cc: Kukjin Kim <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 090d1cf103725f583b3f41fc3185698ae5a7aa64 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:10:57 2015 -0400 drivers/cpuidle: Convert non-modular drivers to use builtin_platform_driver All these drivers are configured with Kconfig options that are declared as bool. Hence it is not possible for the code to be built as modular. However the code is currently using the module_platform_driver() macro for driver registration. While this currently works, we really don't want to be including the module.h header in non-modular code, which we'll be forced to do, pending some upcoming code relocation from init.h into module.h. So we fix it now by using the non-modular equivalent. Cc: "Rafael J. Wysocki" <[email protected]> Cc: Daniel Lezcano <[email protected]> Cc: Michal Simek <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 1dda2b42db1bbc788bf6de0a8141a305484f963b Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:10:57 2015 -0400 drivers/platform: Convert non-modular pdev_bus to use builtin_platform_driver This driver is configured with a Kconfig option that is declared as a bool. Hence it is not possible for the code to be built as modular. However the code is currently using the module_platform_driver() macro for driver registration. While this currently works, we really don't want to be including the module.h header in non-modular code, which we'll be forced to do, pending some upcoming code relocation from init.h into module.h. So we fix it now by using the non-modular equivalent. And since we've already established that the code is non-modular, we can completely drop any code relating to module_exit. Signed-off-by: Paul Gortmaker <[email protected]> commit f309d4443130bf814e991f836e919dca22df37ae Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:10:57 2015 -0400 platform_device: better support builtin boilerplate avoidance We have macros that help reduce the boilerplate for modules that register with no extra init/exit complexity other than the most standard use case. However we see an increasing number of non-modular drivers using these modular_driver() type register functions. There are several downsides to this: 1) The code can appear modular to a reader of the code, and they won't know if the code really is modular without checking the Makefile and Kconfig to see if compilation is governed by a bool or tristate. 2) Coders of drivers may be tempted to code up an __exit function that is never used, just in order to satisfy the required three args of the modular registration function. 3) Non-modular code ends up including the <module.h> which increases CPP overhead that they don't need. 4) It hinders us from performing better separation of the module init code and the generic init code. Here we introduce similar macros, with the mapping from module_driver to builtin_driver and similar, so that simple changes of: module_platform_driver() ---> builtin_platform_driver() module_platform_driver_probe() ---> builtin_platform_driver_probe(). can help us avoid #3 above, without having to code up the same __init functions and device_initcall() boilerplate. For non modular code, module_init becomes __initcall. But 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 -- drivers will remain at level 6 in the initcall ordering. Cc: Greg Kroah-Hartman <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit 5b00c1eb94e5936e5bf5cdd9ad1ddfbed0c39159 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 21:57:34 2015 -0400 x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling This was using module_init, but the current Kconfig situation is as follows: In arch/x86/kernel/cpu/Makefile: obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_intel_pt.o perf_event_intel_bts.o and in arch/x86/Kconfig.cpu: config CPU_SUP_INTEL default y bool "Support Intel processors" if PROCESSOR_SELECT So currently, the end user can not build this code into a module. If in the future, there is desire for this to be modular, then it can be changed to include <linux/module.h> and use module_init. But currently, in the non-modular case, a module_init becomes a device_initcall. But this really isn't a device, so we should choose a more appropriate initcall bucket to put it in. The obvious choice here seems to be arch_initcall, but that does make it earlier than it was currently through device_initcall. As long as perf_pmu_register() is functional, we should be OK. Cc: Peter Zijlstra <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit ca41d24cf56458a699b44e918c5a19b7077df422 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 21:57:34 2015 -0400 x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling This was using module_init, but the current Kconfig situation is as follows: In arch/x86/kernel/cpu/Makefile: obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_intel_pt.o perf_event_intel_bts.o and in arch/x86/Kconfig.cpu: config CPU_SUP_INTEL default y bool "Support Intel processors" if PROCESSOR_SELECT So currently, the end user can not build this code into a module. If in the future, there is desire for this to be modular, then it can be changed to include <linux/module.h> and use module_init. But currently, in the non-modular case, a module_init becomes a device_initcall. But this really isn't a device, so we should choose a more appropriate initcall bucket to put it in. The obvious choice here seems to be arch_initcall, but that does make it earlier than it was currently through device_initcall. As long as perf_pmu_register() is functional, we should be OK. Cc: Peter Zijlstra <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Arnaldo Carvalho de Melo <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 44c5af96de8230ff7268500f48995f9fea5cffe7 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 21:57:34 2015 -0400 mm/page_owner.c: use late_initcall to hook in enabling This was using module_init, but there is no way this code can be modular. In the non-modular case, a module_init becomes a device_initcall, but this really isn't a device. So we should choose a more appropriate initcall bucket to put it in. In order of execution, our close choices are: fs_initcall(fn) rootfs_initcall(fn) device_initcall(fn) late_initcall(fn) ..and since the initcall here goes after debugfs, we really should be post-rootfs, which means late_initcall makes the most sense here. Cc: Andrew Morton <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 4c7217f1f0fe70af7b9e213ef16f1d2f4a4bacaf Author: Paul Gortmaker <[email protected]> Date: Fri May 1 21:57:34 2015 -0400 lib/list_sort: use late_initcall to hook in self tests This was using module_init, but there is no way this code can be modular. In the non-modular case, a module_init becomes a device_initcall, but this really isn't a device. So we should choose a more appropriate initcall bucket to put it in. Assuming boot time self tests need to be observed over a console to be useful, and that the console device could possibly not be fully functional until after device_initcall, we move this to the late_initcall bucket, which is immediately after device_initcall. Cc: Andrew Morton <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit 89f08f64408b630df7d559223f63e616d0814509 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:08:21 2015 -0400 arm: use subsys_initcall in non-modular pl320 IPC code 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 level 6-device to level 4-subsys (i.e. slightly earlier). However no impact of that small difference is expected. Cc: Russell King <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 6f114281c4ad543392f5b7c8345e11e103675cee Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:08:21 2015 -0400 powerpc: don't use module_init for non-modular core hugetlb code The hugetlbpage.o is obj-y (always built in). It will never be modular, so using module_init as an alias for __initcall is 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 arch_initcall (which makes sense for arch code) will thus change this registration from level 6-device to level 3-arch (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. Cc: Benjamin Herrenschmidt <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 383d14a5365879bc193d29ad2ed17ac5299753c3 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:08:21 2015 -0400 powerpc: use subsys_initcall for Freescale Local Bus The FSL_SOC 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 subsys_initcall (which makes sense for bus code) will thus change this registration from level 6-device to level 4-subsys (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. Cc: Benjamin Herrenschmidt <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Scott Wood <[email protected]> Acked-by: Scott Wood <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 1206f53589237b7e00b9b0a4e42815f14aedad2d Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:08:21 2015 -0400 x86: don't use module_init for non-modular core bootflag code The bootflag.o is obj-y (always built in). It will never be modular, so using module_init as an alias for __initcall is 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 arch_initcall (which makes sense for arch code) will thus change this registration from level 6-device to level 3-arch (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 55331060096f0e9a57356ec36476a49e4bf22bc1 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:08:20 2015 -0400 netfilter: don't use module_init/exit in core IPV4 code The file net/ipv4/netfilter.o is created based on whether CONFIG_NETFILTER is set. However that is defined as a bool, and hence this file with the core netfilter hooks 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. Also add an inclusion of init.h, as that was previously implicit here in the netfilter.c file. 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 netfilter code) will thus change this registration from level 6-device to level 4-subsys (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. (i.e. the location of the netfilter messages in dmesg remains unchanged with respect to all the other surrounding messages.) As for the module_exit, rather than replace it with __exitcall, we simply remove it, since it appears only UML does anything with those, and even for UML, there is no relevant cleanup to be done here. Cc: Pablo Neira Ayuso <[email protected]> Acked-by: Pablo Neira Ayuso <[email protected]> Cc: Patrick McHardy <[email protected]> Cc: Jozsef Kadlecsik <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit c013d5a4581203e074a1065e17378984544fcaef Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:08:20 2015 -0400 fs/notify: don't use module_init for non-modular inotify_user code The INOTIFY_USER 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 fs_initcall (which makes sense for fs code) will thus change this registration from level 6-device to level 5-fs (i.e. slightly earlier). However no observable impact of that small difference has been observed during testing, or is expected. Cc: John McCutchan <[email protected]> Cc: Robert Love <[email protected]> Cc: Eric Paris <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit a4bc6fc79f94c5b4f850aabca9c5249adc597094 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:08:20 2015 -0400 mm: replace module_init usages with subsys_initcall in nommu.c Compiling some arm/m68k configs with "# CONFIG_MMU is not set" reveals two more instances of module_init being used for code that can't possibly be modular, as CONFIG_MMU is either on or off. We replace them with subsys_initcall as per what was done in other mmu-enabled code. 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 makes sense for these files) will thus change this registration from level 6-device to level 4-subsys (i.e. slightly earlier). One might think that core_initcall (l2) or postcore_initcall (l3) would be more appropriate for anything in mm/ but if we look at the actual init functions themselves, we see they are just sysctl setup stuff, and hence the choice of subsys_initcall (l4) seems reasonable. At the same time it minimizes the risk of changing the priority too drastically all at once. We can adjust further in the future. Also, a couple instances of missing ";" at EOL are fixed. Cc: Andrew Morton <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 84c3e5bf1defc035d63869bbb0f5f80d276c1fc7 Author: Paul Gortmaker <[email protected]> Date: Sun Jun 14 16:55:25 2015 -0400 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 <[email protected]> Cc: Jesper Nilsson <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 4d38e5c48f4095be21343869ad741676ab4e518f Author: James Hogan <[email protected]> Date: Fri Jun 5 22:17:18 2015 +0100 tty/metag_da: Avoid module_init/module_exit in non-modular code 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 <[email protected]> Tested-by: Guenter Roeck <[email protected]> Signed-off-by: James Hogan <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Jiri Slaby <[email protected]> Cc: [email protected] Cc: Paul Gortmaker <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit 791ed0bb5558dfdc4040563bd0b7dc24450fa732 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:51 2015 -0400 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 <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 30e3c6428f18b5b8e78602a5a7cc653aee3bfe99 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:50 2015 -0400 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 <[email protected]> Cc: Max Filippov <[email protected]> Cc: Thomas Meyer <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit b205118bdb4b515b4b4f5058aa9f5a12668386c3 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:50 2015 -0400 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 <[email protected]> Cc: Paul Mundt <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 1b4d5beecbeb4608a0fdb77c3b8ba182f0cfb4b6 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:50 2015 -0400 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 <[email protected]> Cc: David Howells <[email protected]> Acked-by: David Howells <[email protected]> Cc: Koichi Yasutake <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 15becabd89fa3fec6aa864fbd1b50b5b1871eee2 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:50 2015 -0400 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 <linux/init.h> 20238 arch/parisc/kernel/perf.i module_init() and <linux/module.h> 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" <[email protected]> Cc: Helge Deller <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit aed6850a1390c2b208b91b2fae0199fc14b94a26 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:50 2015 -0400 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 <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: Helge Deller <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 73de14e8cdc733bbc8eda006f813d5aa51511139 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:50 2015 -0400 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 <[email protected]> Cc: Mikael Starvik <[email protected]> Cc: Jesper Nilsson <[email protected]> Acked-by: Jesper Nilsson <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 2a177fd1d92f669f8f493a61e195ff4e3c50f95f Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:50 2015 -0400 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 <[email protected]> Cc: Fenghua Yu <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 2e21fa2d11ab61e1827bd5bb1e0e2484931d68e1 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:49 2015 -0400 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 <[email protected]> Cc: Fenghua Yu <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 4a0ece7ceceab251e92e7f98e7926642a065727b Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:49 2015 -0400 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 <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit a390a2f18147533359d4e45cb13438d42580da84 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:49 2015 -0400 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 <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 8f6b9512ceadc6bd52777c299111dc642b4c65b6 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:49 2015 -0400 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 <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Geoff Levand <[email protected]> Acked-by: Geoff Levand <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit d54b675a6b0007422dc13acbecdb1ca2b1a53aeb Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:49 2015 -0400 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 <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 4711e2f9caedaa07e7cdcb5e058a18762d6be9b1 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:05:49 2015 -0400 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 <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 7cac34370a4dde12e6430c2f0985926d4ef0f459 Author: Paul Gortmaker <[email protected]> Date: Fri Jun 5 11:25:18 2015 -0400 frv: add module.h to mb93090-mb00/flash.c to avoid compile fail This file is built off of a tristate Kconfig option and also contains modular function calls so it should explicitly include module.h to avoid compile breakage during header shuffles done in the future. Reported-by: kbuild test robot <[email protected]> Cc: David Howells <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit 743492ccd53008736f169f242479bac6245f8379 Author: Paul Gortmaker <[email protected]> Date: Wed Jun 3 15:45:21 2015 -0400 drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code This file is built off of a tristate Kconfig option ("ARM_EXYNOS_CPUFREQ") and also contains modular function calls so it should explicitly include module.h to avoid compile breakage during pending header shuffles. Cc: "Rafael J. Wysocki" <[email protected]> Cc: Viresh Kumar <[email protected]> Acked-by: Viresh Kumar <[email protected]> Cc: Kukjin Kim <[email protected]> Cc: Krzysztof Kozlowski <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit a7e9bc55cc144dc40e809e579bd932ef2ec324de Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:02:31 2015 -0400 drivers/staging: include <module.h> for modular android tegra_ion code This file is built off of a tristate Kconfig option and also contains modular function calls so it should explicitly include module.h to avoid compile breakage during header shuffles done in the future. Cc: Greg Kroah-Hartman <[email protected]> Cc: "Arve Hj�nnev�g" <[email protected]> Cc: Riley Andrews <[email protected]> Cc: Stephen Warren <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Alexandre Courbot <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 88775588b71d28a9020a7faa4ad95bbf76d8bb45 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 21:29:53 2015 -0400 crypto/asymmetric_keys: pkcs7_key_type needs module.h This driver builds off of the tristate CONFIG_PKCS7_TEST_KEY and calls module_init and module_exit. So it should explicitly include module.h to avoid compile breakage during header shuffles done in the future. Cc: Herbert Xu <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit 0bbad249a6a4934203b50d574f5d5f9f480b389e Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:02:31 2015 -0400 sh: mach-highlander/psw.c is tristate and should use module.h This file is controlled by a tristate Kconfig option, and hence needs to include module.h so that it can get module_init() once we relocate it from init.h into module.h in the future. Note that module_exit() appears to be missing from the driver, so it is questionable whether it would actually work for a removal and reload cycle if it was configured for a modular build. Cc: Paul Mundt <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit ca1c8e93c37e5a5e27e6149cd3612eb2247e0e4a Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:02:31 2015 -0400 drivers/regulator: include <module.h> for modular max77802 code This file is built off of a tristate Kconfig option and also contains modular function calls so it should explicitly include module.h to avoid compile breakage during header shuffles done in the future. Cc: Liam Girdwood <[email protected]> Cc: Mark Brown <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit 5468f887bc861b2fe2fa24a44bc6a616a5d33a73 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:02:31 2015 -0400 drivers/pcmcia: include <module.h> for modular xxs1500_ss code This file is built off of a tristate Kconfig option and also contains modular function calls so it should explicitly include module.h to avoid compile breakage during header shuffles done in the future. Cc: Wolfram Sang <[email protected]> Acked-by: Wolfram Sang <[email protected]> Cc: [email protected] Signed-off-by: Paul Gortmaker <[email protected]> commit a1a0bec593623f49740d7900e4b862c534f219bf Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:02:30 2015 -0400 drivers/hsi: include <module.h> for modular omap_ssi code These files are built off of a tristate Kconfig option and also contain modular function calls so they should explicitly include module.h to avoid compile breakage during header shuffles done in the future. We change the one header file wich gives us coverage on both files: drivers/hsi/controllers/omap_ssi.c drivers/hsi/controllers/omap_ssi_port.c Cc: Sebastian Reichel <[email protected]> Signed-off-by: Paul Gortmaker <[email protected]> commit 00fe614863eed7ca39fc72a307c6dff57b690476 Author: Paul Gortmaker <[email protected]> Date: Fri May 1 20:02:30 2015 -0400 drivers/gpu: in…
- Loading branch information
