On Wed, 17 Jul 2013, Alan Stern wrote: > On Wed, 17 Jul 2013, Thomas Pugliese wrote: > > > On Wed, 17 Jul 2013, Alan Stern wrote: > > > > > On Wed, 17 Jul 2013, Thomas Pugliese wrote: > > > > > > > Hi, > > > > What is the expected behavior if a host controller does not implement > > > > bus_suspend and bus_resume? I am seeing that with the HWA HCD, kworker > > > > and khubd peg the CPU at 100% because the kernel is constantly calling > > > > hcd_bus_suspend and hcd_bus_resume. The calls to hcd_bus_suspend and > > > > hcd_bus_resume fail because hcd->bus_suspend and hcd->bus_resume are NULL. > > > > I have reproduced this behaviour using 3.11rc1 all the way back to 3.9.2. > > > > > > I think the expected behavior is close to what you described. :-) > > > > > > Seriously, AFAIK nobody thought about this case. To prevent this > > > problem, the HCD's start routine would have to disable runtime PM for > > > the root hub, by calling > > > > > > pm_runtime_disable(&hcd->self.root_hub.dev); > > > > > > Alan Stern > > > > > > > > > > Hi Alan. Thanks for the response. I tried your suggestion of calling > > pm_runtime_disable in the HCD start routine but this causes the set > > configuration request to fail on the root hub. The output looks like > > this: > > > > usb usb6: usb_probe_device > > usb usb6: configuration #1 chosen from 1 choice > > usb usb6: can't set config #1, error -13 > > Ah. Okay, I haven't tried to do this before; it's not surprising that > something would go wrong. > > > What appears to happen is that usb_set_configuration calls > > usb_autoresume_device which eventually results in a call to rpm_resume > > which fails with -EACCES. This causes usb_set_configuration to bail out. > > Is there a better place to call pm_runtime_disable that would allow the > > root hub to successfully start? > > Looks like a better way to prevent runtime PM is to make sure the usage > counter is always > 0. Calling pm_runtime_get_noresume() instead of > pm_runtime_disable() will accomplish this. > > If you're interested, the full set of runtime-PM calls relating to new > USB devices can be found in core/hub.c:usb_new_device(). > > Alan Stern > > 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. 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. Thanks, Tom -- 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
