On 09.06.2015 14:43, David Laight wrote:
> From: Mathias Nyman
>> Now including Renesas uPD720201 we got four xhci vendors that return
>> Success instead of short transfer when there are still unstraferred bytes
>> left. The driver anyway checks the untransferred bytes and suggest adding
>> the quirk if needed, so we can as well make it default behavior and get
>> rid of the quirk all together.
> ...
>> @@ -2114,14 +2114,13 @@ static int process_bulk_intr_td(struct xhci_hcd
>> *xhci, struct xhci_td *td,
>> /* Double check that the HW transferred everything. */
>> if (event_trb != td->last_trb ||
>> EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) != 0) {
>> - xhci_warn(xhci, "WARN Successful completion "
>> - "on short TX\n");
>> + xhci_warn(xhci, "WARN Successful completion on short
>> TX\n");
>
> You really don't want to output that message at all.
>
> Even with the old code it was very confusing because it looks like an
> an issue with the xhci controller sending data.
>
Here we can keep it because if we hit this codepath something weird is going on.
process_bulk_intr_td() is called by handle_tx_event(), which already checks
for a successful completion on short transfers, and changes the completion
from COMP_SUCCESS to COMP_SHORT_TX
I removed outputting the message from handle_tx_events()
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
