Problematic Set TR Deq error handling series in xhci-next

["Michał Pecio" <michal.pecio@gmail.com>]

Hi,

I noticed that xhci/for-usb-next now includes a series which tries
to handle Set TR Deq errors. It strikes me as a solution looking for
a problem, and frankly creating new problems where none existed ;)

I am aware of three cases leading to errors being handled here, and
none of them is addressed. One is harmless and easy to fix properly,
but this series appears to turn it into a "never give back the URB"
disaster. Tests pending, I hope to find some time this weekend.

There should be no need to handle these errors, they are prevented
by not queuing the command in wrong states. When the command fails,
it means the driver screwed up tracking endpoint state and other
things are on fire too, so the actual bug should be fixed instead.

The case of disabled endpoints is clear: no URBs are allowed, the
core is broken. It would be more productive to sanity-check core:
detect and nuke lingering URBs in places like endpoint_disable(),
drop_endpoint(), reset_device(), free_dev(). If Set Deq is already
pending at the time, give back the URB and let the command fail.

The case of "stopped" should outright never happen, we don't queue
Stop Endpoint if Set TR Deq is pending. It triggers a known HW bug,
so it's a bug. Note that this series already assumes that Stop EP
isn't pending when it queues a new one.

The case of "running" (or "halted", which "running" can morth into)
is possibly more useful, because we assume it's caused by illegal
state changes without driver's knowledge. But these are supposed to
be detected and fixed by handle_cmd_stop_ep(), because they cause
other problems too. It's unclear if retrying Stop Endpoint and Set
TR Deq again will solve any case not solved yet, but risk exists of
infinite retries on broken HW. (And HW is broken if we are here).

Queuing a Soft Retry and then doing Set TR Deq out of the halted TD
instead of restarting the ring is a weird thing to do and IDK if HW
will get it right. IIRC, some ASMedia had issues in similar cases:
it would retry the TD anyway, despite Set TR Deq.

The case of command TRB error looks wrong too. AFAIK, bad stream
ID only halts the endpoint if it's in a packet from the device. The
command just fails. And find_halted_td() will crash on Streams EPs.

TRB error also happens on ASMedia HCs under unclear circumstances.
It's either an HC bug, or (totally guessing) maybe a way the HC is
telling us that the target stream is the Current Stream, forbidden
by the spec. It only seems to happen with some UAS chips, and same
chips also have issues (but no TRB errors) on other HCs. If anyone
with access to the UAS spec (paywall) and a USB packet analyzer
would like to debug it, I can provide detailed repro instructions. 

Regards,
Michal