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]

Date:   Wed, 30 Jun 2021 14:04:25 +0100
From:   Mark Brown <broonie@...nel.org>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
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

On Wed, Jun 30, 2021 at 02:29:02PM +0200, H. Nikolaus Schaller wrote:
> > Am 30.06.2021 um 14:13 schrieb Mark Brown <broonie@...nel.org>:

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

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

Why would LDO3 have a dependency on SPMS3 given what's written above and
how would that be circular?

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

Ah, I see - the issue is the intervening 1.8V regulator.  That's not a
circularity, that's the callout to a separate device in the middle of
the chain.  It's a super weird hardware design if the DT is accurate,
it's hard to see how it's not going to be hurting efficiency.  In any
case simplest thing would be to have separate MFD subdevices in Palmas
for the LDOs and DCDCs, that'll do the right thing.

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