On Wednesday 14 June 2006 11:00 pm, Nigel Cunningham wrote: > Hi. > > On Thursday 15 June 2006 11:46, David Brownell wrote: > > On Wednesday 14 June 2006 4:57 pm, Pavel Machek wrote: > > > My point is that you really want the console enabled in writing phase > > > of suspend-to-disk. > > > > Notice how nicely this generalizes a point that's been made before: > > Linux should have the ability to exclude certain devices (and their > > parents) from that first "prepare to suspend" phase. Originally the > > canonical example was the swap device (and its disk, controller, bus > > tree, etc). Now we recognize consoles (and their parents, network > > controllers, etc) have the same issue ... > > Wouldn't it be simpler to say "We send the prepare_to_suspend/freeze/suspend > messages to all devices, but some have the nous to know to ignore them"? That's one potential solution, and one I thought about. But it has the conceptual problem that the PM framework code would be (wrongly) thinking the device is suspended; so it couldn't handle the parent/child relationships properly. (The parents of that still-"active" device would wrongly be allowed to suspend...) The approach of having a driver suspend() method understand things about the target system state is IMO just fine. In fact the original parameter of suspend() identified that system state ... but certainly pm_message_t does not. You may not have understood the point of the clk_must_disable() API I posted a while back, but what it's doing is exporting some essential information about that target state ... stuff that drivers need to know in order to support multiple system sleep (or run!) states. Certainly there's other data beyond clocking that could matter. - Dave
