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 -- 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
