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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 10 Apr 2013 12:46:55 +0000
From:	"Liu, Chuansheng" <chuansheng.liu@...el.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.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

Hi Mark,

> -----Original Message-----
> From: Mark Brown [mailto:broonie@...nsource.wolfsonmicro.com]
> Sent: Wednesday, April 10, 2013 8:30 PM
> To: Liu, Chuansheng
> Cc: sameo@...ux.intel.com; linux-kernel@...r.kernel.org;
> patches@...nsource.wolfsonmicro.com
> Subject: Re: mfd, arizona: Fix the deadlock between interrupt handler and
> dpm_suspend
> 
> On Wed, Apr 10, 2013 at 08:39:09PM +0800, Chuansheng Liu wrote:
> 
> > 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?

> the first place so this probably isn't what we want.  Something like the
> below which does a similar thing to what we do on resume might help
> here...  needs testing though.
We will take your patch to do the test, thanks.

> 
> From 538e817db94dc0c689ecfea7151b1a3f86bb204a Mon Sep 17 00:00:00
> 2001
> From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
> Date: Wed, 10 Apr 2013 12:40:26 +0100
> Subject: [PATCH] mfd: arizona: Disable interrupts during suspend
> 
> We aren't able to handle interrupts after the device has suspended since
> we need to runtime resume it in order to do so but the controller may not
> be available any more. Handle this in the same way as we handle a similar
> issue on resume.
> 
> Reported-by: Chuansheng Liu <chuansheng.liu@...el.com>
> Signed-off-by: Mark Brown <broonie@...nsource.wolfsonmicro.com>
> ---
>  drivers/mfd/arizona-core.c |   23 ++++++++++++++++++++++-
>  1 file changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 98023d8..c6be1f6 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -399,6 +399,26 @@ static int arizona_runtime_suspend(struct device
> *dev)
>  #endif
> 
>  #ifdef CONFIG_PM_SLEEP
> +static int arizona_suspend(struct device *dev)
> +{
> +	struct arizona *arizona = dev_get_drvdata(dev);
> +
> +	dev_dbg(arizona->dev, "Suspend, disabling IRQ\n");
> +	disable_irq(arizona->irq);
> +
> +	return 0;
> +}
> +
> +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?
and one more question, why the irq is needed to be enabled even after suspended?

> +
> +	return 0;
> +}
> +
>  static int arizona_resume_noirq(struct device *dev)
>  {
>  	struct arizona *arizona = dev_get_drvdata(dev);
> @@ -424,8 +444,9 @@ const struct dev_pm_ops arizona_pm_ops = {
>  	SET_RUNTIME_PM_OPS(arizona_runtime_suspend,
>  			   arizona_runtime_resume,
>  			   NULL)
> -	SET_SYSTEM_SLEEP_PM_OPS(NULL, arizona_resume)
> +	SET_SYSTEM_SLEEP_PM_OPS(arizona_suspend, arizona_resume)
>  #ifdef CONFIG_PM_SLEEP
> +	.suspend_late = arizona_suspend_late,
>  	.resume_noirq = arizona_resume_noirq,
>  #endif
>  };
> --
> 1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ