Re: [PATCH] i2c/tegra: I2C driver uses thesuspend_noirq/resume_noirq

[Mark Brown]

On Thu, 2011-08-11 at 14:43 -0700, Colin Cross wrote:
> On Thu, Aug 11, 2011 at 2:09 PM, Stephen Warren <swarren@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/