Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1446944 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/3] ARM: fix three implicit module use cases fed via gpio Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-07-20 06:20 +0200
    Re: [PATCH 0/3] ARM: fix three implicit module use cases fed via gpio Linus Walleij <linus.walleij@linaro.org> - 2016-07-22 17:30 +0200
    Re: [PATCH 0/3] ARM: fix three implicit module use cases fed via gpio Robert Jarzmik <robert.jarzmik@free.fr> - 2016-07-23 10:20 +0200
      Re: [PATCH 0/3] ARM: fix three implicit module use cases fed via gpio Paul Gortmaker <paul.gortmaker@windriver.com> - 2016-07-23 16:20 +0200

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

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@lists.infradead.org
Cc: linux-gpio@vger.kernel.org
Cc: linux-omap@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

[toc] | [next] | [standalone]

#1448639

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

[toc] | [prev] | [next] | [standalone]

#1448906

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@lists.infradead.org
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-omap@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

[toc] | [prev] | [next] | [standalone]

#1448952

[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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web