The USB "maximum-speed" property can now take the SSP signaling rate
generation and lane count with these new strings:

"super-speed-plus-gen2x2"
"super-speed-plus-gen2x1"
"super-speed-plus-gen1x2"

Introduce usb_get_maximum_ssp_rate() to parse for the corresponding
usb_ssp_rate enum. The original usb_get_maximum_speed() will return
USB_SPEED_SUPER_PLUS if it matches one of these new strings.
Signed-off-by: NThinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/f8ed896313d8cd8e2d2b540fc82db92b3ddf8a47.1611106162.git.Thinh.Nguyen@synopsys.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If you pass a string that is not terminated with a carriage return to
dev_err(), it will eventually be printed with a carriage return, but
not right away, since the kernel will wait for a pr_cont().
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210123142502.16980-4-paul@crapouillou.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove unused-but-set devctl variable.
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210123142502.16980-3-paul@crapouillou.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The 'request' variable is a pointer to the 'request' field of the
struct musb_request 'req' pointer. It only worked until now because
the 'request' field is the first one in the musb_request structure, but
as soon as that changes, the check will be invalid.

Fix it preventively by doing the NULL-check on the 'req' pointer
instead.
Suggested-by: NMaarten ter Huurne <maarten@treewalker.org>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210123142502.16980-2-paul@crapouillou.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

musb_queue_resume_work() would call the provided callback if the runtime
PM status was 'active'. Otherwise, it would enqueue the request if the
hardware was still suspended (musb->is_runtime_suspended is true).

This causes a race with the runtime PM handlers, as it is possible to be
in the case where the runtime PM status is not yet 'active', but the
hardware has been awaken (PM resume function has been called).

When hitting the race, the resume work was not enqueued, which probably
triggered other bugs further down the stack. For instance, a telnet
connection on Ingenic SoCs would result in a 50/50 chance of a
segmentation fault somewhere in the musb code.

Rework the code so that either we call the callback directly if
(musb->is_runtime_suspended == 0), or enqueue the query otherwise.

Fixes: ea2f35c0 ("usb: musb: Fix sleeping function called from invalid context for hdrc glue")
Cc: stable@vger.kernel.org # v4.9+
Tested-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210123142502.16980-1-paul@crapouillou.netSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This replaces the platform_device_add_properties() call with
the safer device_create_managed_software_node() that does
exactly the same, but can also guarantee that the lifetime
of the node that is created for the device is tied to the
lifetime of device itself.
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210204141711.53775-7-heikki.krogerus@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This replaces the platform_device_add_properties() call with
the safer device_create_managed_software_node() that does
exactly the same, but can also guarantee that the lifetime
of the node that is created for the device is tied to the
lifetime of device itself.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210204141711.53775-6-heikki.krogerus@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

At the moment the function device_del() is calling
device_remove_properties() unconditionally. That will result into the
reference count of the software node attached to the device being
decremented, and in most cases it will hit 0 at that point. So in
practice device_del() will unregister the software node attached to
the device, even if that was not the intention of the caller. Right
now software nodes can not be reused or shared because of that.

So device_del() can not unregister the software nodes unconditionally
like that. Unfortunately some of the users of device_add_properties()
are now relying on this behaviour. Because of that, and also in
general, we do need a function that can offer similar behaviour where
the lifetime of the software node is bound to the lifetime of the
device. But it just has to be a separate function so the behaviour is
optional. We can not remove the device_remove_properties() call from
device_del() before we have that new function, and before we have
replaced device_add_properties() calls with it in all the places that
require that behaviour.

This adds function device_create_managed_software_node() that can be
used for exactly that purpose. Software nodes created with it are
declared "managed", and separate handling for those nodes is added to
the software node code. The reference count of the "managed" nodes is
decremented when the device they are attached to is removed. This will
not affect the other nodes that are not declared "managed".

The function device_create_managed_software_node() has also one
additional feature that device_add_properties() does not have. It
allows the software nodes created with it to be part of a node
hierarchy by taking also an optional parent node as parameter.
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210204141711.53775-2-heikki.krogerus@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Clear USB Type C discovery events from the Chrome EC once they've been
successfully handled.
Signed-off-by: NPrashant Malani <pmalani@chromium.org>
Reported-by: NBenson Leung <bleung@chromium.org>
Tested-by: NBenson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20210203021539.745239-2-pmalani@chromium.orgSigned-off-by: NBenson Leung <bleung@chromium.org>

What platform_device_add_properties() does is it allocates
dynamically a software node that will contain the device
properties supplied to it, and then couples that node with
the device. If the properties are constant, the node can be
constant as well.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210204141711.53775-5-heikki.krogerus@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

What platform_device_add_properties() does is it allocates
dynamically a software node that will contain the device
properties supplied to it, and then couples that node with
the device. Since that node is always created, it might as
well be constant.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210204141711.53775-4-heikki.krogerus@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The function dwc2_pci_quirks() does nothing. Removing.
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Minas Harutyunyan <hminas@synopsys.com>
Link: https://lore.kernel.org/r/20210204141711.53775-3-heikki.krogerus@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

"PD Spec Revision 3.0 Version 2.0 + ECNs 2020-12-10" introduces several
changes regarding the ID Header VDO and the Product Type VDOs.
Signed-off-by: NKyle Tso <kyletso@google.com>
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210202161733.932215-3-kyletso@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

typec_partner_set_pd_revision returns void now.

Fixes: cefc011f ("platform/chrome: cros_ec_typec: Set Partner PD revision from status")
Signed-off-by: NBenson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20210202164531.3982778-1-bleung@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

typec_partner_set_pd_revision doesn't need any return value.

Fixes: 29b01295 ("usb: typec: Add typec_partner_set_pd_revision")
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NBenson Leung <bleung@chromium.org>
Signed-off-by: NKyle Tso <kyletso@google.com>
Link: https://lore.kernel.org/r/20210202095512.761214-1-kyletso@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Configure USB switches when partner is USB Communication capable.
The is enabled USB data communication over D+/D- pins.
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210202003101.221145-3-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB Communications Capable bit indicates if port
partner is capable of communication over the USB data lines
(e.g. D+/- or SS Tx/Rx). TCPM passes this information for chip specific
operations.
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210202003101.221145-2-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB Communications Capable bit indicates if port
partner is capable of communication over the USB data lines
(e.g. D+/- or SS Tx/Rx). Notify the status of the bit to low
level drivers to perform chip specific operation.
For instance, low level driver enables USB switches on D+/D-
lines to set up data path when the bit is set.

Refactored from patch initially authored by
Kyle Tso <kyletso@google.com>
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210202003101.221145-1-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Receiving the first packet in an AMS sequence signals the
beginning of AMS. Set in_ams flag to true when SRC_CAPS are
received during POWER_NEGOTIATION AMS.
This fixes the failure flagged while running TD.PD.SNK.E9
compliance test.

>From Deterministic PD compliance MOI spec:
TD.PD.SNK.E9. GetSinkCap in Place of Accept
Description:
As Provider, the Tester intentionally sends a GetSinkCap message in place
of Accept message and verifies the UUT will send a SoftReset and recover
from the error.
Steps:
a) Run PROC.PD.E1 Bring-up according to the UUT role.
b) The Tester cycles VBus.
c) The Tester sends a Source Capabilities message to the UUT.
d) Upon receipt of a Request message from the UUT, the Tester replies with
   a GoodCRC message.
e) The Tester sends a GetSinkCap message to the UUT.
f) If a SoftReset is not received within 15 ms after the GetSinkCap EOP was
   sent, the test fails.
g) If a SoftReset is received timely, the Tester replies with an Accept
   message.
h) The Tester sends Source Capabilities message to the UUT repeatedly until
   nCapsCount reached or a GoodCRC is received. If nCapsCount reached, the
   test fails.
i) If a Request is not received timely within 30 ms after the GoodCRC EOP
   corresponding to Source Capabilities message was received, the test
   fails.
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210202033859.258491-1-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

While in source mode, vbus could be shutoff by protections
circuits. TCPM does not move back to toggling state to
re-initiate connection. Fix this by moving to SRC_UNATTACHED
state when vbus shuts off while in source mode.
Reviewed-by: NGuenter Roeck <linux@roeck-us.net>
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBadhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20210201100212.49863-1-badhri@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When SOP Discovery is done, set the opmode to PD if status indicates
SOP is connected.

SOP connected indicates a PD contract is in place, and is a solid
indication we have transitioned to PD power negotiation, either as
source or sink.
Signed-off-by: NBenson Leung <bleung@chromium.org>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: NPrashant Malani <pmalani@chromium.org>
Link: https://lore.kernel.org/r/20210129061406.2680146-7-bleung@chromium.orgSigned-off-by: NBenson Leung <bleung@chromium.org>

Status provides sop_revision. Process it, and set it using the new
setter in the typec class.
Signed-off-by: NBenson Leung <bleung@chromium.org>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: NPrashant Malani <pmalani@chomium.org>
Link: https://lore.kernel.org/r/20210129061406.2680146-6-bleung@chromium.orgSigned-off-by: NBenson Leung <bleung@chromium.org>

cros_typec_handle_sop_prime_disc now takes the PD revision provided
by the EC_CMD_TYPEC_STATUS command response for the SOP'.

Attach the properly formatted pd_revision to the cable desc before
registering the cable.
Signed-off-by: NBenson Leung <bleung@chromium.org>
Acked-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: NPrashant Malani <pmalani@chromium.org>
Link: https://lore.kernel.org/r/20210129061406.2680146-5-bleung@chromium.orgSigned-off-by: NBenson Leung <bleung@chromium.org>

The partner's PD revision may be resolved later than the port partner
registration since the port partner creation may take place once
Type-C detects the port has changed state, but before PD communication is
completed.

Add a setter so that the partner's PD revision can be attached to it once
it becomes available.

If the revision is set to a valid version (not 0), the setter will also
refresh the partner's usb_pd flag and notify on "supports_usb_power_delivery"
sysfs property as well.
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBenson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20210129061406.2680146-4-bleung@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The USB Power Delivery specification Section 6.2.1.1.5 outlines
revision backward compatibility requirements starting from Revision 3.0.

The Port, the Cable Plug, and the Port Partner may support either
revision 2 or revision 3 independently, and communication between ports,
partners, and cables of different revisions are allowed under rules
that the parties agree to communicate between each other using the
lowest common operating revision.

This may mean that Port-to-Partner operating revision comms may be
different than Port-to-CablePlug operating revision comms. For example,
it is possible for a R3.0 port to communicate with a R3.0 partner
using R3.0 messages, while the R3.0 port (in the same session) must
communicate with the R2.0 cable using R2.0 messages only.

Introduce individual revision number properties for cable
and port partner so that the port can track them independently.
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBenson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20210129061406.2680146-3-bleung@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The Type-C Revision was in a specific BCD format "0120H" for 1.2.
USB PD revision numbers follow a similar pattern with "0300H" for 3.0.

Standardizes the sysfs format for usb_power_delivery_revision
to align with the BCD format used for usb_typec_revision.

Example values:
- "2.0": USB Power Delivery Release 2.0
- "3.0": USB Power Delivery Release 3.0
- "3.1": USB Power Delivery Release 3.1
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NBenson Leung <bleung@chromium.org>
Link: https://lore.kernel.org/r/20210129061406.2680146-2-bleung@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

If we receive a transfer event indicating that an endpoint should be
halted, but current endpoint state doesn't match it, then the halt might
be just resolved by the stop endpoint completion handler that detects the
halted endpoint due to a context state error.

In this case the TD we halted on is already moved to the cancelled TD list,
and should not be successfully completed and given back anymore.
Let the stop endpoint completion handler reset the endpoint, and then let
the reset endpoint handler give back the cancelled TD among all other
ones on the cancelled TD list
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-28-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A halted endpoint can be detected both when transfer events complete, and
in stop endpoint command completion. Both these handlers will start
clearing up the halted endpoint and queue a reset endpoint command.

It's possible to get both events for the same halted endpoint if right
after a URB cancel queues a stop endpoint command the endpoint stalls.
Use the EP_HALTED flag to prevent resetting the endpoint twice.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-27-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci_find_new_dequeue_state() and xhci_queue_new_dequeue_state() are no
longer used afer introducing the move_dequeue_past_td() function.

also remove struct xhci_dequeue_state as its no longer used.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-26-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Replace xhci_find_new_dequeue_state() and xhci_queue_new_dequeue_state()
functions with one combined function.
These function were always called after each other, and had a lot of extra
code just to pass the newly found dequeue state from the first function
to the other.

The new function also returns error in case there is a failure to
queue the new dequeue state. This way the caller can decide on
recovery measures to handle it.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-25-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Handle race where a stop endpoint command fails with "context state error"
as hardware hasn't actually started the ring yet after a previous urb
cancellation completed and restarted the endpoint.
Flushing the doorbell write that restart the endpoint reduced these cases,
but didn't completely resolve them.

Check if the ring is running in the stop endpoint completion handler, and
issue a new stop endpoint command in this case.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-24-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

xhci 4.6.9: "A busy endpoint may asynchronously transition from the
Running to the Halted or Error state due to error conditions detected
while processing TRBs. A possible race condition may occur if software,
thinking an endpoint is in the running state, issues a Stop Endpoint
Command, however at the same time the xHC asynchronously transitions
the endpoint to the Halted or Error state. In this case, a Context
State Error may be generated for the command completion. Software
may verify that this case occurred by inspecting the EP State for
Halted or Error when a Stop Endpoint Command results in a Context
State Error."

Halted endpoints were not detected or handled at all in the stop endpoint
completion handler. A set TR Deq ptr command was bluntly queued instead
of resetting the endpoint first. The set TR Deq command would fail with
a context state error.

Fix this case by resetting the halted endpoint first to get it to a
stopped state instead of the halted (error) state.
Handle cancelled TDs once endpoint reset completes,
invalidating cancelled TDs on ring either by turning them to no-op,
or in case ring stopped on cancelled TD then move hardware dequeue pointer
past it, which will clear the cancelled TD from hw cache, and make sure
HW does not process it
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-23-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Don't queue both a reset endpoint command and a
set TR deq command at once when handling a halted endpoint.

split this into two steps.
Initially only queue a reset endpoint command, and then if needed queue a
set TR deq command in the reset endpoint handler.

Note: This removes the RESET_EP_QUIRK handling which was added in
commit ac9d8fe7 ("USB: xhci: Add quirk for Fresco Logic xHCI hardware.")

This quirk was added in 2009 for prototype xHCI hardware meant for
evaluation purposes only, and should not reach consumers.
This hardware could not handle two commands queued at once, and had
bad data in the output context after a reset endpoint command.

After this patch two command are no longer queued at once, so that
part is solved  in this rewrite, but the workaround for bad data in the
output context solved by issuing an extra configure endpoint command is
bluntly removed.

Adding this workaround to the new rewrite just adds complexity, and I
think it's time to let this quirk go.
Print a debug message instead.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-22-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Halted endpoints can be discoverd both when handling transfer events and
command completion events. Move code that handles halted endpoints before
both of those event handlers.

Rename the function to xhci_handle_halted_ep() to better describe
what it does. Try to reserve "cleanup" word in function names for last
stage cleanup activities.

No functional changes
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-21-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Refactor handler for stop endpoint command completion. Yank out the part
that invalidates cancelled TDs and turn it into a separate function.

Invalidating cancelled TDs should be done while the ring is stopped,
but not exclusively in the stop endpoint command completeion handler.

We will need to invalidate TDs after resetting endpoints as well.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-20-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In cases where the TD can't be given back in current handler we want
to be able to store it until its time to return the TD.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-19-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

use the existing xhci_td_cleanup() to give back cancelled TDs when a
ring is stopped.

A minor change to make sure we don't try to remove an already removed
td from the list is needed as cancelled TDs are already removed from the
td_list immediatelty when it's cancelled.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-18-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

No funtional changes
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-17-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Create a separate helper function to issue reset endpont commands
to clear halted endpoints.

This is useful for cases where a halted endpoint is discovered while
completing another command, and the endpoint halt needs to be cleared
with a endpoint reset first.

No functional changes
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-16-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Stop endpoint command fails with "context state error" if the endpoint is
already stopped.

This case was observed when a previous URB cancel had just completed and
rang the doorbell to restart the ring, when a new URB cancel queued a stop
endpoint command.
>From xHC hardware pov the endpoint had not yet started, so the stop
endpoint command failed with context state error.
Right after this the doorbell ring took effect and ring was restarted.

Interrupt handler saw a stop endpoint command completion event with
"context state error" and discovered that the ring was back up in
running state.

flushing the write reduces these cases in stress testing, but does not
completely remove the issue.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20210129130044.206855-15-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>