On Wed, Aug 24, 2011 at 10:31:27AM -0400, Alan Stern wrote: > On Wed, 24 Aug 2011, Michal Nazarewicz wrote: > > > On Tue, 23 Aug 2011 22:49:37 +0200, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> > > wrote: > > > Still, maybe I was wrong. Maybe it would be better to use the fastest > > > speed supported by at least one of the function drivers. The user can > > > always force a SuperSpeed-capable device to run at high speed by using > > > a USB-2 cable to plug it in. I'm not sure whether the user could force > > > such a device to run at full speed, however. > > > > I'm actually wondering whether we really need to worry about it. > > composite_driver has the “max_speed” field and I would just leave it as > > composite driver's author responsibility to put correct value there. > > > > One thing that could be worth doing is iterate over all the configurations > > and figure out if at least one supports the speed declared by “max_speed” > > and if not, lower it. > > That's the same as what I said: Use the highest speed supported by any > function driver. There really isn't any point in allowing connections > faster than that. And as Felipe pointed out, the user always has the > capability to force the connection to be slower, by using the right > sorts of cables and hubs. > > > Like I've said before, as additional functionality, composite.c could > > check if it's USB_SPEED_UNKWONW in which case it would look for the lowest > > speed that all the functions support. > > > > Such configuration would allow composite driver authors set the speed to > > USB_SPEED_SUPER when they mean “choose maximum speed at least one function > > supports” and to “USB_SPEED_UNKWONW” when they mean “choose maximum speed > > all the functions support”. > > > > Does that make sense? > > It's reasonable. Just be sure to document it properly; otherwise > nobody will understand or remember it! good point. I agree with this approach. -- balbi
Attachment:
signature.asc
Description: Digital signature
