I thought there was some reason why the code didn't already trust the length. I even made a comment to the fact that the system already tells me that its needed, so my patch to turn it on seems silly. I just assumed there was a reason it didn't trust it and printed a message asking if it should. On Mon, Aug 11, 2014 at 9:42 AM, Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> wrote: > 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
