[PATCH 00/11] Fix implicit includes of <module.h> that will break.

[PATCH 00/11] Fix implicit includes of <module.h> that will break.

[Paul Gortmaker]

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(-)

-- 
2.2.1

[PATCH 01/11] drivers/crypto: include <module.h> for modular caam code

[Paul Gortmaker]

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: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/crypto/caam/ctrl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index efba4ccd4fac..b9ad19df372d 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -5,6 +5,7 @@
  */
 
 #include <linux/device.h>
+#include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 
-- 
2.2.1

Re: [PATCH 01/11] drivers/crypto: include <module.h> for modular caam code

[Herbert Xu]

On Thu, Apr 30, 2015 at 09:47:37PM -0400, Paul Gortmaker wrote:
> 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: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Please post patches to linux-crypto@vger.kernel.org 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,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
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

[Paul Gortmaker]

On 15-04-30 11:24 PM, Herbert Xu wrote:
> On Thu, Apr 30, 2015 at 09:47:37PM -0400, Paul Gortmaker wrote:
>> 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: Herbert Xu <herbert@gondor.apana.org.au>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> 
> Please post patches to linux-crypto@vger.kernel.org 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.

> 
> Also it actually gets module.h through caam/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.
--

> 
> Cheers,
> 

[PATCH 02/11] drivers/clk: include <module.h> for clk-max77xxx modular code

[Paul Gortmaker]

These 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.

Cc: Mike Turquette <mturquette@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/clk/clk-max77686.c | 1 +
 drivers/clk/clk-max77802.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
index 86cdb3a28629..446c2fe76dc2 100644
--- a/drivers/clk/clk-max77686.c
+++ b/drivers/clk/clk-max77686.c
@@ -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>
diff --git a/drivers/clk/clk-max77802.c b/drivers/clk/clk-max77802.c
index 0729dc723a8f..74c49b93a6eb 100644
--- a/drivers/clk/clk-max77802.c
+++ b/drivers/clk/clk-max77802.c
@@ -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>
-- 
2.2.1

Re: [PATCH 02/11] drivers/clk: include <module.h> for clk-max77xxx modular code

[Stephen Boyd]

On 04/30/15 18:47, Paul Gortmaker wrote:
> These 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.
>
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

I assume you're taking this through some larger series?

Acked-by: Stephen Boyd <sboyd@codeaurora.org>

-- 
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

[Paul Gortmaker]

[Re: [PATCH 02/11] drivers/clk: include <module.h> for clk-max77xxx modular code] On 01/05/2015 (Fri 14:37) Stephen Boyd wrote:

> On 04/30/15 18:47, Paul Gortmaker wrote:
> > These 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.
> >
> > Cc: Mike Turquette <mturquette@linaro.org>
> > Cc: Stephen Boyd <sboyd@codeaurora.org>
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> 
> 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.
--

> 
> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

[PATCH 03/11] drivers/gpio: include <module.h> for modular crystalcove code

[Paul Gortmaker]

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: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/gpio/gpio-crystalcove.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
index 91a7ffe83135..cf28ec525e93 100644
--- a/drivers/gpio/gpio-crystalcove.c
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -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>
-- 
2.2.1

Re: [PATCH 03/11] drivers/gpio: include <module.h> for modular crystalcove code

[Linus Walleij]

On Fri, May 1, 2015 at 3:47 AM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:

> 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: Linus Walleij <linus.walleij@linaro.org>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: linux-gpio@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Patch applied.

Yours,
Linus Walleij

[PATCH 04/11] drivers/gpu: include <module.h> for modular rockchip code

[Paul Gortmaker]

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.

Cc: David Airlie <airlied@linux.ie>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 3962176ee713..01b558fe3695 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -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>
 
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index ccb0ce073ef2..38155215efcd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -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>
-- 
2.2.1

[PATCH 05/11] drivers/hsi: include <module.h> for modular omap_ssi code

[Paul Gortmaker]

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 <sre@kernel.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/hsi/controllers/omap_ssi.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hsi/controllers/omap_ssi.h b/drivers/hsi/controllers/omap_ssi.h
index 9d056417d88c..f9aaf37262be 100644
--- a/drivers/hsi/controllers/omap_ssi.h
+++ b/drivers/hsi/controllers/omap_ssi.h
@@ -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>
-- 
2.2.1

[PATCH 06/11] drivers/net: include <module.h> for modular stmmac_platform code

[Paul Gortmaker]

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: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 705bbdf93940..68aec5c460db 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -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>
-- 
2.2.1

Re: [PATCH 06/11] drivers/net: include <module.h> for modular stmmac_platform code

[David Miller]

From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 30 Apr 2015 21:47:42 -0400

> 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: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Applied, thanks Paul.

[PATCH 07/11] drivers/pcmcia: include <module.h> for modular xxs1500_ss code

[Paul Gortmaker]

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 <wsa@the-dreams.de>
Cc: linux-pcmcia@lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/pcmcia/xxs1500_ss.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pcmcia/xxs1500_ss.c b/drivers/pcmcia/xxs1500_ss.c
index 4c04360f378b..b2a189507fc3 100644
--- a/drivers/pcmcia/xxs1500_ss.c
+++ b/drivers/pcmcia/xxs1500_ss.c
@@ -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>
-- 
2.2.1

Re: [PATCH 07/11] drivers/pcmcia: include <module.h> for modular xxs1500_ss code

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

On Thu, Apr 30, 2015 at 09:47:43PM -0400, Paul Gortmaker wrote:
> 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 <wsa@the-dreams.de>
> Cc: linux-pcmcia@lists.infradead.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Acked-by: Wolfram Sang <wsa@the-dreams.de>


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 08/11] drivers/pcmcia: include <module.h> for modular max77802 code

[Paul Gortmaker]

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 <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/regulator/max77802.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 6af41abccacb..c07ee13bd470 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -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>
-- 
2.2.1

Re: [PATCH 08/11] drivers/pcmcia: include <module.h> for modular max77802 code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

On Thu, Apr 30, 2015 at 09:47:44PM -0400, Paul Gortmaker wrote:
> 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.

Why are you sending me PCMCIA patches?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 08/11] drivers/pcmcia: include <module.h> for modular max77802 code

[Paul Gortmaker]

On 15-05-01 06:11 AM, Mark Brown wrote:
> On Thu, Apr 30, 2015 at 09:47:44PM -0400, Paul Gortmaker wrote:
>> 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.
> 
> Why are you sending me PCMCIA patches?

It isn't a PCMCIA patch:

$ ./scripts/get_maintainer.pl -f drivers/regulator/max77802.c
Liam Girdwood <lgirdwood@gmail.com> (supporter:VOLTAGE AND CURRE...)
Mark Brown <broonie@kernel.org> (supporter:VOLTAGE AND CURRE...)
linux-kernel@vger.kernel.org (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.

Re: [PATCH 08/11] drivers/pcmcia: include <module.h> for modular max77802 code

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Fri, May 01, 2015 at 09:34:34AM -0400, Paul Gortmaker wrote:
> On 15-05-01 06:11 AM, Mark Brown wrote:

> > Why are you sending me PCMCIA patches?

> It isn't a PCMCIA patch:

> $ ./scripts/get_maintainer.pl -f drivers/regulator/max77802.c
> Liam Girdwood <lgirdwood@gmail.com> (supporter:VOLTAGE AND CURRE...)
> Mark Brown <broonie@kernel.org> (supporter:VOLTAGE AND CURRE...)
> linux-kernel@vger.kernel.org (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).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code

[Paul Gortmaker]

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: Vinayak Holikatti <vinholikatti@gmail.com>
Cc: "James E.J. Bottomley" <JBottomley@parallels.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/scsi/ufs/ufshcd-pltfrm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index 7db9564f507d..1c0bac8a7e4a 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -33,6 +33,7 @@
  * this program.
  */
 
+#include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/of.h>
-- 
2.2.1

Re: [PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code

[James Bottomley]

On Thu, 2015-04-30 at 21:47 -0400, Paul Gortmaker wrote:
> 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.

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

[Paul Gortmaker]

On 15-04-30 10:35 PM, James Bottomley wrote:
> On Thu, 2015-04-30 at 21:47 -0400, Paul Gortmaker wrote:
>> 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.
> 
> 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)?

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.
--

> 
> James
> 
> 

Re: [PATCH 09/11] drivers/scsi: include <module.h> for modular ufshcd-pltfrm code

[James Bottomley]

On Fri, 2015-05-01 at 09:37 -0400, Paul Gortmaker wrote:
> On 15-04-30 10:35 PM, James Bottomley wrote:
> > On Thu, 2015-04-30 at 21:47 -0400, Paul Gortmaker wrote:
> >> 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.
> > 
> > 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)?
> 
> 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.

Just as a point of principle, you didn't send the 0/11 patch, so I only
have this one to go by.

> 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

[Paul Gortmaker]

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 <gregkh@linuxfoundation.org>
Cc: "Arve Hj�nnev�g" <arve@android.com>
Cc: Riley Andrews <riandrews@android.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: devel@driverdev.osuosl.org
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 drivers/staging/android/ion/tegra/tegra_ion.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/android/ion/tegra/tegra_ion.c b/drivers/staging/android/ion/tegra/tegra_ion.c
index 5b8ef0e66010..4d3c516cc15e 100644
--- a/drivers/staging/android/ion/tegra/tegra_ion.c
+++ b/drivers/staging/android/ion/tegra/tegra_ion.c
@@ -15,6 +15,7 @@
  */
 
 #include <linux/err.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/slab.h>
 #include "../ion.h"
-- 
2.2.1

[PATCH 11/11] sh: mach-highlander/psw.c is tristate and should use module.h

[Paul Gortmaker]

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 <lethal@linux-sh.org>
Cc: linux-sh@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 arch/sh/boards/mach-highlander/psw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/boards/mach-highlander/psw.c b/arch/sh/boards/mach-highlander/psw.c
index 522786318d36..40e2b585d488 100644
--- a/arch/sh/boards/mach-highlander/psw.c
+++ b/arch/sh/boards/mach-highlander/psw.c
@@ -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>
-- 
2.2.1

[PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code

[Paul Gortmaker]

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" <rjw@rjwysocki.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Kukjin Kim <kgene@kernel.org>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---

[ patch will be appended to the implicit include fixup series, see:
  https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker@windriver.com
  for the original series posting.]

 drivers/cpufreq/exynos-cpufreq.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 82d2fbb20f7e..4c157302365f 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -10,6 +10,7 @@
 */
 
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/err.h>
 #include <linux/clk.h>
 #include <linux/io.h>
-- 
2.2.1

Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code

[Krzysztof Kozlowski]

On 04.06.2015 06:18, Paul Gortmaker wrote:
> 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" <rjw@rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

Best regards,
Krzysztof

Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code

[Viresh Kumar]

On 03-06-15, 17:18, Paul Gortmaker wrote:
> 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" <rjw@rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> 
> [ patch will be appended to the implicit include fixup series, see:
>   https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker@windriver.com
>   for the original series posting.]
> 
>  drivers/cpufreq/exynos-cpufreq.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
> index 82d2fbb20f7e..4c157302365f 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -10,6 +10,7 @@
>  */
>  
>  #include <linux/kernel.h>
> +#include <linux/module.h>
>  #include <linux/err.h>
>  #include <linux/clk.h>
>  #include <linux/io.h>

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

-- 
viresh

Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code

[Rafael J. Wysocki]

On Wednesday, June 03, 2015 05:18:18 PM Paul Gortmaker wrote:
> 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" <rjw@rjwysocki.net>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Kukjin Kim <kgene@kernel.org>
> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Cc: linux-pm@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>

I'm assuming that this will go in via the Samsung tree.


> ---
> 
> [ patch will be appended to the implicit include fixup series, see:
>   https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker@windriver.com
>   for the original series posting.]
> 
>  drivers/cpufreq/exynos-cpufreq.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
> index 82d2fbb20f7e..4c157302365f 100644
> --- a/drivers/cpufreq/exynos-cpufreq.c
> +++ b/drivers/cpufreq/exynos-cpufreq.c
> @@ -10,6 +10,7 @@
>  */
>  
>  #include <linux/kernel.h>
> +#include <linux/module.h>
>  #include <linux/err.h>
>  #include <linux/clk.h>
>  #include <linux/io.h>
> 

-- 
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

[Krzysztof Kozlowski]

On 16.06.2015 08:47, Rafael J. Wysocki wrote:
> On Wednesday, June 03, 2015 05:18:18 PM Paul Gortmaker wrote:
>> 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" <rjw@rjwysocki.net>
>> Cc: Viresh Kumar <viresh.kumar@linaro.org>
>> Cc: Kukjin Kim <kgene@kernel.org>
>> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>> Cc: linux-pm@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-samsung-soc@vger.kernel.org
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> 
> I'm assuming that this will go in via the Samsung tree.
> 
> 
>> ---
>>
>> [ patch will be appended to the implicit include fixup series, see:
>>   https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker@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

[Paul Gortmaker]

On Mon, Jun 15, 2015 at 7:53 PM, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> On 16.06.2015 08:47, Rafael J. Wysocki wrote:
>> On Wednesday, June 03, 2015 05:18:18 PM Paul Gortmaker wrote:
>>> 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" <rjw@rjwysocki.net>
>>> Cc: Viresh Kumar <viresh.kumar@linaro.org>
>>> Cc: Kukjin Kim <kgene@kernel.org>
>>> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>> Cc: linux-pm@vger.kernel.org
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-samsung-soc@vger.kernel.org
>>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>
>> I'm assuming that this will go in via the Samsung tree.
>>
>>
>>> ---
>>>
>>> [ patch will be appended to the implicit include fixup series, see:
>>>   https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker@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.
--

>
> Best regards,
> Krzysztof
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@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

[Paul Gortmaker]

On 15-06-15 07:53 PM, Krzysztof Kozlowski wrote:
> On 16.06.2015 08:47, Rafael J. Wysocki wrote:
>> On Wednesday, June 03, 2015 05:18:18 PM Paul Gortmaker wrote:
>>> 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" <rjw@rjwysocki.net>
>>> Cc: Viresh Kumar <viresh.kumar@linaro.org>
>>> Cc: Kukjin Kim <kgene@kernel.org>
>>> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>> Cc: linux-pm@vger.kernel.org
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: linux-samsung-soc@vger.kernel.org
>>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>
>> I'm assuming that this will go in via the Samsung tree.
>>
>>
>>> ---
>>>
>>> [ patch will be appended to the implicit include fixup series, see:
>>>   https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker@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.
--

> 
> Best regards,
> Krzysztof
> 

Re: [PATCH] drivers/cpufreq: include <module.h> for modular exynos-cpufreq.c code

[Krzysztof Kozlowski]

On 17.06.2015 00:29, Paul Gortmaker wrote:
> On 15-06-15 07:53 PM, Krzysztof Kozlowski wrote:
>> On 16.06.2015 08:47, Rafael J. Wysocki wrote:
>>> On Wednesday, June 03, 2015 05:18:18 PM Paul Gortmaker wrote:
>>>> 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" <rjw@rjwysocki.net>
>>>> Cc: Viresh Kumar <viresh.kumar@linaro.org>
>>>> Cc: Kukjin Kim <kgene@kernel.org>
>>>> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>>> Cc: linux-pm@vger.kernel.org
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-samsung-soc@vger.kernel.org
>>>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>>
>>> I'm assuming that this will go in via the Samsung tree.
>>>
>>>
>>>> ---
>>>>
>>>> [ patch will be appended to the implicit include fixup series, see:
>>>>   https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortmaker@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.

Thank you, I'll leave the patch for you to handle.

Best regards,
Krzysztof