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: <20191118164101.GA7894@lst.de>
Date:   Mon, 18 Nov 2019 17:41:01 +0100
From:   Torsten Duwe <duwe@....de>
To:     Mark Brown <broonie@...nel.org>
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 12:46:54PM +0000, Mark Brown wrote:
> 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:
> 
> > 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.

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?

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

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

Any hints welcome,

	Torsten