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: <20210630130425.GF5106@sirena.org.uk>
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ