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
| ||
|
Date: Tue, 14 Jun 2022 09:47:43 +0000 From: "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com> To: Mark Brown <broonie@...nel.org>, Martin Kepplinger <martin.kepplinger@...i.sm> CC: "lgirdwood@...il.com" <lgirdwood@...il.com>, "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? On 6/14/22 12:18, Mark Brown wrote: > On Tue, Jun 14, 2022 at 11:06:06AM +0200, Martin Kepplinger wrote: > >> 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... >> >> Why does power domain only implement resume_noirq? How could I untangle >> this? > > Indeed - if a power domain is controlling regulators then I'd not expect > things to go well if it tries to resume without interrupts, there will > be some things that can be done purely with GPIOs but that's depending > on the hardware having wired things up that way and the operations > needed by the power domain mapping well onto what can be done with > GPIOs. In case of BD71837 only the PMIC 'state changes' could be initiated by GPIO. And if the state is not 'RUN' the regulator enable/disable state can not be controlled by the Linux driver (or - as far as I remember the driver I've authored does not support that. It _may_ be there were enable/disable register for IDLE/SUSPEND states for _some_ of the BD71837 regulators. Some probably had fixed states. In any case, I don't think the driver touched them after initial setup). 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 ~~
Powered by blists - more mailing lists