linux-kernel - Re: [PATCH 3/5] mfd: wm5110: Add delay before releasing reset line on cold boot

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:	Tue, 17 Mar 2015 12:04:21 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
Cc:	lee.jones@...aro.org, sameo@...ux.intel.com, lgirdwood@...il.com,
	patches@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] mfd: wm5110: Add delay before releasing reset line
 on cold boot

On Tue, Mar 17, 2015 at 11:50:30AM +0000, Charles Keepax wrote:
> On Mon, Mar 16, 2015 at 08:47:10PM +0000, Mark Brown wrote:

> > As I suggested in my original reply handle system suspend.

> Just to confirm when we say system suspend here we are talking
> about the suspend and resume callbacks in dev_pm_ops? As I am
> slightly concerned I have my wires very crossed here.

Yes.

> There are use-cases were we expect the CODEC to be powered up
> across system suspend, is that something we should not expect to
> be guaranteed possible? For example compressed off-load or always
> on voice.

Sure, that's perfectly fine - jack detection is also very common.

> If these use-cases are expected to be reasonable then it would be
> reasonable to assume the regulators would not be removed if a
> runtime reference to the CODEC is held. If we can't assume that
> then how do we know if we should reset the CODEC?

Given jack detection I don't think you can base this purely on the CODEC
part of the device.

> So I guess we could reset the chip in system resume if no runtime
> references are held, but that still has the same problem as
> resetting in runtime resume, the chip may have been active
> running jack detection and you have just blatted the
> settings/state. I guess you could have the extcon driver restore
> the settings at least in its system resume, but it really feels
> like we are likely to be introducing issues worse than those this
> patch is there to fix.

> Apologies if I am missing something very basic here. Does this
> really need to be done before this patch could be accepted?

It seems easy enough to check if the device is active and it's very
common for drivers to do this (wm8994 has an example) - for most uses
you should be able to check pm_runtime_is_enabled() and there should
just be a single bitfield you can look at to figure out if jack
detection was running.  Looking at the extcon driver briefly
ARIZONA_JD1_ENA looks hopeful.

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