linux-usb.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 220748] usb: xhci_queue_isoc_tx_prepare ignore start_frame and always assumes URB_ISO_ASAP is set
Date: Thu, 06 Nov 2025 03:52:48 +0000	[thread overview]
Message-ID: <bug-220748-208809-loEwOHrV1o@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-220748-208809@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=220748

--- Comment #10 from Alan Stern (stern@rowland.harvard.edu) ---
Figuring out how to handle isochronous transfers has been very difficult; it's
not obvious what scheme would work best.  Compounding that difficulty is the
fact that different host controller drivers store their (micro)frame numbers
differently, so drivers will never know exactly what to expect.

You say that uhci-hcd used to work "the intuitive way", but in fact experience
has shown that no way is truly intuitive.  Or to put it another differently,
what's intuitive for one person is not intuitive for another.

And don't forget that host controller drivers have to handle isochronous
endpoint queues that can be in three or four different possible states: empty,
partially or completely full, and partially full but totally expired.  It's not
at all easy to come up with a set of flags and values that can handle all the
possibilities in ways that drivers will find convenient to use.

The matter of specifying polling intervals different from what the endpoint
descriptor says is yet another can of worms.  For example, host controllers
generally can't change polling intervals in mid-stream.  And some might reserve
the necessary bandwidth at the time when the alternate setting is installed,
before any URBs have been submitted -- how would one go about changing it from
the default value then?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2025-11-06  3:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-04 21:25 [Bug 220748] New: usb: xhci_queue_isoc_tx_prepare ignore start_frame and always assumes URB_ISO_ASAP is set bugzilla-daemon
2025-11-05  8:40 ` [Bug 220748] " bugzilla-daemon
2025-11-05  8:48 ` bugzilla-daemon
2025-11-05  8:53 ` bugzilla-daemon
2025-11-05  9:06 ` bugzilla-daemon
2025-11-05 15:47 ` bugzilla-daemon
2025-11-05 18:28 ` bugzilla-daemon
2025-11-05 18:30 ` bugzilla-daemon
2025-11-05 20:16 ` bugzilla-daemon
2025-11-05 21:18 ` bugzilla-daemon
2025-11-06  3:52 ` bugzilla-daemon [this message]
2025-11-06  8:27 ` bugzilla-daemon
2025-11-06  8:35 ` bugzilla-daemon
2025-11-06 15:03 ` bugzilla-daemon
2025-11-08 10:33 ` bugzilla-daemon
2025-11-08 16:09 ` bugzilla-daemon
2025-11-10 10:23 ` bugzilla-daemon
2025-11-10 10:42 ` bugzilla-daemon

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=bug-220748-208809-loEwOHrV1o@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /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).