On Thu, Oct 21, 2010 at 01:22:45PM -0400, Alan Stern wrote: > 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: > > > > 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... I don't _know_ the command will fail, but the NEC host does a lot of checking of the input from the driver, so it wouldn't surprise me if it did fail. Or the host controller could just lock up on the illegal input, all other devices would cease to work, and the host would stop sending any interrupts with no change to the host error bits. That failure mode happened when the NEC 0.95 host didn't like the way the driver set the chain bit on the link TRB. If someone wants to try this device under an xHCI host controller, I'd be happy to make a patch. Otherwise I don't want to risk causing the xHCI host to lock up. 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
