On Thu, 2007-04-12 at 12:16 +0200, Pavel Machek wrote: > Adding platform hook to disable interrupts just because we need one > platform device last is not nice, either. (And does decrementer even > need to come last?) > > Anyway, platform devices may need specific ordering on more than power > pc, so perhaps we should just make ordering more stable so that > relying on it is no longer a hack? It would be pretty hard to do cleanly without raping the core driver suspend/resume core. I have experience implementing suspend/resume in all sorts of environments, and I do strongly beleive that an arch hook right at this point will be useful to more than that anyway. There are actions the arch code might need to take after drivers and before going to "atomic" mode (irqs off mean you can no longer sleep or take semaphores etc...), and in a similar vein, actions to take on resume just after interrupts are back and before all the drivers get woken up. The decrementer is one example, there might be other processor specific bits or arch specific bits that are better done at that stage. I think the way to go for 2.6.22 is to have that hook unless you can propose me a way to cleanly provide a platform device that is guaranteed to suspend last and resume first in all cases (and even then, I wouldn't be that happy since the proper decrementer stop procedure involves really wrapping the "irqs off" operation). Why not give this added flexibility ? Archs who don't care don't need to bother and it will make us happy... it's not like we are about to -add- burden to other architectures. Ben. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
