public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox