On Wed, 24 Aug 2005, David Brownell wrote: > > 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". :)
Well, then maybe those objections will no longer apply! :-) > > 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 ... Yes indeed. My extremely vague memory of the last go-around is that it wasn't clear which config to accept, if more than one was applicable. Weeding out ones that aren't applicable (because they violate the power budget) should not be controversial. > 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. That can certainly go in at the same time. Okay, if there's no obvious reason why doing this would mess something up, I'll try to work on it. > > 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. :) Yeah... When the USB specification becomes 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?? Until now, usb_device_match has been called only for struct usb_interface's. There's never been any need to match drivers against a struct usb_device, because usb_device's are pre-bound to usb_generic. Now that the possibility of unbinding a usb_device exists, we have to take into account that usb_device_match might be called for a usb_device. It should be smart enough to know that a usb_device matches only against usb_generic and vice versa. This implies that somehow we need to know, given a struct device, whether it is embedded in a usb_device or in a usb_interface. Offhand I can't think of a reliable way of determining this. Maybe it will be best to store a magic value in the platform_data field; that shouldn't any cause problems seeing as how USB devices are never treated as platform devices. (Although in fact some of them _are_ platform devices, in the sense that they come built into the computer.) Alan Stern ------------------------------------------------------- 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
