On Mon, 28 Jun 2004, David Brownell wrote: > >>Hmm, I see. Tradeoff time. I'd say take whichever causes > >>least impact to device drivers ... didn't you originally > >>suggest taking the device out of suspend before unbind? :) > > > > > > I don't remember suggesting that. It isn't practical if there are any > > suspended hubs between the root and the device. My preference goes to > > installing altsetting 0 as soon as possible, which means when the device > > resumes. There could just be a little loop in one of the resume() > > routines that looks for unbound interfaces not in altsetting 0. > > Why wouldn't it be practical -- locking?
Only because you would have to wake up all the intermediate hubs as well. And then you would probably want to suspend them again afterward. Waiting until the device resumes seems a lot easier. > > But the HCDs already have "reset" and "start" methods, and they don't have > > a "restart" method. One would have to be added to each HCD. The major > > new feature would be that the root hub has to survive the "restart" > > process; you couldn't delete it and then create a new one. > > The only reason for a new method would then be preserving the root hub. > Why would that be important? (Other than avoiding that self-deadlock > in the PM code, which is just a bug.) By definition, usb_reset_device() doesn't delete the device, unless the reset fails or the descriptors change. And even then, the device isn't deleted until after usb_reset_device() returns. If you wanted, it would possible to make usb_reset_device() on a root hub return -ENODEV while setting up a schedule_work thingy to call the HCD's stop, reset, and stop routines. A lot like usb_hc_died() and hcd_panic(), maybe even combined with them. Doing things that way would probably rule out any possibility of maintaining the root hub's connections across the reset. Not that we can do this now, but we might want to be able to. I can imagine a situation where resetting a hub first notifies the drivers for all the child devices that a reset is impending, and afterwards khubd realizes that all the new connections are actually just the old devices. (We could almost do all that now, if we restricted to notifying only child hubs rather than all child devices -- to everything else this would look like an unsolicited reset.) It's not nearly so easy to make that work if the hub is deleted rather than reset. > OK. I was just trying to be accomodating ... and I've not yet digested > all of those much-anticipated patches, anyway! :) The later ones haven't even been merged yet. Alan Stern ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
