On Thu, 18 Jul 2013, Thomas Pugliese wrote: > Calling pm_runtime_get_noresume() instead of pm_runtime_disable() does the > trick. The root hub enumerates correctly and no longer thrashes > attempting bus_suspend/bus_resume. Good. > Moving forward, if I wanted to implement proper support for bus_suspend > and bus_resume in the HWA, what actions would be required when those > functions are called? I have a pretty good idea how to put the wireless > medium into a suspended state that is similar to wired USB suspend. I am > less clear on what needs to be done to the software state (URB tracking, > etc..) when bus_suspend is called. I apologize if this is already > documented somehwere. I did a fair amount of searching but could only > find info on device suspend not bus_suspend. It probably isn't documented anywhere. The USB core takes care of most of the work. By the time bus_suspend is called, no URBs are active. All you have to do is put the bus into the suspended state (with wired USB this means you have to turn off the Start Of Frame packets) and make the proper arrangements for enabling wakeup if the root hub's do_remote_wakeup bit is set. There may be other stuff related to managing the driver's private data structures; you must know about all that already. In wired USB, wakeup events include: port connect change (plug or unplug), port overcurrent change, and remote wakeup request received from a downstream device. In theory, remote wakeup requests are supposed to be treated as wakeup events even if the root hub's do_remote_wakeup bit isn't set, but not all hardware is capable of enabling those events without enabling the others as well. I don't know what qualifies as a wakeup event for wireless USB. The only tricky thing you may have to watch out for is the race between bus suspend and resuming a child. If one of the devices on the bus is in the middle of resuming, and if the root hub is supposed to be enabled for wakeup, then bus_suspend should fail with -EBUSY. After a runtime suspend of the bus, if you do get a wakeup event, you handle it by calling usb_hcd_resume_root_hub(). For system suspend, you have to make the appropriate platform-specific arrangements so that wakeup events will actually cause the system to wake up. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
