linux-kernel - Re: [PATCH] i2c/tegra: I2C driver uses the suspend_noirq/resume

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:	Sat, 6 Aug 2011 09:48:05 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Colin Cross <ccross@...gle.com>
Cc:	Stephen Warren <swarren@...dia.com>,
	Ben Dooks <ben-linux@...ff.org>, Dilan Lee <dilee@...dia.com>,
	linux-i2c@...r.kernel.org, linux-tegra@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i2c/tegra: I2C driver uses the
 suspend_noirq/resume_noirq

On Fri, Aug 05, 2011 at 09:33:31PM -0700, Colin Cross wrote:

Please delete unneeded context from e-mails, it makes it much easier to
find the content.

> NAK - moving the suspend order around is not the correct way to solve
> this.  If wm8903 needs to talk to the i2c bus in its suspend handler,
> it needs to be child device on the i2c bus.  suspend_noirq is for

WM8903 is an I2C device.  The problem is that it's suspended as part of
the ASoC suspend since the audio subsystem is composed of multiple
devices that all need to work together coherently.  I did start doing
some stuff to bodge around this like we do on probe but there are enough
system wide problems with this that it didn't seem worth the complexity
when the existing workarounds are so straightforward.

> devices that must suspend with system irqs turned off, not for
> ordering suspend handlers.

Unfortunately it's the only tool Linux has for dealing with this sort of
issue right now.  We were supposed to be getting support for telling the
PM core about dependencies but Linus didn't like that, and it's possible
Grant's stuff with allowing device binding to be retried to handle cross 
bus dependencies will help.  Right now the Linux model just doesn't have
any understanding of cross device dependencies other than control buses.

One other example of this is that you're also going to have the same
problem with PMICs - random devices on the system might want to control
their regulators as part of the suspend process and typically the PMIC
is going to be connected over I2C so it needs to be available for as
long as possible.
--
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/