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]

Message-ID: <CAMbhsRR2+bhpjhGfUSt9M5tDk1EW2d70yC-tZy27zEgVqtkfSg@mail.gmail.com>
Date:	Thu, 11 Aug 2011 13:51:08 -0700
From:	Colin Cross <ccross@...gle.com>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Ben Dooks <ben-linux@...ff.org>, Dilan Lee <dilee@...dia.com>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] i2c/tegra: I2C driver uses the suspend_noirq/resume_noirq

On Thu, Aug 11, 2011 at 12:35 PM, Stephen Warren <swarren@...dia.com> wrote:
> Mark Brown wrote at Saturday, August 06, 2011 2:48 AM:
>> On Fri, Aug 05, 2011 at 09:33:31PM -0700, Colin Cross wrote:
> ...
>> > 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.
>
> Colin, given Mark's explanation, are you OK with the patch now?

It's still not the right way to handle this, are you going to mark
every I2C controller as suspend_noirq?  What happens when you find an
I2C controller that needs its irq on to suspend?  These are the kinds
of hacks we've been asked not to do in ARM, so I'd like to see a
response from the I2C maintainers.
--
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/