Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Tue, 8 Dec 2015 11:54:11 +0100 (CET), Thomas Gleixner wrote: > On Tue, 8 Dec 2015, Thomas Petazzoni wrote: > > When a device driver uses a normal (non per-CPU) interrupt, then it > > doesn't have to take care of disabling the interrupt on suspend and > > re-enabling the interrupt on

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Tue, 8 Dec 2015 11:54:11 +0100 (CET), Thomas Gleixner wrote: > On Tue, 8 Dec 2015, Thomas Petazzoni wrote: > > When a device driver uses a normal (non per-CPU) interrupt, then it > > doesn't have to take care of disabling the interrupt on suspend and > > re-enabling the interrupt on

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, 8 Dec 2015, Thomas Petazzoni wrote: > When a device driver uses a normal (non per-CPU) interrupt, then it > doesn't have to take care of disabling the interrupt on suspend and > re-enabling the interrupt on resume at the interrupt controller level. > This is all transparently handled by

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Hello Thomas, On Sun, 6 Dec 2015 10:28:15 +0100 (CET), Thomas Gleixner wrote: > Second thoughts. That network driver example does not make sense. > > You have a suspend/resume mechanism and a cpu hotplug machinery in > that driver, right? So that should be responsible for > disabling/enabling

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Hello Thomas, On Sun, 6 Dec 2015 10:28:15 +0100 (CET), Thomas Gleixner wrote: > Second thoughts. That network driver example does not make sense. > > You have a suspend/resume mechanism and a cpu hotplug machinery in > that driver, right? So that should be responsible for > disabling/enabling

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, 8 Dec 2015, Thomas Petazzoni wrote: > When a device driver uses a normal (non per-CPU) interrupt, then it > doesn't have to take care of disabling the interrupt on suspend and > re-enabling the interrupt on resume at the interrupt controller level. > This is all transparently handled by

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Sat, 5 Dec 2015, Thomas Gleixner wrote: > On Fri, 4 Dec 2015, Thomas Petazzoni wrote: > > Well, the problem is that IRQ_NOAUTOEN is a global flag, which is OK > > for global interrupts, but not good for per-CPU interrupts, since you > > don't have the information on a per-CPU basis of

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Sat, 5 Dec 2015, Thomas Gleixner wrote: > On Fri, 4 Dec 2015, Thomas Petazzoni wrote: > > Well, the problem is that IRQ_NOAUTOEN is a global flag, which is OK > > for global interrupts, but not good for per-CPU interrupts, since you > > don't have the information on a per-CPU basis of

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Fri, 4 Dec 2015, Thomas Petazzoni wrote: > Well, the problem is that IRQ_NOAUTOEN is a global flag, which is OK > for global interrupts, but not good for per-CPU interrupts, since you > don't have the information on a per-CPU basis of which interrupt was > enabled before suspend, and

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Fri, 4 Dec 2015, Thomas Petazzoni wrote: > Well, the problem is that IRQ_NOAUTOEN is a global flag, which is OK > for global interrupts, but not good for per-CPU interrupts, since you > don't have the information on a per-CPU basis of which interrupt was > enabled before suspend, and

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Fri, 13 Nov 2015 15:11:16 -0500 (EST), Thomas Gleixner wrote: > On Wed, 11 Nov 2015, Thomas Petazzoni wrote: > > Have you had the time to consider the proposed solution? For 4.3 we > > implemented the quick work-around that consisted in clearing > > IRQ_NOAUTOEN, but it's probably not

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Fri, 13 Nov 2015 15:11:16 -0500 (EST), Thomas Gleixner wrote: > On Wed, 11 Nov 2015, Thomas Petazzoni wrote: > > Have you had the time to consider the proposed solution? For 4.3 we > > implemented the quick work-around that consisted in clearing > > IRQ_NOAUTOEN, but it's probably not

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Wed, 11 Nov 2015, Thomas Petazzoni wrote: > Have you had the time to consider the proposed solution? For 4.3 we > implemented the quick work-around that consisted in clearing > IRQ_NOAUTOEN, but it's probably not a very good long-term solution. > > Don't hesitate to let me know if

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Wed, 11 Nov 2015, Thomas Petazzoni wrote: > Have you had the time to consider the proposed solution? For 4.3 we > implemented the quick work-around that consisted in clearing > IRQ_NOAUTOEN, but it's probably not a very good long-term solution. > > Don't hesitate to let me know if

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Tue, 20 Oct 2015 21:23:29 +0200 (CEST), Thomas Gleixner wrote: > > However, relying on IRQ_NOAUTOEN being cleared doesn't seem like the > > right long term solution, which is why I implemented what I believe is > > a (hopefully) better long term solution. > > Agreed. > > I'll go

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Tue, 20 Oct 2015 21:23:29 +0200 (CEST), Thomas Gleixner wrote: > > However, relying on IRQ_NOAUTOEN being cleared doesn't seem like the > > right long term solution, which is why I implemented what I believe is > > a (hopefully) better long term solution. > > Agreed. > > I'll go

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, 20 Oct 2015, Thomas Gleixner wrote: > On Tue, 20 Oct 2015, Russell King - ARM Linux wrote: > > I think Rob's patches need another review in light of this, to determine > > how much breakage there is here, and a decision how to proceed made on > > that basis. > > I'll go over them tomorrow

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, 20 Oct 2015, Thomas Gleixner wrote: > On Tue, 20 Oct 2015, Russell King - ARM Linux wrote: > > I think Rob's patches need another review in light of this, to determine > > how much breakage there is here, and a decision how to proceed made on > > that basis. > > I'll go over them tomorrow

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Tue, 20 Oct 2015 21:23:29 +0200 (CEST), Thomas Gleixner wrote: > On Tue, 20 Oct 2015, Thomas Petazzoni wrote: > > As discussed on IRC, another simpler (code line wise) solution is to > > simply clear the IRQ_NOAUTOEN flag in the irq-armada-370-xp, which > > brings us back to what

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, On Tue, 20 Oct 2015 21:23:29 +0200 (CEST), Thomas Gleixner wrote: > On Tue, 20 Oct 2015, Thomas Petazzoni wrote: > > As discussed on IRC, another simpler (code line wise) solution is to > > simply clear the IRQ_NOAUTOEN flag in the irq-armada-370-xp, which > > brings us back to what

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, 20 Oct 2015, Russell King - ARM Linux wrote: > On Tue, Oct 20, 2015 at 04:08:28PM +0200, Thomas Petazzoni wrote: > > As discussed on IRC, another simpler (code line wise) solution is to > > simply clear the IRQ_NOAUTOEN flag in the irq-armada-370-xp, which > > brings us back to what

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, 20 Oct 2015, Thomas Petazzoni wrote: > As discussed on IRC, another simpler (code line wise) solution is to > simply clear the IRQ_NOAUTOEN flag in the irq-armada-370-xp, which > brings us back to what set_irq_flags() was doing, without actually > reverting Rob's patch. I prefer that for

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Russell, On Tue, 20 Oct 2015 15:17:36 +0100, Russell King - ARM Linux wrote: > However, this is rather worrying. NOAUTOEN is supposed to avoid enabling > the interrupt when the interrupt is claimed. > > If, as a result of Rob's patch, we now have a load of IRQs which are > marked with NOAUTOEN

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, Oct 20, 2015 at 04:08:28PM +0200, Thomas Petazzoni wrote: > As discussed on IRC, another simpler (code line wise) solution is to > simply clear the IRQ_NOAUTOEN flag in the irq-armada-370-xp, which > brings us back to what set_irq_flags() was doing, without actually > reverting Rob's

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Jason, On Tue, 20 Oct 2015 14:04:27 +, Jason Cooper wrote: > Whole series, > > Reviewed by: Jason Cooper Thanks. > Thomas (tglx), if you're happy with the core changes, let me know and > I'll cue the series up. > > We know it's a bit late in the -rc cycle, but the alternative (reverting

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas (tglx also), On Tue, Oct 20, 2015 at 03:23:50PM +0200, Thomas Petazzoni wrote: > Thomas, Jason, Marc, Rob, > > In commit d17cab4451df ("irqchip: Kill off set_irq_flags usage"), Rob > Herring modified the irqchip drivers to not use the ARM-specific > set_irq_flags() and instead rely on

[PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, Jason, Marc, Rob, In commit d17cab4451df ("irqchip: Kill off set_irq_flags usage"), Rob Herring modified the irqchip drivers to not use the ARM-specific set_irq_flags() and instead rely on various functions provided by the core irq subsystem. While his commit was supposed to have no

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas (tglx also), On Tue, Oct 20, 2015 at 03:23:50PM +0200, Thomas Petazzoni wrote: > Thomas, Jason, Marc, Rob, > > In commit d17cab4451df ("irqchip: Kill off set_irq_flags usage"), Rob > Herring modified the irqchip drivers to not use the ARM-specific > set_irq_flags() and instead rely on

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, Oct 20, 2015 at 04:08:28PM +0200, Thomas Petazzoni wrote: > As discussed on IRC, another simpler (code line wise) solution is to > simply clear the IRQ_NOAUTOEN flag in the irq-armada-370-xp, which > brings us back to what set_irq_flags() was doing, without actually > reverting Rob's

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Russell, On Tue, 20 Oct 2015 15:17:36 +0100, Russell King - ARM Linux wrote: > However, this is rather worrying. NOAUTOEN is supposed to avoid enabling > the interrupt when the interrupt is claimed. > > If, as a result of Rob's patch, we now have a load of IRQs which are > marked with NOAUTOEN

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Jason, On Tue, 20 Oct 2015 14:04:27 +, Jason Cooper wrote: > Whole series, > > Reviewed by: Jason Cooper Thanks. > Thomas (tglx), if you're happy with the core changes, let me know and > I'll cue the series up. > > We know it's a bit late in the -rc cycle, but the

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, 20 Oct 2015, Thomas Petazzoni wrote: > As discussed on IRC, another simpler (code line wise) solution is to > simply clear the IRQ_NOAUTOEN flag in the irq-armada-370-xp, which > brings us back to what set_irq_flags() was doing, without actually > reverting Rob's patch. I prefer that for

Re: [PATCH 0/5] Fix regression introduced by set_irq_flags() removal

On Tue, 20 Oct 2015, Russell King - ARM Linux wrote: > On Tue, Oct 20, 2015 at 04:08:28PM +0200, Thomas Petazzoni wrote: > > As discussed on IRC, another simpler (code line wise) solution is to > > simply clear the IRQ_NOAUTOEN flag in the irq-armada-370-xp, which > > brings us back to what

[PATCH 0/5] Fix regression introduced by set_irq_flags() removal

Thomas, Jason, Marc, Rob, In commit d17cab4451df ("irqchip: Kill off set_irq_flags usage"), Rob Herring modified the irqchip drivers to not use the ARM-specific set_irq_flags() and instead rely on various functions provided by the core irq subsystem. While his commit was supposed to have no