On Thu, Sep 28, 2017 at 11:22:38AM -0700, Florian Fainelli wrote:
> On 09/27/2017 05:15 PM, justinpopo6@xxxxxxxxx wrote:
> > From: Justin Chen <justinpopo6@xxxxxxxxx>
> >
> > 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 <justinpopo6@xxxxxxxxx>
> > 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
Attachment:
signature.asc
Description: Digital signature
