linux-kernel - Re: [PATCH] regulator: palmas: set supply

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: <02EE05C2-588F-4D50-8A37-46CC3B0C302C@goldelico.com>
Date:   Wed, 30 Jun 2021 14:29:02 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Tony Lindgren <tony@...mide.com>,
        Graeme Gregory <gg@...mlogic.co.uk>,
        Liam Girdwood <lgirdwood@...il.com>,
        Nishanth Menon <nm@...com>,
        Linux-OMAP <linux-omap@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com,
        Peter Ujfalusi <peter.ujfalusi@...il.com>
Subject: Re: [PATCH] regulator: palmas: set supply_name after registering the
 regulator

> Am 30.06.2021 um 14:13 schrieb Mark Brown <broonie@...nel.org>:
> 
> On Tue, Jun 29, 2021 at 10:21:45PM +0200, H. Nikolaus Schaller wrote:
> 
>> There seems to be a deadlock in probing:
> 
>> 	e.g. ldo3_reg depends on vdds_1v8_main supply
>> 	vdds_1v8_main depends on smps7_reg supply
>> 	smps7_reg depends on vsys_cobra supply
>> 	vsys_cobra depends on nothing
> 
>> This would normally lead to a simple chain as you described above. But
>> ldo3_reg and smps7_reg share the same driver and can probe successfully or
>> fail only in common.
> 
> I don't see any deadlock there?  Just a straightforward set of
> dependencies.  Anything circular would clearly be a driver bug.

I think it could be indirectly circular since ldo3_reg does not find smps3
registered. But I have to run more tests with printk inserted.

So I am not sure if that is the issue but the best hypothesis I currently know of.

> 
>> Now if ldo3_reg defers probe through the new rule, smps7_reg is never
>> probed successfully because it is the same driver. Hence vdds_1v8_main can
>> not become available. And the Palmas continues to run in boot initialization
>> until some driver (MMC) wants to switch voltages or whatever.
> 
> The driver should just register all the DCDCs before the LDOs, then
> everything will sort itself out.

Basically the driver code does it that way. But fails. Probing seems to defer
until deferral limits (AFAIR there is a timer or counter in the probe deferral
queue) an does not succeed.

It only works if I disable the new condition - but apparently it suffices
to do so for the LDOs because I noticed that the smps initialization also
defines supply_name and there it is no problem to have it before
devm_regulator_register(). Every simple problem becomes complex if you look
deeper :)

Which I interpret (without additional tests) that the smps7_reg is registered
but does not pass the (new) test when asked by ldo3_reg.

>  It's *possible* you might see a system
> trying to link things together regulators of the same type but that's
> very unusual as it makes the system less efficient.

I can check that - and there may be other LDOs in the Palmas
chained (as described by device tree).

It will need some test time to get more factual information about this
issue besides that reverting the new rule or adding a trick to make
the Palmas driver initialize properly again.

BR and thanks,
Nikolaus