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