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, 13 May 2015 12:09:15 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Ulf Hansson <ulf.hansson@...aro.org>, linux-mmc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, johan.rudholm@...s.com,
	adrian.hunter@...el.com, tim.kryger@...il.com,
	javier.martinez@...labora.co.uk, andrew_gabbasov@...tor.com,
	s.hauer@...gutronix.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] RFC: mmc: core: Increase delay for voltage to stabilize
 from 3.3V to 1.8V

On Tue, May 12, 2015 at 02:46:11PM -0700, Doug Anderson wrote:
> Since the regulator used for the SDMMC IO voltage is not expected to
> draw a lot of current, most systems will probably use an inexpensive
> LDO for it.  LDO regulators apparently have the feature that they
> don't actively drive the voltage down--they wait for other components
> in the system to drag the voltage down.  Thus they will transition
> faster under heavy loads and slower under light loads.

What a LDO is doing is basically just charging up a capacitor - the
regulation consists of monitoring the voltage on the capacitor and
opening a transistor to charge the capacitor when the voltage droops too
much.

> From experimental evidence, we've seen the voltage change fail if the
> card doesn't detect that the voltage fell to less than about 2.3V when
> we turn on the clock.  On one device (that admittedly had a 47K CMD
> pullup instead of a 10K CMD pullup) we saw that the voltage was just
> about 2.3V after 5ms and thus the voltage change would sometimes fail.
> Doubling the delay gave margin and made the voltage change work 100%
> of the time, despite the slightly weaker CMD pull.

> At the moment submitting this as an RFC patch since my problem _could_
> be fixed by increasing the pull strength (or using a smaller
> capacitor).  However being a little bit more lenient to strange
> hardware could also be a good thing.

Right, and this is probably going beyond the delays that the regulator
API is handling since it's not something the regulator hardware is
actively managing.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ