On Thu, Oct 21, 2010 at 10:08:43AM -0400, Alan Stern wrote: > On Wed, 20 Oct 2010, Sarah Sharp wrote: > > The xHCI driver has to communicate the max > > packet size to the host hardware, and the driver will update the control > > endpoint's max packet size once the descriptor is fetched. > > > > However, the code in xhci_urb_enqueue() to update the max packet size is > > only called if the device is running at full speed. So I think this > > buggy device will work fine under xHCI, but the control transfers will > > be broken up into 64-byte packets rather than whatever illegal size the > > device wanted. Do you know if this will be an issue? > > Certainly it will. The device doesn't accept 64-byte control packets; > the original bug report demonstrated that. Does it want control packets that are bigger or smaller than 64-bytes? What size does it want? > > I could change the xHCI driver to update the max packet size for > > non-full speed devices as well, but I'm not sure what the host hardware > > will do with an illegal value. It may just reject the Evaluate Context > > command, which would show up as a bunch of failed control transfers > > after the descriptor was fetched. > > That's okay. It means this non-compliant device simply won't work when > plugged into an xHCI controller, regardless of the OS. Not much we can > do about that. You might as well go ahead and make the change. If the device isn't going to work under xHCI, I don't see any benefit in changing the driver code. The device isn't going to fail any sooner. Either the Evaluate Context command will fail when the control transfer URB is submitted, or the URB itself will fail when the device doesn't like the length. Sarah -- 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
