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 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? 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
