On Thu, 22 Apr 2004, David Brownell wrote: > Alan Stern wrote: > > David: > > > > Do you think that once your latest khubd changes are applied we can get > > usb_reset_device() into working shape? The necessary changes won't be > > very large: > > Yes, I do think that. Some key parts are in the gadget-2.6 tree, > and I think you've listed the main remaining issues:
Those key parts are all contained within hub.c and usb.c, right? > > Rename usb_physical_reset_device to usb_reset_device (and > > get rid of the subroutine that currently has that name). > > > > Change the API to require that the caller holds the > > usbdev->serialize lock. > > > > Go through the various callers to make sure they really do > > hold the lock (usb-storage will need some changes but I can > > take care of them easily). > > Those three deltas (change API, make it stick) aren't in there, > but I agree they should be. Wasn't there an issue with SCSI too? > When probe() resets, dev->serialize is held, but otherwise not. > The clean fix was to make some other task scan for devices, after > a new SCSI host is added in the thread with the lock. That would certainly help and I think the SCSI folk are headed in that direction (triggering device scanning off a hotplug event), but I don't know how far they've gotten. > > Make the routine read the configuration descriptors and verify > > them against the raw descriptor values already in memory. > > This one's in the gadget-2.6 tree, along with an update to most of the > physical() reset code to make it use hub_port_init(). It's even been > tested on a DFU-ish device. > > > > We can even provide support for the "device morphed" case, simply by > > disabling the port. The khubd thread will see the enable-changed status > > sometime later and will initiate a disconnect and another port reset. > > While it's debatable whether this is the _best_ way to handle it, it ought > > to work. > > Hmm, that sounds right ... you were the one thinking about how > to make all that work, and that sounds like a good outcome. It's a roundabout technique, since it involves destroying and then re-creating the device structure and resetting the port twice. For now it should be good enough, though. > Feel like finishing that up, possibly starting with what's now > in the gadget-2.6 tree? Okay, once the current outstanding changes are installed. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
