public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: "Xuetao (kirin)" <xuetao09@huawei.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	<linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<caiyadong@huawei.com>, <stable@kernel.org>
Subject: [PATCH 2/2] usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval
Date: Thu, 23 Apr 2026 11:09:59 +0200	[thread overview]
Message-ID: <20260423110959.0e2f1a4e.michal.pecio@gmail.com> (raw)
In-Reply-To: <20260423110648.158ec861.michal.pecio@gmail.com>

Tao Xue found that some common devices violate USB3 section 9.6.7
by reporting wBytesPerInterval lower than the size of packets they
actually send. I confirmed that AX88179 may set it to 0 and RTL8153
CDC configuration sets it to 8 but sends both 8 and 16 byte packets:

S Ii:11:007:3 -115:128 16 <
C Ii:11:007:3 0:128 8 = a1000000 01000000
S Ii:11:007:3 -115:128 16 <
C Ii:11:007:3 0:128 16 = a12a0000 01000800 00000000 00000000

Most xHCI host controllers neglect interrupt bandwidth reservations
and let such devices exceed theirs, some fail the URB with EOVERFLOW.

Assume that wBytesPerInterval lower than wMaxPacketSize is bogus and
increase it to the worst case maximum on interrupt IN endpoints. This
solves xHCI problems and appears to have no other effect. Interrupt
transfers are not limited to one interval and drivers submit URBs of
class defined size without looking at wBytesPerInterval. Any multi-
interval transfer is considered terminated by a packet shorter than
wMaxPacketSize regardless of wBytesPerInterval - see USB3 8.10.3.

Stay in spec on OUT endpoints and isochronous. No buggy devices are
known and we don't want to risk sending more data than the device
is prepared to handle or confusing isoc drivers regarding altsetting
capacities guaranteed by the device itself. And don't complain when
wMaxPacketSize <= wBytesPerInterval < wMaxPacketSize * (bMaxBurst+1)
because enabling this seems to be the exact goal of the spec.

Reported-by: Tao Xue <xuetao09@huawei.com>
Closes: https://lore.kernel.org/linux-usb/20260402021400.28853-1-xuetao09@huawei.com/
Cc: stable@vger.kernel.org
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
---

Note:
Compared to original suggestion, this is a conservative patch which
only addresses known broken devices and tries to minimize disruption
for spec compliant ones.

 drivers/usb/core/config.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 6a1fd967e0a6..bdd912627bac 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -191,7 +191,14 @@ static void usb_parse_ss_endpoint_companion(struct device *ddev, int cfgno,
 			(desc->bMaxBurst + 1);
 	else
 		max_tx = 999999;
-	if (le16_to_cpu(desc->wBytesPerInterval) > max_tx) {
+	/*
+	 * wBytesPerInterval > max_tx is bogus, but USB3 spec doesn't forbid the opposite.
+	 * Experience shows that wBytesPerInterval < wMaxPacketSize on common interrupt IN
+	 * endpoints is usually bogus too, and recent HCs enforce interrupt BW limits.
+	 */
+	if (le16_to_cpu(desc->wBytesPerInterval) > max_tx ||
+	    (le16_to_cpu(desc->wBytesPerInterval) < usb_endpoint_maxp(&ep->desc) &&
+	     usb_endpoint_xfer_int(&ep->desc) && usb_endpoint_dir_in(&ep->desc))) {
 		dev_notice(ddev, "%s endpoint with wBytesPerInterval of %d in "
 				"config %d interface %d altsetting %d ep %d: "
 				"setting to %d\n",
-- 
2.48.1

  reply	other threads:[~2026-04-23  9:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02  2:14 [PATCH] usb: core: Fix bandwidth for devices with invalid wBytesPerInterval Tao Xue
2026-04-02  2:45 ` Alan Stern
2026-04-02  3:51 ` Greg KH
2026-04-02  6:59   ` Xuetao (kirin)
2026-04-02  7:10     ` Greg KH
2026-04-02  8:26       ` Xuetao (kirin)
2026-04-02 13:56     ` Alan Stern
2026-04-02 14:09       ` Greg KH
2026-04-02 15:03         ` Michal Pecio
2026-04-03  1:20         ` Xuetao (kirin)
2026-04-22 13:26           ` Xuetao (kirin)
2026-04-23  9:05             ` Michal Pecio
2026-04-23  9:06               ` [PATCH 1/2] usb: core: Fix root hub descriptor wBytesPerInterval Michal Pecio
2026-04-23  9:09                 ` Michal Pecio [this message]
2026-04-23 14:04                   ` [PATCH 2/2] usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval Alan Stern
2026-04-23 14:55                     ` Xuetao (kirin)
2026-04-02 20:17       ` [PATCH] usb: core: Fix bandwidth for devices with invalid wBytesPerInterval Michal Pecio
2026-04-02  9:44 ` Michal Pecio
2026-04-02 11:55   ` Xuetao (kirin)
2026-04-03  7:16     ` Michal Pecio
2026-04-22  6:32       ` Michal 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=20260423110959.0e2f1a4e.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=caiyadong@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=xuetao09@huawei.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