On 15.05.2015 17:30, Alan Stern wrote: > On Fri, 15 May 2015, Lu, Baolu wrote: > >> On 2015年05月14日 22:44, David Laight wrote: >>> From: Rodrigo Severo >>>> Sent: 14 May 2015 15:06 >>>> Activating XHCI_TRUST_TX_LENGTH on Renesas uPD720201 USB 3.0 hosts to get rid of >>>> the following warnings when using webcams on this type of host: >>>> >>>> xhci_hcd 0000:06:00.0: WARN Successful completion on short TX: needs >>>> XHCI_TRUST_TX_LENGTH quirk? >>> Given that the driver always reads the receive data length (in order >>> to output the message) is there any reason not to make the 'quirk' >>> the default behaviour? >> >> I don't think this is a default behavior. In this quirk case, xHC reports >> that it has completed a transfer _successfully_, but there are still some >> bytes _not_ transfered yet. >> >> Driver needs a hardware quirk to decide "which one should I trust, transfer >> completed successfully, or only part of data has been transfered?" >> >> If hardware completes a transfer successfully, it should set "Successful" >> to "completion code" and set "TRB transfer length" to 0. >> >> If hardware completes result in a short package transfer, it should set >> "Short Packet" to "completion code" and set "TRB transfer length" to the >> length of data that was not transmitted. > > The hardware _should_ do that, but we have seen examples of hardware > that does _not_ set the completion code correctly. > >> If hardware completes result in an error, it should set completion code >> as the error code and set "TRB transfer length" to the length of data that >> was not transmitted. > > Note that in each case, the hardware _does_ set "TRB transfer length" > to the length of data that was not transmitted. Even if it doesn't set > the completion code correctly. > > David's question (and I think it is a good question) is this: Why > doesn't xhci-hcd behave as though XHCI_TRUST_TX_LENGTH is _always_ set? > > Alan Stern > I think David pointed this out earlier as well, and now would be a good time to change the driver behavior. We now got 4 vendors using the quirk. I'll make a patch, removing the quirk, and perhaps add some debugging for the unlikely case of host marking a successful transfer as short with 0 bytes left. -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
