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] [day] [month] [year] [list]
Date:   Mon, 15 Jun 2020 17:37:35 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Saravana Kannan <saravanak@...gle.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        John Stultz <john.stultz@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>
Subject: Re: [PATCH v2 2/2] regulator: Add support for sync_state() callbacks

On Mon, 15 Jun 2020 at 13:49, Mark Brown <broonie@...nel.org> wrote:
>
> On Mon, Jun 15, 2020 at 12:27:23PM +0200, Ulf Hansson wrote:
>
> > eMMC is not only about voltage levels, but also about enable/disable
> > of the regulator(s).
>
> > More precisely, one needs to follow the steps specified in the eMMC
> > spec, when disabling the regulator(s).
>
> > In other words, the mmc host driver needs to be probed (consumer of
> > the regulator), before the regulator(s) can be disabled.
>
> Right, though you can generally get away with it if you completely cut
> the power.

Well, there are two regulators.

One is the VCC (vmmc) the other is VCCQ (vqmmc). If you can cut both,
yes, then you are right. However, quite often VCCQ (the rail for the
I/O voltage) is an always-on regulator.

Moreover, even if you can cut both regulators, I wouldn't do that,
unless really necessary. It's always better with a graceful power-off
sequence of a storage device, as otherwise flash corruption and other
bad things can more easily happen.

> The big thing is that as part of this we need to actually do
> the things at the time the driver asks for them to be done rather than
> some other time.

Right.

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ