From: Michal Pecio <michal.pecio@gmail.com>
To: Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 1/6] usb: xhci: Document endpoint state management
Date: Mon, 10 Mar 2025 09:36:59 +0100 [thread overview]
Message-ID: <20250310093659.04b082e3@foxbook> (raw)
In-Reply-To: <20250310093605.2b3d0425@foxbook>
Add systematic comments describing xhci_virt_ep.ep_state flags and
their relation to xHC endpoint state.
Add a few paragraphs about how they are used to track and manage the
state of endpoints.
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
---
drivers/usb/host/xhci.h | 44 +++++++++++++++++++++++++++++------------
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 56ed1b817f91..46bbdc97cc4b 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -662,20 +662,18 @@ struct xhci_virt_ep {
*/
struct xhci_ring *new_ring;
unsigned int err_count;
+ /* Endpoint state, state transitions, pending operations. See also notes below. */
unsigned int ep_state;
-#define SET_DEQ_PENDING (1 << 0)
-#define EP_HALTED (1 << 1) /* Halted host ep handling */
-#define EP_STOP_CMD_PENDING (1 << 2) /* For URB cancellation */
-/* Transitioning the endpoint to using streams, don't enqueue URBs */
-#define EP_GETTING_STREAMS (1 << 3)
-#define EP_HAS_STREAMS (1 << 4)
-/* Transitioning the endpoint to not using streams, don't enqueue URBs */
-#define EP_GETTING_NO_STREAMS (1 << 5)
-#define EP_HARD_CLEAR_TOGGLE (1 << 6)
-#define EP_SOFT_CLEAR_TOGGLE (1 << 7)
-/* usb_hub_clear_tt_buffer is in progress */
-#define EP_CLEARING_TT (1 << 8)
-#define EP_STALLED (1 << 9) /* For stall handling */
+#define SET_DEQ_PENDING BIT(0) /* EP Stopped, Set TR Dequeue pending */
+#define EP_HALTED BIT(1) /* EP Halted -> Stopped, Reset Endpoint pending */
+#define EP_STOP_CMD_PENDING BIT(2) /* EP Running -> Stopped, Stop Endpoint pending */
+#define EP_GETTING_STREAMS BIT(3) /* Transitioning to streams, no URBs allowed */
+#define EP_HAS_STREAMS BIT(4) /* Streams are enabled */
+#define EP_GETTING_NO_STREAMS BIT(5) /* Transitioning to no streams, no URBs allowed */
+#define EP_HARD_CLEAR_TOGGLE BIT(6) /* Toggle is being or has been cleared by reset */
+#define EP_SOFT_CLEAR_TOGGLE BIT(7) /* Software toggle clearing, no URBs allowed */
+#define EP_CLEARING_TT BIT(8) /* EP not Running, Transaction Translator reset */
+#define EP_STALLED BIT(9) /* EP not Running, waiting for usb_clear_halt() */
/* ---- Related to URB cancellation ---- */
struct list_head cancelled_td_list;
struct xhci_hcd *xhci;
@@ -703,6 +701,26 @@ struct xhci_virt_ep {
bool use_extended_tbc;
};
+/*
+ * Endpoint state notes.
+ * xHCI 4.8.3 defines three basic states of an enabled endpoint: Running, Halted, Stopped.
+ * The fourth Error state is avoided by not queuing invalid TRBs. This seems to work so far.
+ *
+ * 4.8.3 warns that Endpoint Context EP State field may be stale, and it doesn't indicate ongoing
+ * transitions anyway. Some xhci_virt_ep.ep_state flags are used to keep track of known transitions
+ * and various operations which imply or require the endpoint to be in a particular state.
+ *
+ * Notably missing is the Stopped -> Running transition started by a doorbell ring. 4.8.3 suggests
+ * that it is instantenous, but on some common HCs it may not be. There is no universal way to know
+ * when it completes. Transfer events imply completion, but don't arrive if the device NAKs/NRDYs.
+ * Stop Endpoint fails if the transition isn't complete. Polling the Endpoint Context is an option.
+ *
+ * xhci_ring_ep_doorbell() inspects the flags to decide if the endpoint can be restarted. Another
+ * user is xhci_urb_dequeue(), which must not attempt to stop a Stopped endpoint, due to HW bugs.
+ * An endpoint with pending URBs and no flags preventing restart must be Running for this to work.
+ * Call xhci_ring_doorbell_for_active_rings() or similar after clearing any such flag.
+ */
+
enum xhci_overhead_type {
LS_OVERHEAD_TYPE = 0,
FS_OVERHEAD_TYPE,
--
2.48.1
next prev parent reply other threads:[~2025-03-10 8:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-10 8:36 [PATCH 0/6] xHCI: endpoint state maintainability and small fixes Michal Pecio
2025-03-10 8:36 ` Michal Pecio [this message]
2025-03-10 9:25 ` [PATCH 1/6] usb: xhci: Document endpoint state management Mathias Nyman
2025-03-10 8:37 ` [PATCH 2/6] usb: xhci: Deduplicate some endpoint state flag lists Michal Pecio
2025-03-10 9:51 ` Mathias Nyman
2025-03-11 0:13 ` Michał Pecio
2025-03-10 8:38 ` [PATCH 3/6] usb: xhci: Only set EP_HARD_CLEAR_TOGGLE after queuing Reset Endpoint Michal Pecio
2025-03-10 8:39 ` usb: xhci: Don't change the status of stalled TDs on failed Stop EP Michal Pecio
2025-03-10 8:43 ` Michal Pecio
2025-03-10 8:40 ` [PATCH 4/6] " Michal Pecio
2025-03-10 13:54 ` Mathias Nyman
2025-03-10 8:41 ` [PATCH 5/6] usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running Michal Pecio
2025-03-10 8:42 ` [PATCH 6/6] usb: xhci: Update comments about Stop Endpoint races Michal Pecio
2025-03-11 15:41 ` [PATCH 0/6] xHCI: endpoint state maintainability and small fixes Mathias Nyman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250310093659.04b082e3@foxbook \
--to=michal.pecio@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.