linux-kernel - Re: mfd, arizona: Fix the deadlock between interrupt handler and dpm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 10 Apr 2013 13:52:32 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	"Liu, Chuansheng" <chuansheng.liu@...el.com>
Cc:	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"patches@...nsource.wolfsonmicro.com" 
	<patches@...nsource.wolfsonmicro.com>
Subject: Re: mfd, arizona: Fix the deadlock between interrupt handler and
 dpm_suspend

On Wed, Apr 10, 2013 at 12:46:55PM +0000, Liu, Chuansheng wrote:
> Hi Mark,

> > > Here the arizona irq is not NOSUSPEND irq, so when doing device suspend,
> > > we can disable the arizona irq, and enable it until devices resuming finished.

> > Hrm, well - actually the primary IRQ probably ought to be a nosuspend in

> Could we set the irq as NOSUSPEND directly?

Worth checking, yes.

> > +static int arizona_suspend_late(struct device *dev)
> > +{
> > +	struct arizona *arizona = dev_get_drvdata(dev);
> > +
> > +	dev_dbg(arizona->dev, "Late suspend, reenabling IRQ\n");
> > +	enable_irq(arizona->irq);

> Here, after later suspending, is it possible the irq coming again?

No, by the time late suspend happens all interrupts ought to be off.  

> and one more question, why the irq is needed to be enabled even after suspended?

We want interrupts to function as wake sources and want to minimise the
risk of confusing things - the enable/disable ought to nest with what
the core is doing.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)