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: <74CDBE0F657A3D45AFBB94109FB122FF04AEA24D09@HQMAIL01.nvidia.com>
Date:	Thu, 11 Aug 2011 14:09:03 -0700
From:	Stephen Warren <swarren@...dia.com>
To:	Colin Cross <ccross@...gle.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	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

Colin Cross wrote at Thursday, August 11, 2011 2:51 PM:
> Cc: Mark Brown; Ben Dooks; Dilan Lee; 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 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.

Well, while that's true, the thing is the right way to handle it doesn't
appear to exist at present.

I did briefly try to move the entire ASoC suspend to early suspend (or
something like that), but ran into a whole slew of issues, that I
unfortunately don't recall right now. That would also impact every user
of ASoC, not just Tegra...

So, in other words, how do you suggest I proceed with this?

Mark Brown wrote:
> 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,

Mark, can you fill in a little more detail; did Linus not like the concept
of drivers registering dependencies on each-other, or was there a problem
with the specific implementation that was proposed? I assume we're still a
long way away from anything like that working. You also mentioned Grant's
device registration retry stuff, but doesn't that only solve the initial
probing, not shutdown/suspend dependencies, or do devices take locks on
each-other to handle that too?

Thanks.

-- 
nvpubilc

--
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/