[PATCH 0/3] ARM: fix three implicit module use cases fed via gpio

[PATCH 0/3] ARM: fix three implicit module use cases fed via gpio

[Paul Gortmaker]

While working on some for-4.9 cleanups of linux/gpio/driver.h it was
found that changes there caused build failures when walking all the
ARM defconfigs, in ARM specific mach-* files.

The proposed GPIO header change is just this:

 ---------------------------------------      
     --- a/include/linux/gpio/driver.h
     +++ b/include/linux/gpio/driver.h
     @@ -3,7 +3,6 @@
      
      #include <linux/device.h>
      #include <linux/types.h>
     -#include <linux/module.h>
      #include <linux/irq.h>
      #include <linux/irqchip/chained_irq.h>
      #include <linux/irqdomain.h>
     @@ -16,6 +15,7 @@ struct of_phandle_args;
      struct device_node;
      struct seq_file;
      struct gpio_device;
     +struct module;
      
      #ifdef CONFIG_GPIOLIB
 ---------------------------------------      

...which is what we've already got in ~50 other include/linux/* files to
try and keep cross contamination entanglement at a minimum.

So we uncovered three users in ARM specific files relying on the above
presence in this header, vs. dealing with it within the driver itself.

But with ARM and GPIO being different subsystems, we'll need to get
this in ARM 1st, and then wait a release before changing the GPIO
header, otherwise we'll risk triggering these three build failures.

So, if folks consider these three trivial changes OK for late in the
for-4.8 cycle, then great.  Otherwise I'll resubmit the ARM parts for
for-4.9 and the GPIO bits for the one after that.

[Yes, there were gpio implicit users too, but they are easily sync'd
with the gpio header change being at the end of that series.]

Paul.
--

Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-gpio at vger.kernel.org
Cc: linux-omap at vger.kernel.org
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>

Paul Gortmaker (3):
  ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals
  ARM: pxa: add module.h for corgi symbol_get/symbol_put usage
  ARM: pxa: add module.h for spitz symbol_get/symbol_put usage

 arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
 arch/arm/mach-pxa/corgi.c                    | 1 +
 arch/arm/mach-pxa/spitz.c                    | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

-- 
2.8.4

[PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals

[Paul Gortmaker]

During unrelated work, attempting to remove an include of the
linux/module.h in favour of "struct module;" in order to reduce
header entanglement, we found doing so caused a build failure in
this file.

It turns out this file uses __init_or_module which lives in the
module.h header, but it wasn't including module.h -- which was
being masked by the module.h in include/linux/gpio/driver.h - the
one we want to remove/replace.

However, if we dig into Makefile / Kconfig we find:

mach-omap2/board-rx51-peripherals.o ---->
   mach-omap2/Makefile:obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51-peripherals.o

arch/arm/mach-omap2/Kconfig:config MACH_NOKIA_RX51
arch/arm/mach-omap2/Kconfig:    bool "Nokia N900 (RX-51) phone"

...and hence the __init_or_module is pointless, as it will always
evaluate to plain __init.

With ARM and GPIO being different subsystems, we'll need to get
this in ARM 1st, and then wait a release before changing the GPIO
header, otherwise we'll risk triggering build failures.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-omap at vger.kernel.org
Cc: linux-gpio at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index a5ab712c1a59..4ddda1d33ec1 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -978,7 +978,7 @@ static struct twl4030_platform_data rx51_twldata __initdata = {
 	.vio			= &rx51_vio,
 };
 
-static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata_or_module = {
+static struct tpa6130a2_platform_data rx51_tpa6130a2_data __initdata = {
 	.power_gpio		= 98,
 };
 
-- 
2.8.4

[PATCH 2/3] ARM: pxa: add module.h for corgi symbol_get/symbol_put usage

[Paul Gortmaker]

During unrelated work, attempting to remove an include of the
linux/module.h in favour of "struct module;" in order to reduce
header entanglement, we found doing so caused a build failure in
this file.

mach-pxa/corgi.c: In function 'corgi_bl_kick_battery':
mach-pxa/corgi.c:548:2: error: implicit declaration of function 'symbol_get' [-Werror=implicit-function-declaration]
mach-pxa/corgi.c:548:12: warning: assignment makes pointer from integer without a cast [enabled by default]
mach-pxa/corgi.c:551:3: error: implicit declaration of function 'symbol_put' [-Werror=implicit-function-declaration]

It turns out this file uses symbol_get/symbol_put which live in the
module.h header, but it wasn't including module.h -- which was
being masked by the module.h in include/linux/gpio/driver.h - the
one we want to remove/replace.

With ARM and GPIO being different subsystems, we'll need to get
this in ARM 1st, and then wait a release before changing the GPIO
header, otherwise we'll risk triggering build failures.

Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-omap at vger.kernel.org
Cc: linux-gpio at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 arch/arm/mach-pxa/corgi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index aa952979461f..183cd3446f25 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -13,6 +13,7 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/module.h>	/* symbol_get ; symbol_put */
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/major.h>
-- 
2.8.4

[PATCH 3/3] ARM: pxa: add module.h for spitz symbol_get/symbol_put usage

[Paul Gortmaker]

During unrelated work, attempting to remove an include of the
linux/module.h in favour of "struct module;" in order to reduce
header entanglement, we found doing so caused a build failure in
this file.

mach-pxa/spitz.c: In function 'spitz_bl_kick_battery':
mach-pxa/spitz.c:524:2: error: implicit declaration of function 'symbol_get' [-Werror=implicit-function-declaration]
mach-pxa/spitz.c:524:12: warning: assignment makes pointer from integer without a cast [enabled by default]
mach-pxa/spitz.c:527:3: error: implicit declaration of function 'symbol_put' [-Werror=implicit-function-declaration]

It turns out this file uses symbol_get/symbol_put which live in the
module.h header, but it wasn't including module.h -- which was
being masked by the module.h in include/linux/gpio/driver.h - the
one we want to remove/replace.

With ARM and GPIO being different subsystems, we'll need to get
this in ARM 1st, and then wait a release before changing the GPIO
header, otherwise we'll risk triggering build failures.

Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-omap at vger.kernel.org
Cc: linux-gpio at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
 arch/arm/mach-pxa/spitz.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index b410698808ca..8078e3cdb6c8 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -13,6 +13,7 @@
  */
 
 #include <linux/kernel.h>
+#include <linux/module.h>	/* symbol_get ; symbol_put */
 #include <linux/platform_device.h>
 #include <linux/delay.h>
 #include <linux/gpio_keys.h>
-- 
2.8.4

[PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals

[Tony Lindgren]

Hi,

* Paul Gortmaker <paul.gortmaker@windriver.com> [160719 21:17]:
> During unrelated work, attempting to remove an include of the
> linux/module.h in favour of "struct module;" in order to reduce
> header entanglement, we found doing so caused a build failure in
> this file.

We're planning to drop this file after v4.8-rc1 after I've
verified that legacy booting still works at v4.8-rc1.

Are you OK if I pick this patch into my omap-for-v4.8/legacy
branch? Or if you have a minimal immutable branch against v4.7-rc1
with just this patch I can merge it in no problem.

Regards,

Tony

[PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals

[Paul Gortmaker]

[Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals] On 21/07/2016 (Thu 23:41) Tony Lindgren wrote:

> Hi,
> 
> * Paul Gortmaker <paul.gortmaker@windriver.com> [160719 21:17]:
> > During unrelated work, attempting to remove an include of the
> > linux/module.h in favour of "struct module;" in order to reduce
> > header entanglement, we found doing so caused a build failure in
> > this file.
> 
> We're planning to drop this file after v4.8-rc1 after I've
> verified that legacy booting still works at v4.8-rc1.
> 
> Are you OK if I pick this patch into my omap-for-v4.8/legacy
> branch? Or if you have a minimal immutable branch against v4.7-rc1
> with just this patch I can merge it in no problem.

Is the legacy branch a contingency plan for the case where legacy
booting doesn't work?  If so, that should be OK.

Having the patch present, or having the file deleted both take care of
my concern -- which was was introducing build regressions when adding
the gpio header cleanup into for-4.9 content.  

THanks,
Paul.
--

> 
> Regards,
> 
> Tony

[PATCH 0/3] ARM: fix three implicit module use cases fed via gpio

[Linus Walleij]

On Wed, Jul 20, 2016 at 6:13 AM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:

> While working on some for-4.9 cleanups of linux/gpio/driver.h it was
> found that changes there caused build failures when walking all the
> ARM defconfigs, in ARM specific mach-* files.
(...)
> Paul Gortmaker (3):
>   ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals
>   ARM: pxa: add module.h for corgi symbol_get/symbol_put usage
>   ARM: pxa: add module.h for spitz symbol_get/symbol_put usage

For all three:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij

[PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals

[Tony Lindgren]

* Paul Gortmaker <paul.gortmaker@windriver.com> [160722 07:02]:
> [Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals] On 21/07/2016 (Thu 23:41) Tony Lindgren wrote:
> 
> > Hi,
> > 
> > * Paul Gortmaker <paul.gortmaker@windriver.com> [160719 21:17]:
> > > During unrelated work, attempting to remove an include of the
> > > linux/module.h in favour of "struct module;" in order to reduce
> > > header entanglement, we found doing so caused a build failure in
> > > this file.
> > 
> > We're planning to drop this file after v4.8-rc1 after I've
> > verified that legacy booting still works at v4.8-rc1.
> > 
> > Are you OK if I pick this patch into my omap-for-v4.8/legacy
> > branch? Or if you have a minimal immutable branch against v4.7-rc1
> > with just this patch I can merge it in no problem.
> 
> Is the legacy branch a contingency plan for the case where legacy
> booting doesn't work?  If so, that should be OK.

Well it's just a branch of omap legacy booting related patches
for v4.8. But looking at it now, looks like I already pushed out the
removal of the last two remaining board files before I took few weeks
off. But I did not add it to Linux next to keep things working
until -rc1.

> Having the patch present, or having the file deleted both take care of
> my concern -- which was was introducing build regressions when adding
> the gpio header cleanup into for-4.9 content.  

OK. As I've already pushed out the board-*.c removal branch, I
suggest we just drop the $subject patch to avoid a merge conflict.

Regards,

Tony

[PATCH 0/3] ARM: fix three implicit module use cases fed via gpio

[Robert Jarzmik]

Paul Gortmaker <paul.gortmaker@windriver.com> writes:

> While working on some for-4.9 cleanups of linux/gpio/driver.h it was
> found that changes there caused build failures when walking all the
> ARM defconfigs, in ARM specific mach-* files.
>
> The proposed GPIO header change is just this:
>
>  ---------------------------------------      
>      --- a/include/linux/gpio/driver.h
>      +++ b/include/linux/gpio/driver.h
>      @@ -3,7 +3,6 @@
>       
>       #include <linux/device.h>
>       #include <linux/types.h>
>      -#include <linux/module.h>
>       #include <linux/irq.h>
>       #include <linux/irqchip/chained_irq.h>
>       #include <linux/irqdomain.h>
>      @@ -16,6 +15,7 @@ struct of_phandle_args;
>       struct device_node;
>       struct seq_file;
>       struct gpio_device;
>      +struct module;
>       
>       #ifdef CONFIG_GPIOLIB
>  ---------------------------------------      
>
> ...which is what we've already got in ~50 other include/linux/* files to
> try and keep cross contamination entanglement at a minimum.
>
> So we uncovered three users in ARM specific files relying on the above
> presence in this header, vs. dealing with it within the driver itself.
>
> But with ARM and GPIO being different subsystems, we'll need to get
> this in ARM 1st, and then wait a release before changing the GPIO
> header, otherwise we'll risk triggering these three build failures.
>
> So, if folks consider these three trivial changes OK for late in the
> for-4.8 cycle, then great.  Otherwise I'll resubmit the ARM parts for
> for-4.9 and the GPIO bits for the one after that.
>
> [Yes, there were gpio implicit users too, but they are easily sync'd
> with the gpio header change being at the end of that series.]
>
> Paul.
> --
>
> Cc: Alexandre Courbot <gnurou@gmail.com>
> Cc: Daniel Mack <daniel@zonque.org>
> Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-gpio at vger.kernel.org
> Cc: linux-omap at vger.kernel.org
> Cc: Robert Jarzmik <robert.jarzmik@free.fr>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Tony Lindgren <tony@atomide.com>
>
> Paul Gortmaker (3):
>   ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals
>   ARM: pxa: add module.h for corgi symbol_get/symbol_put usage
>   ARM: pxa: add module.h for spitz symbol_get/symbol_put usage
>
>  arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
>  arch/arm/mach-pxa/corgi.c                    | 1 +
>  arch/arm/mach-pxa/spitz.c                    | 1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)

Hi Paul,

I'll take the mach-pxa changes to pxa/for-next tree with Linus's ack.
Tony, I think you will carry the remaining omap2 one, right ?

As for the cycle, I'd prefer have it for-4.9 as we're at rc7 and it's a bit late
for me. If you want your GPIO bits to get in 4.9 I think I can commit to request
pull very early (-rc1 time) or give my ack so that Linus can carry these changes
through the gpio tree with the other changes.

Cheers.

-- 
Robert

[PATCH 0/3] ARM: fix three implicit module use cases fed via gpio

[Paul Gortmaker]

[Re: [PATCH 0/3] ARM: fix three implicit module use cases fed via gpio] On 23/07/2016 (Sat 10:09) Robert Jarzmik wrote:

> Paul Gortmaker <paul.gortmaker@windriver.com> writes:
> 

[...]

> >
> > But with ARM and GPIO being different subsystems, we'll need to get
> > this in ARM 1st, and then wait a release before changing the GPIO
> > header, otherwise we'll risk triggering these three build failures.
> >
> > So, if folks consider these three trivial changes OK for late in the
> > for-4.8 cycle, then great.  Otherwise I'll resubmit the ARM parts for
> > for-4.9 and the GPIO bits for the one after that.

[...]

> Hi Paul,
> 
> I'll take the mach-pxa changes to pxa/for-next tree with Linus's ack.
> Tony, I think you will carry the remaining omap2 one, right ?
> 
> As for the cycle, I'd prefer have it for-4.9 as we're at rc7 and it's a bit late
> for me. If you want your GPIO bits to get in 4.9 I think I can commit to request
> pull very early (-rc1 time) or give my ack so that Linus can carry these changes
> through the gpio tree with the other changes.

Yep, agreed it is now (Sat) a bit late, so as per what I said above, do
whatever you are comfortable with and I'll react accordingly to make
sure the gpio fix lands on a baseline with all the other three patches
present and doesn't introduce build regressions.

Thanks,
Paul.

> 
> Cheers.
> 
> -- 
> Robert

[PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals

[Paul Gortmaker]

[Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals] On 22/07/2016 (Fri 22:55) Tony Lindgren wrote:

> * Paul Gortmaker <paul.gortmaker@windriver.com> [160722 07:02]:

[...]

> > Having the patch present, or having the file deleted both take care of
> > my concern -- which was was introducing build regressions when adding
> > the gpio header cleanup into for-4.9 content.  
> 
> OK. As I've already pushed out the board-*.c removal branch, I
> suggest we just drop the $subject patch to avoid a merge conflict.

Sounds like a plan.  I'll just keep it in my local queue so my tests
don't fail and drop it on the floor once I see your removal loop around
to me via linux-next or master.

Thanks,
Paul.
--

> 
> Regards,
> 
> Tony