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]

Date:   Mon, 18 Nov 2019 16:56:51 +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 Mon, Nov 18, 2019 at 05:41:01PM +0100, Torsten Duwe wrote:
> On Mon, Nov 18, 2019 at 12:46:54PM +0000, Mark Brown wrote:

> > 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.

> For me, this appeared first after upgrading from from 5.3.0-rc1 to 5.4.0-rc6.
> I guess the late initcall was executed before the regulator driver module got
> loaded? And now, with the 30s delay, the regulator driver is finally there?
> Would that explain it?

If the regulator driver wasn't loaded you'd not see the power off on
late init, yes.

> > 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.

> How exactly? I have been looking for deficiencies in the driver, but found
> devm_regulator_get() should actually do the right thing (use_count++). Is
> that correct, or am I missing something?

Regulators are enabled using the regulator_enable() call, if a driver
hasn't called that and isn't for something like cpufreq where the
regulator is expected to be always on then it should expect that power
may be removed at any time, even if the core didn't do this another
consumer sharing the supply could do the same.  It's perfectly possible
and normal for a driver to enable and disable a regulator at runtime,
for example for power saving.

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

> I was worried about the regulator core handing out refs to the dummy
> regulator when the requesting driver wants to change the voltages next.

I don't follow at all, if a driver is calling regulator_get() and
regulator_put() repeatedly at runtime around voltage changes then it
sounds like the driver is extremely broken.  Further, if a supply has a
regulator provided in device tree then a dummy regulator will never be
provided for it.  

> I concluded the requesting device driver would have to wait until the real
> regulator driver was registered. But either this somehow works or my eDP
> bridge is still powered on correctly from U-Boot. What does the warning
> "...  using dummy regulator" mean for the caller of regulator_get()?
> AFAICS the caller is then stuck with a reference to the dummy, correct?

If a dummy regulator has been provided then there is no possibility that
a real supply could be provided, there's not a firmware description of
one.  We use a dummy regulator to keep software working on the basis
that it's unlikely that the device can operate without power but lacking
any information on the regulator we can't actually control it.

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