Re: [PATCH v3b 0/9] refactoring for mask_cache

Re: [PATCH v3b 0/9] refactoring for mask_cache

[Greg KH]

On Thu, Mar 21, 2013 at 06:12:02PM +0100, Gerlando Falauto wrote:
> This patchset addresses a regression found with the Orion GPIO controller
> when both Edge- and Level- based interrupts are requested within the same
> GPIO chip. The regression was introduced by e59347a
> "arm: orion: Use generic irq chip"
> 
> thereby affecting all kernel releases since 3.0.x.

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.

</formletter>

Re: [PATCH v3b 0/9] refactoring for mask_cache

[Thomas Gleixner]

On Thu, 21 Mar 2013, Greg KH wrote:

> On Thu, Mar 21, 2013 at 06:12:02PM +0100, Gerlando Falauto wrote:
> > This patchset addresses a regression found with the Orion GPIO controller
> > when both Edge- and Level- based interrupts are requested within the same
> > GPIO chip. The regression was introduced by e59347a
> > "arm: orion: Use generic irq chip"
> > 
> > thereby affecting all kernel releases since 3.0.x.
> 
> <formletter>
> 
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
> 
> </formletter>

Aside of that it would be less intrusive for the stable series to
revert the offending commit(s), if that is possible.

Thanks,

	tglx

Re: [PATCH v3b 0/9] refactoring for mask_cache

[Greg KH]

On Tue, Mar 26, 2013 at 09:37:53PM +0100, Thomas Gleixner wrote:
> On Thu, 21 Mar 2013, Greg KH wrote:
> 
> > On Thu, Mar 21, 2013 at 06:12:02PM +0100, Gerlando Falauto wrote:
> > > This patchset addresses a regression found with the Orion GPIO controller
> > > when both Edge- and Level- based interrupts are requested within the same
> > > GPIO chip. The regression was introduced by e59347a
> > > "arm: orion: Use generic irq chip"
> > > 
> > > thereby affecting all kernel releases since 3.0.x.
> > 
> > <formletter>
> > 
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> > for how to do this properly.
> > 
> > </formletter>
> 
> Aside of that it would be less intrusive for the stable series to
> revert the offending commit(s), if that is possible.

If it is reverted in Linus's tree, yes, I can do that.  But if so,
please just tag that revert with the Cc: stable marking and then I can
pick it up properly.

Otherwise, no, I can't revert something that isn't already fixed in
upstream first.

thanks,

greg k-h

Re: [PATCH v3b 0/9] refactoring for mask_cache

[Thomas Gleixner]

On Tue, 26 Mar 2013, Greg KH wrote:

> On Tue, Mar 26, 2013 at 09:37:53PM +0100, Thomas Gleixner wrote:
> > On Thu, 21 Mar 2013, Greg KH wrote:
> > 
> > > On Thu, Mar 21, 2013 at 06:12:02PM +0100, Gerlando Falauto wrote:
> > > > This patchset addresses a regression found with the Orion GPIO controller
> > > > when both Edge- and Level- based interrupts are requested within the same
> > > > GPIO chip. The regression was introduced by e59347a
> > > > "arm: orion: Use generic irq chip"
> > > > 
> > > > thereby affecting all kernel releases since 3.0.x.
> > > 
> > > <formletter>
> > > 
> > > This is not the correct way to submit patches for inclusion in the
> > > stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> > > for how to do this properly.
> > > 
> > > </formletter>
> > 
> > Aside of that it would be less intrusive for the stable series to
> > revert the offending commit(s), if that is possible.
> 
> If it is reverted in Linus's tree, yes, I can do that.  But if so,
> please just tag that revert with the Cc: stable marking and then I can
> pick it up properly.
> 
> Otherwise, no, I can't revert something that isn't already fixed in
> upstream first.

I know. The proper thing would be:

patch 1/n   revert (cc'ed to stable)
patch 2-m/n fix infrastructure
patch n/n   redo the commit with the proper change

Though I don't know if it's possible.

Thanks,

	tglx
 

Re: [PATCH v3b 0/9] refactoring for mask_cache

[Greg KH]

On Tue, Mar 26, 2013 at 09:54:59PM +0100, Thomas Gleixner wrote:
> On Tue, 26 Mar 2013, Greg KH wrote:
> 
> > On Tue, Mar 26, 2013 at 09:37:53PM +0100, Thomas Gleixner wrote:
> > > On Thu, 21 Mar 2013, Greg KH wrote:
> > > 
> > > > On Thu, Mar 21, 2013 at 06:12:02PM +0100, Gerlando Falauto wrote:
> > > > > This patchset addresses a regression found with the Orion GPIO controller
> > > > > when both Edge- and Level- based interrupts are requested within the same
> > > > > GPIO chip. The regression was introduced by e59347a
> > > > > "arm: orion: Use generic irq chip"
> > > > > 
> > > > > thereby affecting all kernel releases since 3.0.x.
> > > > 
> > > > <formletter>
> > > > 
> > > > This is not the correct way to submit patches for inclusion in the
> > > > stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> > > > for how to do this properly.
> > > > 
> > > > </formletter>
> > > 
> > > Aside of that it would be less intrusive for the stable series to
> > > revert the offending commit(s), if that is possible.
> > 
> > If it is reverted in Linus's tree, yes, I can do that.  But if so,
> > please just tag that revert with the Cc: stable marking and then I can
> > pick it up properly.
> > 
> > Otherwise, no, I can't revert something that isn't already fixed in
> > upstream first.
> 
> I know. The proper thing would be:
> 
> patch 1/n   revert (cc'ed to stable)
> patch 2-m/n fix infrastructure
> patch n/n   redo the commit with the proper change
> 
> Though I don't know if it's possible.

Did anything ever come of this?  Do you need me to do anything for
3.8-stable still?

thanks,

greg k-h

Re: [PATCH v3 3/9] gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type

[Linus Walleij]

On Thu, Mar 21, 2013 at 6:12 PM, Gerlando Falauto
<gerlando.falauto@keymile.com> wrote:

> Since we have now introduced pmask_cache within irq_chip_type to also
> handle per-chip-type mask registers, convert gpio-mvebu driver to use
> this new pointer.
>
> Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>

If the genirq changes are accepted you can have my
Acked-by: Linus Walleij <linus.walleij@linaro.org>

>From the GPIO side of things.

Yours,
Linus Walleij

Re: [PATCH v3b 8/9] orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS

[Linus Walleij]

On Thu, Mar 21, 2013 at 6:12 PM, Gerlando Falauto
<gerlando.falauto@keymile.com> wrote:

> enable handling of separate mask registers for Orion SoC GPIOs,
> fixing indeed the regression introduced by e59347a
> "arm: orion: Use generic irq chip".
>
> Reported-by: Joey Oravec <joravec@drewtech.com>
> Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
> Tested-by: Simon Guinot <sguinot@lacie.com>

If the genirq changes are accepted you can have my
Acked-by: Linus Walleij <linus.walleij@linaro.org>

>From the GPIO side of things.

Yours,
Linus Walleij

Re: [PATCH v3b 9/9] gpio: mvebu: enable IRQ_GC_SEPARATE_MASK_REGISTERS

[Linus Walleij]

On Thu, Mar 21, 2013 at 6:12 PM, Gerlando Falauto
<gerlando.falauto@keymile.com> wrote:

> enable handling of separate mask registers for all three SoC variants
> handled by this driver.
>
> Signed-off-by: Gerlando Falauto <gerlando.falauto@keymile.com>
> Tested-by: Simon Guinot <sguinot@lacie.com>

If the genirq changes are accepted you can have my
Acked-by: Linus Walleij <linus.walleij@linaro.org>

>From the GPIO side of things.

Yours,
Linus Walleij

Re: [PATCH v3b 0/9] refactoring for mask_cache

[Gerlando Falauto]

Hi everyone,

any chance we could move this pachset to the next level (at least for 
mainline)?

Thanks a lot!
Gerlando

On 03/21/2013 06:12 PM, Gerlando Falauto wrote:
> This patchset addresses a regression found with the Orion GPIO controller
> when both Edge- and Level- based interrupts are requested within the same
> GPIO chip. The regression was introduced by e59347a
> "arm: orion: Use generic irq chip"
>
> thereby affecting all kernel releases since 3.0.x.
>
> The reason behind it is that the Orion GPIO controller uses separate
> mask registers for the two types of interrupts (one for edge and one
> for level), whereas in other cases the same register would be shared.
> Since this mask register is cached, we need to have (potentially)
> separate register caches.
> We do that by adding a per-chip-type mask register cache, and a mask cache
> pointer (which will point either to that or the shared one).
>
> So we proceed with incremental stages:
> a) we introduce the new fields and pointer (though only the shared one is used)
> b) we convert all drivers to use it
> c) we rename the field so to force the use of the per-ct pointer
> d) we add per-ct mask cache, provided the new flag
>     IRQ_GC_SEPARATE_MASK_REGISTERS is enabled
> e) we enable the flag for orion-gpio and mvebu drivers
>
> The changes were tested by Simon Guinot to be effective on Kirkwood chipsets,
> on both the legacy orion-gpio and the new gpio-mvebu drivers.
> The bug should also affect the other two Marvell variants handled by
> the gpio-mvebu driver.
>
> Changes from v3: cover letter and SOB lines.
>
> Gerlando Falauto (9):
>    genirq: cosmetic: remove cur_regs
>    genirq: add mask_cache and pmask_cache into struct irq_chip_type
>    gpio: mvebu: convert to usage of *pmask_cache within irq_chip_type
>    MIPS: JZ4740: convert to usage of *pmask_cache within irq_chip_type
>    ARM: SAMSUNG: convert to usage of *pmask_cache within irq_chip_type
>    genirq: rename mask_cache to shared_mask_cache
>    genirq: handle separate mask registers
>    orion-gpio: enable IRQ_GC_SEPARATE_MASK_REGISTERS
>    gpio: mvebu: enable IRQ_GC_SEPARATE_MASK_REGISTERS
>
>   arch/arm/plat-orion/gpio.c            |    3 +-
>   arch/arm/plat-samsung/irq-vic-timer.c |    6 ++--
>   arch/mips/jz4740/irq.c                |    3 +-
>   drivers/gpio/gpio-mvebu.c             |   23 ++++++++------
>   include/linux/irq.h                   |    9 ++++--
>   kernel/irq/generic-chip.c             |   55 +++++++++++++++++++++------------
>   6 files changed, 64 insertions(+), 35 deletions(-)
>