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:   Fri, 15 Oct 2021 16:02:57 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc:     alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
        patches@...nsource.cirrus.com
Subject: Re: [PATCH 07/16] ASoC: cs42l42: Correct power-up sequence to match
 datasheet

On Fri, Oct 15, 2021 at 02:36:10PM +0100, Richard Fitzgerald wrote:
> The power-up sequence mandated in the datasheet is:

> - VP must turn on first
> - VA, VCP, VL, in any order
> - VD_FILT after VL

>  static const char *const cs42l42_supply_names[CS42L42_NUM_SUPPLIES] = {
> -	"VA",
>  	"VP",
> +	"VA",
>  	"VCP",
> -	"VD_FILT",
>  	"VL",
> +	"VD_FILT",
>  };

If you need the regulators to be turned on in sequence you shouldn't
rely on bulk enable doing it for you - the existing regulator code will
initiate all the enables in parallel and then wait for them all to
complete ramping up so if for example VD_FILT were to ramp more quickly
than the earlier regulators the hardware might notice it getting to
whatever voltage the hardware cares about before them.  The only
sequencing you're getting at the minute is when the enables for the
regulators are toggled and you shouldn't even rely on that.

To get the sequencing guaranteed you should pull VP and VD_FILT out of
the bulk enable and do individual enables for them.

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

Powered by blists - more mailing lists