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: <CAMbhsRShLvyc2XKJAL8PwR0Uj4Pnp9rVt7QyK1qAVxJ-R2PSdQ@mail.gmail.com>
Date:	Thu, 11 Aug 2011 19:59:27 -0700
From:	Colin Cross <ccross@...gle.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.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, Aug 11, 2011 at 5:45 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> 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.

You can't just move everything after the card, you have to move
everything after the last device that was probed, and it only works if
nothing depends on any of the devices that are moved.

> 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-tegra" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
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/