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:45:15 +0900
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-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:43 -0700, Colin Cross wrote:
> On Thu, Aug 11, 2011 at 2:09 PM, Stephen Warren <swarren@...dia.com> wrote:

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

> Yes, but the maintainers have been asked to stop using one-off hacks
> to fix everything that isn't supported in common code, and work
> towards getting the common code fixed instead.  If the common code
> maintainers say this is the best way to fix it for now, fine, but I'd
> like to hear an opinion first.

We've been through this quite a few times already at the driver core
level, mostly in the context of PMIC probing. Fixing this properly
requires some surgery on the core device model infrastructure which it's
not realistic to expect driver authors to implement.

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

> device_pm_move_after(deva, devb) makes should make deva suspend before
> devb.  Maybe subsystems that link multiple devices together should
> call device_pm_move_after() to make sure that all of their devices
> suspend before the parents of any of their devices?

This wouldn't be a robust solution for bus independent subsystems as it
doesn't maintain any sort of sorting - it just does a direct move so
it'll only capture the last dependency we saw. If you've got two
dependencies we could easily end up breaking things.

For example with ASoC we'd sort all the components before the ASoC card
without regard for their bus dependencies or any other dependencies they
have (eg, their regulators). Since the ASoC card is a platform device
it's likely to have registered early with no regard for where the buses
the card needs are registered. I'd expect there's a reasonable chance
it'll actually make things worse in the short term.

I'll mail Ted and see if we can get this on the topic for KS, it's
getting more and more serious.

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

Powered by blists - more mailing lists