linux-kernel - Re: [PATCH v2 20/28] ARM: tegra: cpufreq: Disable cpufreq during suspend

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:	Mon, 24 Jan 2011 10:50:53 -0800
From:	Colin Cross <ccross@...roid.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	linux-tegra@...r.kernel.org, Russell King <linux@....linux.org.uk>,
	konkers@...roid.com, linux-kernel@...r.kernel.org, olof@...om.net,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 20/28] ARM: tegra: cpufreq: Disable cpufreq during suspend

On Mon, Jan 24, 2011 at 6:41 AM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Sun, Jan 23, 2011 at 06:01:25PM -0800, Colin Cross wrote:
>> Adds a SUSPEND_PREPARE notification hook to drop the frequency to
>> the lowest possible during suspend.  This prevents the cpufreq driver
>> from attempting regulator calls after suspend has started - the
>> regulator api can call into drivers that have already been suspended.
>
> Hrm, what's the situation where that happens and why does it cause
> problems?  The regulator API doesn't care if suspend is going on, and
> nor do any of the current drivers for regulators.  There is an issue
> with keeping things like I2C alive until the bitter end of suspend so
> you've got a control bus to the regulators but that's a generic issue
> which crops up with other subsystems too so a regulator-specific
> workaround seems dodgy.

The end result is that the regulator driver calls the i2c driver after
the i2c driver has been suspended.  On Tegra, this happens because of
voltage scaling on the CPU regulator, which can be on the i2c bus.  A
sleep in a suspend handler after the i2c bus has been suspended can
cause the cpufreq governor to lower the frequency, and try to lower
the voltage as well.

The problem isn't limited to i2c busses, there are some regulators on
spi busses.  You would need to ensure that any driver that has a
regulator consumer suspends before the regulator driver it
communicates with, and that still wouldn't fix cpufreq, which has a
sysdev suspend handler.

> The patch itself seems fine, it's just that it feels like there's
> something else going on.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/