On Thu, 7 May 2009, Sarah Sharp wrote: > > > Although it would be a layering violation, can we make these drivers > > > change the values in the usb_endpoint_descriptor, in the same way that > > > the descriptor parser in config.c does? > > > > Yes, that would work for those drivers. > > > > However, I am by no means sure these are the only drivers who do this. > > They are just the only ones I know. I'll look, but not today. > > There are several drivers that set the interrupt endpoint to something > other than the interval in the endpoint descriptor: > - drivers/hid/usbhid/hid-core.c has a quirk for HS devices that > advertise the bInterval in frames, rather than microframes. It > multiplies the interval by 8. > - drivers/net/usb/rtl8150.c sets it to 100 > - drivers/net/usb/usbnet.c sets it to 7 if it's a HS device, or 3 > - drivers/net/wireless/zd1211rw/zd_usb.c also sets it based on speed, > either 4 (HS), 10 (LS), or 1 (FS) > - drivers/staging/go7007/go7007-usb.c sets it to 8 > - drivers/staging/line6/driver.c uses bInterval, unless it can't find > the endpoint it expects at endpoint 0x82. Then it falls back to an > interval of 10. > - drivers/staging/winbond/wb35tx.c sets it to 32 > - drivers/usb/atm/cxacru.c sets the IN interval to 1 and the OUT to 4 > - drivers/usb/atm/speedtch.c sets it to 50 > - drivers/usb/serial/kobil_sct.c sets it to 8 > - drivers/media/video/se401.c sets it to 8 > - drivers/media/video/usbvideo/quickcam_messenger.c sets it to 16 > - drivers/net/usb/pegasus.c grabs the interval out of the device's > EPROM, which makes me twitch. > - sound/usb/usx2y/usbusx2y.c sets it to 10 > > Of course, some of those intervals may actually be the endpoint's > bInterval, hard-coded by the driver writer. I can't tell without the > device descriptors. > > And then there are the drivers that set the interval to 1: > - drivers/usb/misc/appledisplay.c > - drivers/bluetooth/bcm203x.c > - drivers/bluetooth/bpa10x.c > - drivers/input/mouse/appletouch.c > - drivers/media/dvb/ttusb-dec/ttusb_dec.c > - drivers/media/video/au0828/au0828-video.c > - drivers/media/video/cx231xx/cx231xx-core.c > - drivers/media/video/em28xx/em28xx-core.c > - drivers/net/irda/kingsun-sir.c > - drivers/net/usb/catc.c > - drivers/net/wireless/ar9170/usb.c > - drivers/staging/otus/wwrap.c > - sound/usb/usbmidi.c if it finds a low speed device that doesn't have > an interrupt endpoint, it attempts to use the bulk endpoint as > interrupt. > > 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.) > 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. Alan Stern -- 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
