From: "Michał Pecio" <michal.pecio@gmail.com>
To: "Neronin, Niklas" <niklas.neronin@linux.intel.com>
Cc: linux-usb@vger.kernel.org, Mathias Nyman <mathias.nyman@linux.intel.com>
Subject: Re: [PATCH 4/4] usb: xhci: handle Set TR Deq Context State Error due to Endpoint state
Date: Fri, 29 Aug 2025 10:14:53 +0200 [thread overview]
Message-ID: <20250829101453.75c38876.michal.pecio@gmail.com> (raw)
In-Reply-To: <20250829100649.6eaa94e9.michal.pecio@gmail.com>
On Fri, 29 Aug 2025 10:06:49 +0200, Michał Pecio wrote:
> We generally try not to queue multiple commands on the same endpoint
> to reduce race condition headache, but Reset Endpoint is an exception.
> I don't remember why, but I thought this exception is necessary evil.
I think it's because handle_tx_event() knows the completion code, so it
can assign accurate urb->status (EPRORO or EPIPE). I guess it would take
a bit of work to separate updating status (immediately) from queuing
Reset Endpoint (later when pending commands complete), though I haven't
really looked into it.
It could possibly increase error recovery latency in some cases.
For now, we live with the headache of Reset Endpoint executing
concurrently with other commands or their completion handlers.
next prev parent reply other threads:[~2025-08-29 8:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-18 12:57 [PATCH 0/4] usb: xhci: improve Set TR Deq completion error handling Niklas Neronin
2025-08-18 12:57 ` [PATCH 1/4] usb: xhci: handle Set TR Deq TRB Error Niklas Neronin
2025-08-21 9:32 ` Michał Pecio
2025-08-22 11:00 ` Neronin, Niklas
2025-08-18 12:57 ` [PATCH 2/4] usb: xhci: handle Set TR Deq Slot Not Enabled Error Niklas Neronin
2025-08-21 10:35 ` Michał Pecio
2025-08-22 7:22 ` Michał Pecio
2025-08-18 12:57 ` [PATCH 3/4] usb: xhci: handle Set TR Deq Context State Error due to Slot state Niklas Neronin
2025-08-22 7:49 ` Michał Pecio
2025-08-18 12:57 ` [PATCH 4/4] usb: xhci: handle Set TR Deq Context State Error due to Endpoint state Niklas Neronin
2025-08-22 8:15 ` Michał Pecio
2025-08-25 7:15 ` Michał Pecio
2025-08-27 11:53 ` Neronin, Niklas
2025-08-29 8:06 ` Michał Pecio
2025-08-29 8:14 ` Michał Pecio [this message]
2025-09-01 6:18 ` Michał Pecio
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=20250829101453.75c38876.michal.pecio@gmail.com \
--to=michal.pecio@gmail.com \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@linux.intel.com \
--cc=niklas.neronin@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;
as well as URLs for NNTP newsgroup(s).