Alan Stern wrote:
What is the cause of all these problems relating to device resetting and probing?
IMO the root cause was an assumption that there'd be only one config, or at least only one usable. There are a number of assumptions inside usbcore which turn up trouble when changing device configurations or interface altsettings, including the case of "change back to current config" (a.k.a. reset).
What is the proper conceptual model for a reset? Should it appear to the core essentially the same as a disconnect swiftly followed by an attach?
The "proper" model doesn't exist yet, IMO ... there are currently some assumptions in the reset code (see above). I think what's desired by reset callers is basically "re-enumerate into the current configuration" ... expecting that it'll help clear out cobwebs of device state that for various reasons (bugs) aren't cleared out by less drastic operations.
On a slightly different but related note, who gets to decide which configuration a device should use?
Typically it's decided by khubd choosing the default (first) config. So long as there's only one config, that's clearly correct. But we've discussed this before, and I think there was agreement that userland should be able to override that. Ideally, just by writing to the sysfs bConfigurationValue file ... by some code that takes into consideration power consumprion and desired functionality. - Dave ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
