On Fri, May 08, 2009 at 10:00:10AM -0400, Alan Stern wrote: > > The drivers that set the interval to 1 must be setting it to the > > endpoint's bInterval, or else the core will set it to the minimum > > interval the endpoint supports. > > How do you reach that conclusion? > > Anyway, USB has no notion of a minimum interval supported by an > endpoint, only a maximum interval. (Except for low speed, where the > interval isn't supposed to be smaller than 10 -- probably in order to > avoid allocating too much bandwidth to a single endpoint.) I reached that conclusion because I misunderstood the bInterval field. You're correct, and it's a maximum time that the system needs to poll the device. So the drivers that set the interval to 1 would need to use the new API also. > > There are also three drivers that default to setting the interval to > > the endpoint's bInterval value, but export a module parameter that > > allows the interval to be configured at load time. Some of those > > drivers check to make sure that the module parameter interval isn't > > smaller than the interval the endpoint can handle, and some of them > > don't. > > - drivers/usb/misc/ldusb.c does check its module parameter. > > - drivers/usb/misc/legousbtower.c does not check. > > - drivers/usb/serial/cypress_m8.c does not check. > > - drivers/hid/usbhid/hid-core.c has a module parameter for mice only, > > and it does not check. I'm not sure if it's actually used, since > > drivers/hid/usbhid/usbmouse.c seems to use the endpoint interval. > > - drivers/staging/frontier/alphatrack.c does check. > > - drivers/staging/frontier/tranzport.c does check. > > > > And then there's all the userspace drivers that use usbfs. > > Usbfs always takes the interval value from the endpoint descriptor. > > > So there are 14 drivers that would need to change bInterval in the USB > > core's representation of the endpoint descriptor, and 6 that might need > > to. Is that too big a change? > > A better way to do this would be to add a new core routine for setting > an endpoint's interval. This routine would be callable only in process > context and only while there are no URBs queued for the endpoint. The > new value could be stored in the usb_host_endpoint structure instead of > messing up the descriptor. Then urb->interval could safely become an > output-only field. This would apply to Isochronous as well as to > Interrupt endpoints. This sounds reasonable. Should submit URB fail if the interval specified by the driver in the URB doesn't match the interval in the usb_host_endpoint structure? It would allow users to quickly catch any drivers that are missed by the conversion, but it's kind of mean to break user's devices. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
