On Mon, 20 Jan 2003, David Brownell wrote: > Oliver Neukum wrote: > > > So here's the list of things related to the core I remember so we can look > > at the issues and see which need attention before 2.6.0 > > > > - reseting during probe will deadlock > > - reseting through usbfs will not reprobe > > - usb_reset_device() and usb_set_configuration() race with probe() > > - bandwidth checking is broken > > > > Removals? Additions? Comments?
What is the cause of all these problems relating to device resetting and probing? Does reset sometimes result in a probe and other times not? Under what circumstances should this happen? 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? When a driver bound to one interface decides to reset the device, how should drivers bound to other interfaces be notified? Is calling their disconnect() and then probe() routines sufficient? Right now, this is relegated to the driver that does the reset; shouldn't it be centralized in the core? On a slightly different but related note, who gets to decide which configuration a device should use? Thanks for any explanations... Alan Stern ------------------------------------------------------- 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
