> Date: Fri, 19 Aug 2005 14:13:08 -0400 (EDT) > From: Alan Stern <[EMAIL PROTECTED]> > > There was a discussion about this a while back, but I can't locate the > messages in the archives or remember what the objections were.
The only objections I recall were "someone needs to make the time to change this" and "someone needs to make a device on which this can be tested". :) > Would there be a problem if the choose_configuration routine was changed > to avoid configs that exceed the parent hub's power budget? Not at all. We've long known this issue would need attention, and I seem to recall a FIXME on that very point ... We ought to be fine now also with a choose_configuration() outcome that leaves the device unconfigured ... e.g. because even though the hub managed to enumerate this device with only 50 mA power left unbudgeted, an active config would draw 100mA. > This problem > was just reported on linux-usb-users: The device has both a high-power and > a low-power config, the high-power one is chosen because it is listed > first, and it causes an overcurrent condition (taking down two or three > other USB devices along with it) when plugged into a low-power hub. > > > On a more theoretical note, it would be logical to move the configuration > selection and installation code from where it is now (under > usb_new_device) into the usb_generic probe routine. In a sense, that's > the main function carried out when a new device is discovered. And now > that there is code to deconfigure devices when they are unbound from > usb_generic, for symmetry they should be reconfigured when they are > rebound. Yes, I've had that thought too. That particular "theory" is nice since it should simplify the structure of the enumeration code. Maybe one day that can all become more obvious and simple. :) > Practically speaking, this may not be worthwhile. I don't expect people > to go around unbinding and rebinding usb_generic very often. Moving the > code like that would end up accomplishing little more than increasing the > stack usage. Greg, what do you think? > > (Oh yes, if we proceed this way then at some point usb_device_match should > be changed so that usb_generic always matches against devices and other > drivers only match against interfaces. Right now it doesn't take account > of the possibility that usb_generic might be unbound or reprobed.) I'm not sure what you mean by "match against devices" ... ignore flags that say to look at interface class/subclass/protocol?? - Dave > > Alan Stern > > lines 1-38/38 (END) ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
