On Fri, May 08, 2009 at 12:52:47AM +0200, Oliver Neukum wrote: > Am Freitag, 8. Mai 2009 00:49:10 schrieb Alan Stern: > > On Fri, 8 May 2009, Oliver Neukum wrote: > > > Am Donnerstag, 7. Mai 2009 20:47:47 schrieb Alan Stern: > > > > On Thu, 7 May 2009, Sarah Sharp wrote: > > > > > I'm working on adding interrupt transfer support to the xHCI host > > > > > controller driver, and I'm having a slight problem with device > > > > > drivers that submit an URB with a different interval than the > > > > > endpoint advertises. > > > > > > > > We don't really have a policy about that. As far as I know, no driver > > > > ever changes the interval from value in the endpoint descriptor. > > > > > > kaweth uses it to override buggy firmware, as do upcoming patches > > > for cdc-acm. > > > > 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. 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. 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? 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
