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]

Message-ID: <20150316184518.GB23705@opensource.wolfsonmicro.com>
Date:	Mon, 16 Mar 2015 18:45:18 +0000
From:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To:	Mark Brown <broonie@...nel.org>
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 Mon, Mar 16, 2015 at 05:12:32PM +0000, Mark Brown wrote:
> On Mon, Mar 16, 2015 at 04:58:42PM +0000, Charles Keepax wrote:
> 
> > On the first boot of the wm5110 it is important the reset line is held
> > for slightly longer to ensure the device starts up well. This patch adds
> > a 5mS delay for this.
> 
> How can we tell what first boot is - what happens if the device is fully
> powered off during system suspend for example?  I'd expect to see this
> done for system resume as well if we don't know power was maintained (or
> whatever else the distinction is).

Internally the device has some state, so effectively we define
the first boot as the first time DCVDD is applied since either
the last physical reset or time the core_supplies were missing.

I think your suspend example is pretty tricky, we enable the
regulators for the core_supplies at boot, so I guess we have
requested that the system never removes those so if it does so
anyway perhaps that is a system problem? There isn't really
anyway to tell if they were removed, since we can't talk to the
CODEC without DCVDD (even if we could I don't think we can find
out) and we need to know before we power it up. Also presumably
if the system removed the regulator when we told it not to it
won't report anything through the regulator framework.

That would leave the only possible solution being a hard reset
during every runtime resume but that makes me very nervous about
the AoD interrupts as state for those would be lost upon that
reset.

All in all, I really struggle to see what more the driver could
do here.

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/