On Mon, 9 May 2005, David Brownell wrote: > On Monday 09 May 2005 2:22 pm, Alan Stern wrote: > > > > > The code still isn't quite right because the root hub doesn't > > > > automatically resume. I haven't tried to track down the reason, but > > > > maybe > > > > replacing the schedule_work() call with usb_hcd_resume_root_hub() would > > > > help. (That replacement should be made in any case.) > > I was just looking at that in conjunction with a different issue, > and I noticed a glitch: it's conditionalized for USB_SUSPEND > (which implies PM) not just PM, but autosuspend kicks in with PM. > > This patch does that conversion, and it also has the other tweak. > Worked for me ... you?
Hmmm... There's a couple of problems with this. Not with the tweak; I won't have a chance to test that for a few days but there's no reason to think it won't work. However the way you're using resume_root_hub doesn't match what I had in mind when it was originally written. No doubt the problem was caused at least in part by insufficient documentation. These are tricky matters, and it's hard to write things down in a form that everyone will understand. The short explanation is that resume_root_hub does a "usbcore" resume, not just a "root hub" resume. I'll skip the details. Suffice it to say that when khubd sees the resume_root_hub flag, it fulfills the request by calling usb_resume_device. That's why the code was conditioned on USB_SUSPEND -- because otherwise usb_resume_device doesn't do anything. Arguably khubd should call the HCD's hub_resume method directly when USB_SUSPEND isn't configured. Right now it doesn't, so your patch won't work as expected in that case. The second issue, which might or might not be a problem, is that your patch calls resume_root_hub to resume from an autosuspend, i.e., a situation where the root hub was suspended without going through usb_suspend_device. So it's not at all clear whether using usb_resume_device to wake up is a good idea. (More honestly, it is clear that it's not a good idea!) These two issues are somewhat related, and the underlying theme is the need to support autosuspend even when CONFIG_USB_SUSPEND is off. If you changed the way the driver does autosuspend then the issues could be avoided. For instance, the UHCI driver makes both autosuspend and autoresume completely transparent to usbcore. It doesn't change any externally visible flags, it doesn't even lock the root hub device while making the transitions! And since it knows there are no USB devices listening it can avoid doing lengthy signalling during the transitions, so they take place entirely in_interrupt. Hence there's no need for a process context and no need for resume_root_hub. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
