From: "Michał Pecio" <michal.pecio@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] usb: xhci: Deduplicate some endpoint state flag lists
Date: Tue, 11 Mar 2025 01:13:15 +0100 [thread overview]
Message-ID: <20250311011315.4b3efbfe@foxbook> (raw)
In-Reply-To: <dabb1140-b26e-4f90-8e65-85e16d99aa49@linux.intel.com>
On Mon, 10 Mar 2025 11:51:30 +0200, Mathias Nyman wrote:
> Not sure this helps readability
>
> It defines even more macros to abstract away something that is not
> complex enough.
It was less about readability, but keeping these lists in one place
so that they don't get out of sync and trigger the double-stop bug.
With this change, a new flag like EP_STALLED only needs to be added
in one place and it's picked up by both functions which need it.
OTOH, maybe such flags aren't being added very often...
> It also gives false impression that EP_HALTED would somehow be more
> part of cancelling a TD than EP_STALLED, when both of those are about
> returning a TD with an error due to transfer issues detected by host,
> not class driver cancelling URBs.
I think EP_HALTED is about cancellation (among other things), because
it indicates that Reset EP handler will run and finish cancellation of
the halted TD and also any other TDs unlinked by class driver.
EP_STALLED and EP_CLEARING_TT are less about the halted TD and more
about ensuring full reset of the pipe before new TDs are executed.
Michal
next prev parent reply other threads:[~2025-03-11 0:13 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 ` [PATCH 1/6] usb: xhci: Document endpoint state management Michal Pecio
2025-03-10 9:25 ` 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 [this message]
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=20250311011315.4b3efbfe@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 \
--cc=mathias.nyman@linux.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