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:	Fri, 12 Aug 2011 09:18:16 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Stephen Warren <swarren@...dia.com>
Cc:	Colin Cross <ccross@...gle.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, 2011-08-11 at 14:09 -0700, Stephen Warren wrote:
> Colin Cross wrote at Thursday, August 11, 2011 2:51 PM:

> 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

He didn't like either, I think - he felt that probe ordering should be
sufficient. Which is true within the device model, in that devices can't
probe until all their resources are ready. This is coming up for ASoC
because that mechanism just doesn't work at all for us an we have to
work around it.

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

Our current mechanism is based entirely on the order in which things get
instantiated so depending on the implementation of deferred binding we
may be able to change the ordering of the dpm_list.

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