[Ksummit-2008-discuss] Tracking of regressions and suspend/resume of devices
benh at kernel.crashing.org
Sun Jun 1 16:50:46 PDT 2008
> documentation only goes so far...
> We can do other things to make suspend/resume more robust in drivers.
> Example: For NIC drivers, we could have a library helper function or something
> that calls the drivers suspend method on "ifconfig down", and resume on going back up.
> The need for a library function comes from the unfortunate corner case that you
> can only do this after, say, 10 seconds, to avoid stupid dhcp clients from bouncing
> the physical link all the time.
I totally agree.
> This would make sure the suspend/resume methods get tested a lot, and in addition,
> there is a ton of overlap right now between "down" and "suspend", since both do
> pretty much equivalent power management steps.
There are some subtle differences when things like WOL get into play,
but overall, I tend to agree. down could do a suspend after a time
threshold (and rmmod needs a lib call to make that complete of course).
network is actually not the hardest case. In most case ,even, the main
driver request path isn't the hardest thing to do deal with. The pain
starts with random ioctl's and sysfs "store" functions that are supposed
to have HW side effects and whack a sleeping drivers, and more
specifically, the locking requirements to plug those holes.
More information about the Ksummit-2008-discuss