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:	Thu, 17 Sep 2015 09:25:42 +0100
From:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To:	Inha Song <ideal.song@...sung.com>
CC:	<lee.jones@...aro.org>, <broonie@...nel.org>,
	<linux-kernel@...r.kernel.org>, <alsa-devel@...a-project.org>,
	<patches@...nsource.wolfsonmicro.com>, <sameo@...ux.intel.com>
Subject: Re: [alsa-devel] [PATCH] mfd: arizona: Call the runtime PM
 function if the state is runtime resumed

On Thu, Sep 17, 2015 at 05:28:47PM +0900, Inha Song wrote:
> This patch call runtiem PM function manually if the state is runtime resumed
> before enter suspend.
> 
> This case has occurred when wake-up by the resume after entering to
> suspend during the playback.
> $ aplay -> runtime_resume() -> suspend() -> resume()
> 
> In this case, Can occurred an error when enter suspend.
> --
> [   82.559234] PM: suspend of devices complete after 57.252 msecs
> [   82.567978] arizona spi1.0: Failed to read IRQ status: -108
> [   82.567989] arizona spi1.0: Failed to read main IRQ status: -108
> [   82.568027] arizona spi1.0: Failed to read IRQ status: -108
> [   82.568036] arizona spi1.0: Failed to read main IRQ status: -108

Would it be possible to get some more detail on what is happening
here? A full log would be nice with DEBUG enabled in
arizona-core.c, also perhaps put some printk's in the SPI driver
suspend/resume as well.

It looks like what is happening is that the system is attempting
to handle an IRQ before the SPI has been resumed. But that is
exactly what the irq enables/disables in the system PM ops in
Arizona are trying to avoid.

> ....
> So, we should call runtime_suspend() manually when enter suspend
> if the state is runtime resume.

There are many use-cases where we want to leave the CODEC enabled
whilst the system is suspended so we really don't want to be
doing a runtime suspend with every system suspend.

Thanks,
Charles
--
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