On 08/11/2014 02:15 PM, David Laight wrote: > From: Behalf Of Evan Langlois >> Sorry if this is answered somewhere, but I couldn't find anything >> specific on Google as far as how to determine if this quirk is needed >> or if its configurable at boot/run-time. Its an HP laptop, and it >> looks like other HP models have the problem. >> >> I most often get this when turning on a USB TV Tuner, which is also HP >> branded but shows up as a Hauppage device. I get glitches on the TV >> output, less with tvtime than other viewers, and these glitches go >> away if I transcode a DVD while watching TV .. yeah, I know that makes >> no sense. Not sure if the glitches are related to the dmesg warnings. >> >> I'll attach the lspci to the message in case anyone needs it. Please >> advise on the next step to proceed. >> >> I'm running a Ubuntu kernel, but I imagine a stock kernel would react >> the same. uname -a ... >> Linux Taro 3.13.0-32-lowlatency #57-Ubuntu SMP PREEMPT Tue Jul 15 >> 04:08:59 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux >> >> dmesg output .... (all the repeats deleted) ... >> [270905.416782] xhci_hcd 0000:00:10.0: WARN Successful completion on >> short TX: needs XHCI_TRUST_TX_LENGTH quirk? > > Given that the code always checks the receive transfer length (in order > to output the message), maybe the code should be refactored to always > use the receive transfer length and the quirk removed. > > I doubt there are any controllers that write a non-zero 'residual' > byte count at the end of a full transfer. > I think that sounds like an idea. I got a quirk patch for this controller waiting already, but in case we hit this again with some other controller vendor then this change could be made. -Mathias -- 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
