On Fri, 17 Jun 2011, Andrey Rahmatullin wrote: > On Fri, Jun 17, 2011 at 11:17:01AM -0400, Alan Stern wrote: > > Okay, then you must have seen all the verbose PM debugging messages. > > Which means the last suspend callback to run was for the 1-1 device > > rather than the usb1 device, right? > > > > If so, it means I was looking in the wrong place. 1-1 is the internal > > rate-matching hub, whereas usb1 is the EHCI controller's root hub. > > > > Can you add your own dev_info() statements to the hub_quiesce() and > > hub_suspend() routines in drivers/usb/core/hub.c, or should I send a > > patch? > After "usb 1-1.1: usb suspend" I see a full "start hub_suspend, > hub_quiesce, rest of hub_suspend" path for 1-1:1.0 (I've used &intf->dev > in suspend and hub->intfdev in quiesce as a 1st arg for dev_info()), then > "usb 1-1: usb suspend" and after that it hangs. Ah, okay. I feel stupid; I should have realized that would happen. Anyway, the next place to look is in usb_port_suspend(), also in hub.c. If you want to go a few levels higher as well, usb_port_suspend() is called from generic_suspend() in generic.c. That routine, in turn, is called from usb_suspend_device() in driver.c -- udriver->suspend should always be equal to generic_suspend. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
