On Thu, 21 Oct 2010, Sarah Sharp wrote: > 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? The ep0 maxpacket value is 32. > > > 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. Do you _know_ that the Evaluate Context command will fail? Maybe everything will work... 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
