linux-kernel - Re: [PATCH] regulator: Defer init completion for a while after late

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: <20191118124654.GD9761@sirena.org.uk>
Date:   Mon, 18 Nov 2019 12:46:54 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Torsten Duwe <duwe@....de>
Cc:     Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH] regulator: Defer init completion for a while after
 late_initcall

On Sat, Nov 16, 2019 at 01:52:33PM +0100, Torsten Duwe wrote:
> On Wed, 4 Sep 2019 13:42:50 +0100 Mark Brown <broonie@...nel.org> wrote:

> > In the absence of any better idea just defer the powering off for 30s
> > after late_initcall(), this is obviously a hack but it should mask the
> > issue for now and it's no more arbitrary than late_initcall() itself.
> > Ideally we'd have some heuristics to detect if we're on an affected
> > system and tune or skip the delay appropriately, and there may be some
> > need for a command line option to be added.

> Am I the only one having problems with this change? I get

I've had no reports of any problems.

> [   11.917136] anx6345 0-0038: 0-0038 supply dvdd12-supply not found, using dummy regulator
> [   11.917174] axp20x-rsb sunxi-rsb-3a3: AXP20x variant AXP803 found

> Despite being loaded as a very early module, PMIC init ^^^ only starts now.

I'm very surprised that anything to do with resolving incomplete
constraints would be affected by this change.  The only thing we do in
the defered bit of init is power off unused regulators which has no
bearing on registration at all.  The only thing that might have a
bearing on this is marking the sytem as having full constraints but
that's still directly in the initcall, not deferred.

> But much later on

> [   38.248573] dcdc4: disabling
> [   38.268493] vcc-pd: disabling
> [   38.288446] vdd-edp: disabling

> screen goes dark and stays dark. Use count of the regulators is 0. I guess
> this is because the driver code had been returned the dummy instead?

This is not new behaviour, all this change did was delay this.  We've
been powering off unused regulators for a bit over a decade.

> It's a mobile device so in principle there is nothing wrong with powering
> down unused circuitry, and always-on is not an option.
> Am I correct to perceive this solution as not 100% mature yet? The anx6345

Like I say this is not in any way new and pretty stable.

> driver in particular needs to do a little "voltage dance" with specific
> timing on the real regulators should the device come up really unpowered,
> so IMHO it's probably neccessary to return EPROBE_DEFER at least in this
> particular case and prepare the driver for it? Or what would be the real
> solution in this case?

We power off regulators which aren't enabled by any driver and where we
have permission from the constraints to change the state.  If the
regulator can't be powered off then it should be flagged as always-on in
constraints, if a driver needs it the driver should be enabling the
regulator.

I don't folow what you're saying about probe deferral here at all,
sorry.

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