On Wed, 11 May 2005, David Brownell wrote: > > However the way you're using resume_root_hub doesn't > > match what I had in mind when it was originally written. > > However it's what I had in mind when I agreed with you that such code > would be useful, and it did pass the basic sysfs-induced test scenarios > with USB_SUSPEND defined.
> > 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. > > And that'd explain why it worked in light testing with USB_SUSPEND. > > But ... if it doesn't work without USB_SUSPEND, then what would be > the point of such a routine? > See above ... I thought the whole point of that routine was to > help that resume-from-autosuspend case. At least I did when the > idea originally came up ... in conjunction with the timer fixes, > an autosuspended root hub could finally do a "real suspend" from > the usbcore POV. That wasn't the point. Quite the opposite. The point was to help with remote wakeup from a selective (non-auto) suspend. In greater detail, usb_hcd_resume_root_hub is intended to help a "usbcore"-suspended root hub that wants to resume. It provides a process context (khubd) for calling usb_resume_device without the need for schedule_work and without the danger of racing with unregister_root_hub. It was never intended for situations that didn't need a process context or where the root hub had been (auto)suspended without calling through usb_suspend_device. My feeling was (a) if the root hub was suspended without calling usb_suspend_device then there was no need for calling usb_resume_device to resume, and (b) if autosuspend didn't need a process context then neither does autoresume. From these it follow that if USB_SUSPEND isn't set then resume_root_hub simply isn't needed. As far as helping root hubs do a real "usbcore" suspend... I don't see that as necessary. Certainly not now. Eventually the hub driver (or some power domain container manager) will learn to do its own autosuspend; then it will automatically use usb_suspend_device and the HCDs won't have to worry about it at all. > When the transition can be atomic -- e.g. use only an internal > spinlock -- that can work. But supporting the USB_SUSPEND=n > case does make complications ... though even with USB_SUSPEND, > there could still be a need to wait for URBs to be reported > back from the HC after all drivers suspend. For now, I'm not > willing to have separate and subtly different suspend codepaths. In UHCI the paths aren't separate. There's a single suspend routine that gets called for both types of suspend. The only difference is that when doing an autosuspend the routine skips over a time-consuming delay. It's known that the delay isn't needed because no devices are attached during autosuspend. Of course that routine will get called from separate places depending on the type of suspend, but presumably you won't object to that. > > 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. > > Once we change the policy and make resume not recurse, that > will become so. Remote wakeup logic should handle whatever > recursion is truly necessary. In a sense it's always been my policy that autoresume isn't recursive. Largely because UHCI autosuspends only when no devices are attached -- it won't autosuspend if a device is attached and suspended. But even if it did, there wouldn't be any need for autoresume recursion because remote wakeup logic takes care of all that, as you said. In fact, with my as507 patch that removed all the resume recursion (except for resuming interfaces along with devices) the remote wakeup logic did exactly what it was supposed to. No explicit recursion was needed. 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
