Re: [linux-usb-devel] [patch/rft 2.6.17-rc2] swsusp resume must not device_suspend()

Alan Stern
2006-04-25T13:50:31Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1485 bytes --]

On Mon, 24 Apr 2006, David Brownell wrote:

> I've noticed a bunch of problem reports that go like this:
>
> - boot system with some USB devices attached
> - echo disk > /sys/power/state
> - ... later resume ...
> - now those USB devices don't work right
> - unplug them/replug them, all is OK
>
> I recently observed this myself and tracked down one problem. The solution
> involves what kexec() does in much the same situation: before starting a
> new kernel, most hardware needs to be reset. Today, swsusp will suspend it
> instead, which is the root cause of the problem.
>
> This seems like something that might need to sit in the MM tree for
> a while, as it's a longstanding bug and the fix could shake loose driver
> goofs. Luckily there's a partial workaround already in wide use: link
> drivers as modules if they use true suspend states (like all USB HCDs),
> don't link them statically into the kernel image.
>
> That workaround is partial because when BIOS takes over a controller, the
> resume() method has to handle that nasty case too! Last I checked, all
> the USB HCDs do handle that case; and few drivers other than those HCDs
> would ever need to worry about such issues.

We might have been able to avoid some of these problems with USB devices
if we had been a bit more careful. In particular, it wouldn't hurt to
have usb_resume_device() verify that the upstream port is enabled and not
suspended in the non-CONFIG_USB_SUSPEND case.

Alan Stern

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]