linux-kernel - Re: regulator: BD71837 PMIC resume during noirq phase?

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:   Tue, 14 Jun 2022 09:38:47 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     Martin Kepplinger <martin.kepplinger@...i.sm>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "broonie@...nel.org" <broonie@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        arm-soc <linux-arm-kernel@...ts.infradead.org>,
        Pengutronix Kernel Team <kernel@...gutronix.de>
Subject: Re: regulator: BD71837 PMIC resume during noirq phase?

Hi dee Ho Martin,

On 6/14/22 12:06, Martin Kepplinger wrote:
> hi Matti,
> 
> I heard you've been helpful in the past - thank for that!

I try to do what I can - It may not be much though :/

> Here's a
> question I'm currently stuck at: In short, imx8mq can't yet resume from
> suspend when using the bd71839 pmic via i2c. The original report here,
> just for the background:
> 
> https://lore.kernel.org/linux-arm-kernel/2d5d3bbec443742506e39488dbfbf724bb4ca93f.camel@puri.sm/T/#u

Oh. I've missed this one. (I'm not in CC - and no keywords like bd71837 
found => mail filters evaded)

> 
> But here's what I *think* is going on: When the (buck3) regulator from
> bd71839 is the power-supply for a power domain (gpu), the power domain
> driver can't resume because buck3 can't be enabled when the pmic isn't
> running yet.

My guess is that the buck enable is tried while the I2C is not yet 
functional. The BUCK3 (and AFAIR all of the regulators on BD71837) are 
controlled via I2C. There are no GPIO controlled regulators on BD71837(*)

(*)Well, you can control PMIC state with GPIO - which can be used to 
toggle all PMIC regulators to predefined ON/OFF/VOLTAGE states. (namely 
to SUSPEND, IDLE, RUN - don't remember all the dirty details though).

> I'm still a bit uncertain, but here's the logs when simply
> printing in the respective suspend/resume callbacks:
> 
> [  452.199600] bd718xx-pmic bd71837-pmic.2.auto: bd718xx_resume_noirq
> [  452.301450] imx-pgc imx-pgc-domain.5: failed to enable regulator: -
> ETIMEDOUT
> [  452.320593] imx-i2c 30a20000.i2c: i2c_imx_resume
> [  452.322152] bd718xx-pmic bd71837-pmic.2.auto: bd718xx_resume
> [  452.323853] imx-i2c 30a30000.i2c: i2c_imx_resume
> [  452.324778] imx-i2c 30a40000.i2c: i2c_imx_resume
> [  452.325017] imx-i2c 30a50000.i2c: i2c_imx_resume
> 
> and regulator_enable() in imx-pgc is called from genpd_resume_noirq().
> 
> At this point, does any workaround or fix come to your mind I could
> test? I guess i2c needs to be resumed too...

I think so too.

Best Regards
	-- Matti
-- 
The Linux Kernel guy at ROHM Semiconductors

Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~ this year is the year of a signature writers block ~~