Fix implicit includes of <module.h> that will break.
Subsystems (23)
cover Fix implicit includes of <module.h> that will break.
The files changed here are simply modular source files that are implicitly relying on <module.h> being present. We fix them up now, so that we can decouple some of the module related init code from the core init code in another pending series.
This is the second series; a pseudo followup to the 1st series[1] factored out from what was a previously larger series[2] so that there is a common theme and lower patch count to ease review.
In this case the addition of module.h include to several files is the common theme, and it is a no-op from a code generation point of view, and even from a compile point of view at this point in time.
There are probably lots more implicit includes of <module.h> in tree, but these are the ones that must be fixed in order to avoid build breakage fallout for the pending module.h <---> init.h code relocations.
Paul.
[1] https://lkml.org/lkml/2015/4/27/777
[2] https://marc.info/?l=linux-kernel&m=139033951228828
---
Paul Gortmaker (11):
drivers/crypto: include <module.h> for modular caam code drivers/clk: include <module.h> for clk-max77xxx modular code drivers/gpio: include <module.h> for modular crystalcove code drivers/gpu: include <module.h> for modular rockchip code drivers/hsi: include <module.h> for modular omap_ssi code drivers/net: include <module.h> for modular stmmac_platform code drivers/pcmcia: include <module.h> for modular xxs1500_ss code drivers/pcmcia: include <module.h> for modular max77802 code drivers/scsi: include <module.h> for modular ufshcd-pltfrm code drivers/staging: include <module.h> for modular android tegra_ion code
sh: mach-highlander/psw.c is tristate and should use module.h
arch/sh/boards/mach-highlander/psw.c | 2 +- drivers/clk/clk-max77686.c | 1 + drivers/clk/clk-max77802.c | 1 + drivers/crypto/caam/ctrl.c | 1 + drivers/gpio/gpio-crystalcove.c | 1 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 + drivers/hsi/controllers/omap_ssi.h | 1 + drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 + drivers/pcmcia/xxs1500_ss.c | 1 + drivers/regulator/max77802.c | 1 + drivers/scsi/ufs/ufshcd-pltfrm.c | 1 + drivers/staging/android/ion/tegra/tegra_ion.c | 1 + 13 files changed, 13 insertions(+), 1 deletion(-)
Signature · 1 line
2.2.1
PATCH 1/11 drivers/crypto: include <module.h> for modular caam 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.
--- drivers/crypto/caam/ctrl.c | 1 + 1 file changed, 1 insertion(+)
drivers/crypto/caam/ctrl.c +1 -0
@@ -5,6 +5,7 @@*/ #include <linux/device.h> +#include <linux/module.h> #include <linux/of_address.h> #include <linux/of_irq.h>
Signature · 1 line
2.2.1
Herbert Xu
maintainerRe: [PATCH 01/11] drivers/crypto: include <module.h> for modular caam code
Quoted 7 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.Cc Herbert Xu <[email protected]>Cc "David S. Miller" <[email protected]>Signed-off-by Paul Gortmaker <[email protected]>
Please post patches to [email protected] if you want them to go through the crypto tree.
Also it actually gets module.h through caam/compat.h. So your patch is unnecessary.
Cheers,
Signature · 3 lines
Email: Herbert Xu <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 01/11] drivers/crypto: include <module.h> for modular caam code
Quoted 11 lines · Herbert Xu
Quoted 7 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.Cc Herbert Xu <[email protected]>Cc "David S. Miller" <[email protected]>Signed-off-by Paul Gortmaker <[email protected]>Please post patches to [email protected] if you want them to go through the crypto tree.
Sure, I will add a CC for that in v2 if the patch is needed.
Quoted 3 lines
Also it actually gets
module.hthroughcaam/compat.h. So your patch is unnecessary.
Well, in my original build testing this file failed to compile once the modular code was moved from init.h to module.h as per the description in the 0/11.
Perhaps since that testing something else has changed. I will drop this patch and retest and if it no longer fails, then great.
Thanks,
Paul.
--
Quoted 3 lines
Cheers,
PATCH 2/11 drivers/clk: include <module.h> for clk-max77xxx modular code
In reply to Paul GortmakerThese files are built off of the tristate COMMON_CLK_MAX77686 and COMMON_CLK_MAX77802 respectively. They also contains modular function calls so they should explicitly include module.h to avoid compile breakage during header shuffles done in the future.
--- drivers/clk/clk-max77686.c | 1 + drivers/clk/clk-max77802.c | 1 + 2 files changed, 2 insertions(+)
drivers/clk/clk-max77686.c +1 -0
@@ -23,6 +23,7 @@#include <linux/kernel.h> #include <linux/slab.h> #include <linux/err.h> +#include <linux/module.h> #include <linux/platform_device.h> #include <linux/mfd/max77686.h> #include <linux/mfd/max77686-private.h>
drivers/clk/clk-max77802.c +1 -0
@@ -22,6 +22,7 @@#include <linux/kernel.h> #include <linux/slab.h> #include <linux/err.h> +#include <linux/module.h> #include <linux/platform_device.h> #include <linux/mfd/max77686-private.h> #include <linux/clk-provider.h>
Signature · 1 line
2.2.1
Re: [PATCH 02/11] drivers/clk: include <module.h> for clk-max77xxx modular code
Quoted 8 lines · Paul Gortmaker
These files are built off of the tristate
COMMON_CLK_MAX77686andCOMMON_CLK_MAX77802respectively. They also contains modular function calls so they should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.Cc Mike Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Signed-off-by Paul Gortmaker <[email protected]>
I assume you're taking this through some larger series?
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 02/11] drivers/clk: include <module.h> for clk-max77xxx modular code
Quoted 11 lines · [Re: [PATCH 02/11] drivers/clk: include <module.h> for clk-max77xxx modular…
Quoted 8 lines · Paul Gortmaker
These files are built off of the tristate
COMMON_CLK_MAX77686andCOMMON_CLK_MAX77802respectively. They also contains modular function calls so they should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.Cc Mike Turquette <[email protected]>Cc Stephen Boyd <[email protected]>Signed-off-by Paul Gortmaker <[email protected]>I assume you're taking this through some larger series?
Yep, there will be several series fed to Linus once I'm done here.
It is basically a refactoring of this series into more manageable chunks:
https://marc.info/?l=linux-kernel&m=139033951228828
Thanks,
Paul.
--
Quoted 7 lines
Acked-by Stephen Boyd <[email protected]>Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
PATCH 3/11 drivers/gpio: include <module.h> for modular crystalcove code
In reply to Paul GortmakerThis 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.
--- drivers/gpio/gpio-crystalcove.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpio/gpio-crystalcove.c +1 -0
@@ -16,6 +16,7 @@*/ #include <linux/interrupt.h> +#include <linux/module.h> #include <linux/platform_device.h> #include <linux/gpio.h> #include <linux/seq_file.h>
Signature · 1 line
2.2.1
Re: [PATCH 03/11] drivers/gpio: include <module.h> for modular crystalcove code
Quoted 8 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.Cc Linus Walleij <[email protected]>Cc Alexandre Courbot <[email protected]>Signed-off-by Paul Gortmaker <[email protected]>
Patch applied.
Yours,
Linus Walleij
PATCH 4/11 drivers/gpu: include <module.h> for modular rockchip code
In reply to Paul GortmakerThese 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.
--- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 + 2 files changed, 2 insertions(+)
drivers/gpu/drm/rockchip/rockchip_drm_drv.c +1 -0
@@ -21,6 +21,7 @@#include <drm/drm_fb_helper.h> #include <linux/dma-mapping.h> #include <linux/pm_runtime.h> +#include <linux/module.h> #include <linux/of_graph.h> #include <linux/component.h>
drivers/gpu/drm/rockchip/rockchip_drm_vop.c +1 -0
@@ -19,6 +19,7 @@#include <drm/drm_plane_helper.h> #include <linux/kernel.h> +#include <linux/module.h> #include <linux/platform_device.h> #include <linux/clk.h> #include <linux/of.h>
Signature · 1 line
2.2.1
PATCH 5/11 drivers/hsi: include <module.h> for modular omap_ssi code
In reply to Paul GortmakerThese 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
--- drivers/hsi/controllers/omap_ssi.h | 1 + 1 file changed, 1 insertion(+)
drivers/hsi/controllers/omap_ssi.h +1 -0
@@ -24,6 +24,7 @@#define __LINUX_HSI_OMAP_SSI_H__#include <linux/device.h> +#include <linux/module.h> #include <linux/platform_device.h> #include <linux/hsi/hsi.h> #include <linux/gpio.h>
Signature · 1 line
2.2.1
PATCH 6/11 drivers/net: include <module.h> for modular stmmac_platform code
In reply to Paul GortmakerThis 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.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c +1 -0
@@ -23,6 +23,7 @@*******************************************************************************/ #include <linux/platform_device.h> +#include <linux/module.h> #include <linux/io.h> #include <linux/of.h> #include <linux/of_net.h>
Signature · 1 line
2.2.1
Re: [PATCH 06/11] drivers/net: include <module.h> for modular stmmac_platform code
From: Paul Gortmaker <[email protected]>
Date: Thu, 30 Apr 2015 21:47:42 -0400
Quoted 7 lines
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.Cc Giuseppe Cavallaro <[email protected]>Signed-off-by Paul Gortmaker <[email protected]>
Applied, thanks Paul.
PATCH 7/11 drivers/pcmcia: include <module.h> for modular xxs1500_ss code
In reply to Paul GortmakerThis 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.
--- drivers/pcmcia/xxs1500_ss.c | 1 + 1 file changed, 1 insertion(+)
drivers/pcmcia/xxs1500_ss.c +1 -0
@@ -11,6 +11,7 @@#include <linux/io.h> #include <linux/ioport.h> #include <linux/mm.h> +#include <linux/module.h> #include <linux/platform_device.h> #include <linux/pm.h> #include <linux/resource.h>
Signature · 1 line
2.2.1
Re: [PATCH 07/11] drivers/pcmcia: include <module.h> for modular xxs1500_ss code
Quoted 7 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.Cc Wolfram Sang <[email protected]>Signed-off-by Paul Gortmaker <[email protected]>
PATCH 8/11 drivers/pcmcia: include <module.h> for modular max77802 code
In reply to Paul GortmakerThis 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.
--- drivers/regulator/max77802.c | 1 + 1 file changed, 1 insertion(+)
drivers/regulator/max77802.c +1 -0
@@ -27,6 +27,7 @@#include <linux/gpio.h> #include <linux/slab.h> #include <linux/gpio/consumer.h> +#include <linux/module.h> #include <linux/platform_device.h> #include <linux/regulator/driver.h> #include <linux/regulator/machine.h>
Signature · 1 line
2.2.1
Mark Brown
maintainerRe: [PATCH 08/11] drivers/pcmcia: include <module.h> for modular max77802 code
Quoted 3 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.
Why are you sending me PCMCIA patches?
Re: [PATCH 08/11] drivers/pcmcia: include <module.h> for modular max77802 code
Quoted 6 lines · Mark Brown
Quoted 3 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.Why are you sending me PCMCIA patches?
It isn't a PCMCIA patch:
$ ./scripts/get_maintainer.pl -f drivers/regulator/max77802.c Liam Girdwood <[email protected]> (supporter:VOLTAGE AND CURRE...) Mark Brown <[email protected]> (supporter:VOLTAGE AND CURRE...) [email protected] (open list:VOLTAGE AND CURRE...)
I borrowed the commit log from 7/11 for this 8/11 and missed changing PCMCIA to regulator. Will fix.
Thanks for spotting it.
Paul.
Mark Brown
maintainerRe: [PATCH 08/11] drivers/pcmcia: include <module.h> for modular max77802 code
Quoted 6 lines · Paul Gortmaker
Quoted 1 line · Mark Brown
Why are you sending me PCMCIA patches?
It isn't a PCMCIA patch:
Quoted 7 lines
$ ./scripts/get_maintainer.pl -f drivers/regulator/max77802.c Liam Girdwood <[email protected]> (supporter:VOLTAGE AND CURRE...) Mark Brown <[email protected]> (supporter:VOLTAGE AND CURRE...) [email protected] (open list:VOLTAGE AND CURRE...)I borrowed the commit log from 7/11 for this 8/11 and missed changing PCMCIA to regulator. Will fix.
Ah, OK - I didn't get as far as reading beyond the header and commit message (I nearly didn't open the mail enough to see the commit message).
PATCH 9/11 drivers/scsi: include <module.h> for modular ufshcd-pltfrm code
In reply to Paul GortmakerThis 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.
--- drivers/scsi/ufs/ufshcd-pltfrm.c | 1 + 1 file changed, 1 insertion(+)
drivers/scsi/ufs/ufshcd-pltfrm.c +1 -0
@@ -33,6 +33,7 @@* this program. */ +#include <linux/module.h> #include <linux/platform_device.h> #include <linux/pm_runtime.h> #include <linux/of.h>
Signature · 1 line
2.2.1
James Bottomley
maintainerRe: [PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code
Quoted 3 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.
I don't understand your logic. The ufs code made a design choice to consolidate most headers for the hcd code in a local include (ufshcd.h), which includes module.h, so why would they explicitly need it here as well? And if we follow your logic, why wouldn't they also need to duplicate everything else (like the scsi includes)?
James
Re: [PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code
Quoted 10 lines · James Bottomley
Quoted 3 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.I don't understand your logic. The ufs code made a design choice to consolidate most headers for the hcd code in a local include (
ufshcd.h), which includesmodule.h, so why would they explicitly need it here as well? And if we follow your logic, why wouldn't they also need to duplicate everything else (like the scsi includes)?
In my original build testing this file failed to compile once the modular code was moved from init.h to module.h as per the description in the 0/11.
Perhaps since that testing something else has changed. I will drop this patch and retest and if it no longer fails, then great.
Paul.
--
Quoted 4 lines
James
James Bottomley
maintainerRe: [PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code
Quoted 12 lines · Paul Gortmaker
Quoted 10 lines · James Bottomley
Quoted 3 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during header shuffles done in the future.I don't understand your logic. The ufs code made a design choice to consolidate most headers for the hcd code in a local include (
ufshcd.h), which includesmodule.h, so why would they explicitly need it here as well? And if we follow your logic, why wouldn't they also need to duplicate everything else (like the scsi includes)?
Quoted 3 lines
In my original build testing this file failed to compile once the modular code was moved from
init.htomodule.has per the description in the 0/11.
Just as a point of principle, you didn't send the 0/11 patch, so I only have this one to go by.
Quoted 2 lines
Perhaps since that testing something else has changed. I will drop this patch and retest and if it no longer fails, then great.
Sounds good.
James
PATCH 10/11 drivers/staging: include <module.h> for modular android tegra_ion code
In reply to Paul GortmakerThis 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.
--- drivers/staging/android/ion/tegra/tegra_ion.c | 1 + 1 file changed, 1 insertion(+)
drivers/staging/android/ion/tegra/tegra_ion.c +1 -0
@@ -15,6 +15,7 @@*/ #include <linux/err.h> +#include <linux/module.h> #include <linux/platform_device.h> #include <linux/slab.h> #include "../ion.h"
Signature · 1 line
2.2.1
PATCH 11/11 sh: mach-highlander/psw.c is tristate and should use module.h
In reply to Paul GortmakerThis 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.
--- arch/sh/boards/mach-highlander/psw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/sh/boards/mach-highlander/psw.c +1 -1
@@ -10,7 +10,7 @@* for more details. */ #include <linux/io.h> -#include <linux/init.h> +#include <linux/module.h> #include <linux/interrupt.h> #include <linux/platform_device.h> #include <mach/highlander.h>
Signature · 1 line
2.2.1
PATCH 1/1 drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
In reply to Paul GortmakerThis 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.
---
[ patch will be appended to the implicit include fixup series, see:
https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker at windriver.com for the original series posting.]
drivers/cpufreq/exynos-cpufreq.c | 1 + 1 file changed, 1 insertion(+)
drivers/cpufreq/exynos-cpufreq.c +1 -0
@@ -10,6 +10,7 @@*/ #include <linux/kernel.h> +#include <linux/module.h> #include <linux/err.h> #include <linux/clk.h> #include <linux/io.h>
Signature · 1 line
2.2.1
Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
Quoted 4 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption ("ARM_EXYNOS_CPUFREQ") and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during pending header shuffles.
Quoted 8 lines
Cc "Rafael J. Wysocki" <[email protected]>Cc Viresh Kumar <[email protected]>Cc Kukjin Kim <[email protected]>Cc Krzysztof Kozlowski <[email protected]>Cc linux-pm at vger.kernel.orgCc linux-arm-kernel at lists.infradead.orgCc linux-samsung-soc at vger.kernel.orgSigned-off-by Paul Gortmaker <[email protected]>
Best regards,
Krzysztof
Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
In reply to Paul GortmakerQuoted 26 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption ("ARM_EXYNOS_CPUFREQ") and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during pending header shuffles.Cc "Rafael J. Wysocki" <[email protected]>Cc Viresh Kumar <[email protected]>Cc Kukjin Kim <[email protected]>Cc Krzysztof Kozlowski <[email protected]>Cc linux-pm at vger.kernel.orgCc linux-arm-kernel at lists.infradead.orgCc linux-samsung-soc at vger.kernel.orgSigned-off-by Paul Gortmaker <[email protected]>---
[ patch will be appended to the implicit include fixup series, see:
https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker at windriver.com for the original series posting.]drivers/cpufreq/exynos-cpufreq.c | 1 + 1 file changed, 1 insertion(+)drivers/cpufreq/exynos-cpufreq.c +0
-0
drivers/cpufreq/exynos-cpufreq.c line 16
Quoted 7 lines
drivers/cpufreq/exynos-cpufreq.c +1
-0@@ -10,6 +10,7 @@*/ #include <linux/kernel.h> +#include <linux/module.h> #include <linux/err.h> #include <linux/clk.h> #include <linux/io.h>
Signature · 1 line
viresh
Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
In reply to Paul GortmakerQuoted 4 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption ("ARM_EXYNOS_CPUFREQ") and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during pending header shuffles.
Quoted 8 lines
Cc "Rafael J. Wysocki" <[email protected]>Cc Viresh Kumar <[email protected]>Cc Kukjin Kim <[email protected]>Cc Krzysztof Kozlowski <[email protected]>Signed-off-by Paul Gortmaker <[email protected]>
I'm assuming that this will go in via the Samsung tree.
Quoted 22 lines
---
[ patch will be appended to the implicit include fixup series, see:
https://lkml.kernel.org/r/[email protected]
for the original series posting.]drivers/cpufreq/exynos-cpufreq.c | 1 + 1 file changed, 1 insertion(+)drivers/cpufreq/exynos-cpufreq.c +1
-0@@ -10,6 +10,7 @@*/ #include <linux/kernel.h> +#include <linux/module.h> #include <linux/err.h> #include <linux/clk.h> #include <linux/io.h>
Signature · 2 lines
I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.
Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
Quoted 14 lines · Rafael J. Wysocki
Quoted 4 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption ("ARM_EXYNOS_CPUFREQ") and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during pending header shuffles.Quoted 8 lines
Cc "Rafael J. Wysocki" <[email protected]>Cc Viresh Kumar <[email protected]>Cc Kukjin Kim <[email protected]>Cc Krzysztof Kozlowski <[email protected]>Cc linux-pm at vger.kernel.orgCc linux-arm-kernel at lists.infradead.orgCc linux-samsung-soc at vger.kernel.orgSigned-off-by Paul Gortmaker <[email protected]>
Quoted 8 lines
I'm assuming that this will go in via the Samsung tree.
Quoted 5 lines
---
[ patch will be appended to the implicit include fixup series, see:
https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker at windriver.com for the original series posting.]
Paul, will you handle the patch or should it go through Samsung tree?
Best regards,
Krzysztof
Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
Quoted 18 lines · Krzysztof Kozlowski
Quoted 17 lines · Rafael J. Wysocki
Quoted 4 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption ("ARM_EXYNOS_CPUFREQ") and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during pending header shuffles.Quoted 8 lines
Cc "Rafael J. Wysocki" <[email protected]>Cc Viresh Kumar <[email protected]>Cc Kukjin Kim <[email protected]>Cc Krzysztof Kozlowski <[email protected]>Cc linux-pm at vger.kernel.orgCc linux-arm-kernel at lists.infradead.orgCc linux-samsung-soc at vger.kernel.orgSigned-off-by Paul Gortmaker <[email protected]>I'm assuming that this will go in via the Samsung tree.
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
---
[ patch will be appended to the implicit include fixup series, see:
https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker at windriver.com for the original series posting.]Paul, will you handle the patch or should it go through Samsung tree?
My fault for not explicitly stating the obvious... If I don't keep the patch locally (or at least a version of it) then we can introduce a compile bisection fail. So I will keep all patches locally unless there is a rebase where I can (also) rebase and drop said pach since it has become common history of the shared baseline...
Paul.
--
Quoted 8 lines
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
In reply to Krzysztof KozlowskiQuoted 18 lines · Krzysztof Kozlowski
Quoted 17 lines · Rafael J. Wysocki
Quoted 4 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption ("ARM_EXYNOS_CPUFREQ") and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during pending header shuffles.Quoted 8 lines
Cc "Rafael J. Wysocki" <[email protected]>Cc Viresh Kumar <[email protected]>Cc Kukjin Kim <[email protected]>Cc Krzysztof Kozlowski <[email protected]>Cc linux-pm at vger.kernel.orgCc linux-arm-kernel at lists.infradead.orgCc linux-samsung-soc at vger.kernel.orgSigned-off-by Paul Gortmaker <[email protected]>I'm assuming that this will go in via the Samsung tree.
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
---
[ patch will be appended to the implicit include fixup series, see:
https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker at windriver.com for the original series posting.]Paul, will you handle the patch or should it go through Samsung tree?
I have to keep a copy of the patch in the above series, since if I don't then we'll introduce build failures into the bisection history, so yes I'll handle it.
Thanks,
Paul.
--
Quoted 4 lines
Best regards,
Krzysztof
Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code
Quoted 25 lines · Paul Gortmaker
Quoted 24 lines · Krzysztof Kozlowski
Quoted 22 lines · Rafael J. Wysocki
Quoted 4 lines · Paul Gortmaker
This file is built off of a tristate
Kconfigoption ("ARM_EXYNOS_CPUFREQ") and also contains modular function calls so it should explicitly includemodule.hto avoid compile breakage during pending header shuffles.Quoted 8 lines
Cc "Rafael J. Wysocki" <[email protected]>Cc Viresh Kumar <[email protected]>Cc Kukjin Kim <[email protected]>Cc Krzysztof Kozlowski <[email protected]>Cc linux-pm at vger.kernel.orgCc linux-arm-kernel at lists.infradead.orgCc linux-samsung-soc at vger.kernel.orgSigned-off-by Paul Gortmaker <[email protected]>I'm assuming that this will go in via the Samsung tree.
Quoted 5 lines
---
[ patch will be appended to the implicit include fixup series, see:
https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker at windriver.com for the original series posting.]
Quoted 6 lines
Quoted 1 line
Paul, will you handle the patch or should it go through Samsung tree?
I have to keep a copy of the patch in the above series, since if I don't then we'll introduce build failures into the bisection history, so yes I'll handle it.
Thank you, I'll leave the patch for you to handle.
Best regards,
Krzysztof