MIPS: BMIPS: Do not mask IPIs during suspend

17385 diff mbox

From: Justin Chen <>

Commit a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq on CPU IRQs") fixes
an issue where disable_irq did not actually disable the irq. The
bug caused our IPIs to not be disabled, which actually is the correct
behavior.

With the addition of Commit a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq
on CPU IRQs"), the IPIs were getting disabled going into suspend,
thus schedule_ipi() was not being called. This caused deadlocks where
schedulable task were not being scheduled and other cpus were waiting
for them to do something.

Add the IRQF_NO_SUSPEND flag so an irq_disable will not be called
on the IPIs during suspend.

Signed-off-by: Justin Chen <>
Fixes: a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq on CPU IRQs")
---
 arch/mips/kernel/smp-bmips.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

On 09/27/2017 05:15 PM,  wrote:
> From: Justin Chen <>
> 
> Commit a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq on CPU IRQs") fixes
> an issue where disable_irq did not actually disable the irq. The
> bug caused our IPIs to not be disabled, which actually is the correct
> behavior.
> 
> With the addition of Commit a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq
> on CPU IRQs"), the IPIs were getting disabled going into suspend,
> thus schedule_ipi() was not being called. This caused deadlocks where
> schedulable task were not being scheduled and other cpus were waiting
> for them to do something.
> 
> Add the IRQF_NO_SUSPEND flag so an irq_disable will not be called
> on the IPIs during suspend.
> 
> Signed-off-by: Justin Chen <>
> Fixes: a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq on CPU IRQs")

This looks good to me, not sure if this is the recommended way to solve
this bug, but this definitively works.

> ---
>  arch/mips/kernel/smp-bmips.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/mips/kernel/smp-bmips.c b/arch/mips/kernel/smp-bmips.c
> index 1b070a76fcdd..3b900a04d724 100644
> --- a/arch/mips/kernel/smp-bmips.c
> +++ b/arch/mips/kernel/smp-bmips.c
> @@ -168,10 +168,10 @@ static void bmips_prepare_cpus(unsigned int max_cpus)
>  		return;
>  	}
>  
> -	if (request_irq(IPI0_IRQ, bmips_ipi_interrupt, IRQF_PERCPU,
> +	if (request_irq(IPI0_IRQ, bmips_ipi_interrupt, IRQF_PERCPU | IRQF_NO_SUSPEND,
>  			"smp_ipi0", NULL))
>  		panic("Can't request IPI0 interrupt");
> -	if (request_irq(IPI1_IRQ, bmips_ipi_interrupt, IRQF_PERCPU,
> +	if (request_irq(IPI1_IRQ, bmips_ipi_interrupt, IRQF_PERCPU | IRQF_NO_SUSPEND,
>  			"smp_ipi1", NULL))
>  		panic("Can't request IPI1 interrupt");
>  }
>

On Thu, Sep 28, 2017 at 11:22:38AM -0700, Florian Fainelli wrote:
> On 09/27/2017 05:15 PM,  wrote:
> > From: Justin Chen <>
> > 
> > Commit a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq on CPU IRQs") fixes
> > an issue where disable_irq did not actually disable the irq. The
> > bug caused our IPIs to not be disabled, which actually is the correct
> > behavior.
> > 
> > With the addition of Commit a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq
> > on CPU IRQs"), the IPIs were getting disabled going into suspend,
> > thus schedule_ipi() was not being called. This caused deadlocks where
> > schedulable task were not being scheduled and other cpus were waiting
> > for them to do something.
> > 
> > Add the IRQF_NO_SUSPEND flag so an irq_disable will not be called
> > on the IPIs during suspend.
> > 
> > Signed-off-by: Justin Chen <>
> > Fixes: a3e6c1eff548 ("MIPS: IRQ: Fix disabled_irq on CPU IRQs")
> 
> This looks good to me, not sure if this is the recommended way to solve
> this bug, but this definitively works.

Yeh it looks appropriate to me.

Documentation/power/suspend-and-interrupts.txt says:
> The IRQF_NO_SUSPEND flag is used to indicate that to the IRQ subsystem when
> requesting a special-purpose interrupt.  It causes suspend_device_irqs() to
> leave the corresponding IRQ enabled so as to allow the interrupt to work as
> expected during the suspend-resume cycle, but does not guarantee that the
> interrupt will wake the system from a suspended state -- for such cases it is
> necessary to use enable_irq_wake().

I presume there's no need for enable_irq_wake() be used on resume, since
c0_status will get preserved by drivers/soc/bcm/brcmstb/pm/s3-mips.S.

I've fixed checkpatch niggles, added a stable tag and applied for 4.16.

Thanks
James