From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2393A3A63ED for ; Mon, 18 May 2026 05:32:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779082343; cv=none; b=GhWeXk0cl3Dg4KPFjG2zyngnTAS4Jn+RX7s02ztpyfN2kTdRNDLOUluyQ1LJWxJr8Oo7q2/ymoBBX8WdCzpsVvxuYyNRNSb3KyhDYmaXIs4Auy3k8Ch6bOoShTzX6ht9oDHoyV9ZkecGMc+lQ44Fw8jyOH64ZEBf4ZlMqBVpuU0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779082343; c=relaxed/simple; bh=mdFHqmiM7J1eyeeB0BYJJMW3l7BJGjPJuNDC/3hHRa4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Izv5PTRvWdjjR5GjY3AeRc2t86vvjxaFlWn0JhapwGRbP/yLfLqSZW80vUISTzKsxO9iNUh9dmBsi3F9TIb2hgs65jpHTXZivoEEUIvrrY9bfqDmResgiiYFAmDE/gbrEgOMdBtK4Vdhj5yNZC4IaJBInf3Ug9IGeUxzQf56/38= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NWWLlLT9; arc=none smtp.client-ip=209.85.128.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NWWLlLT9" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4896c22fcbaso14152055e9.0 for ; Sun, 17 May 2026 22:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779082330; x=1779687130; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=zz3RXE6rLnkPyLWqz9WMXcLwC/lkGY7zfy2G8LQXM4I=; b=NWWLlLT9+6Mvp7iSmMIaz2YEsLV7HhJi/fq+nZlpYdY1U0/AerSqsI11br1hyb7/Z5 U81aCeYHts06iZeIpDCdI/IiyH3jPDeSmC6Jc3HKl+oq6wEQE7sbyLsY3+Z0WZJBxgsG 7cXXy/Z9uHFOcYLcWv2b+4opxfX0Pcurr2WqmxpvaaGeaDXGIMmtfPc2wy4uWn2rOzxh OgekfyOSEQc+1pJ38eUwbpNj9FcCzweDbzp46NUIXrWcKMVSHLf8bLc8iyK8i27xS4ue 46w1MV4ldOhaQq8typqUmU9WvxBYyX31joY4fF+Nvmf1v97xpB5w5MbtfbkqX2G65Gpf Y04A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779082330; x=1779687130; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=zz3RXE6rLnkPyLWqz9WMXcLwC/lkGY7zfy2G8LQXM4I=; b=M7WDnYuPZBpOcHiSpB3jLKyhkzw1E4TeREBOVJLBaMjmTQEe6750bln3eun/M3cLR+ wBHZJtGlQyx7QLuYexk0eBupTSjpwTUatvp2BeWyTF+RX8hR2/ze/HSLSJgxFh3Ikq8Y 5r83stLHYOQHgB98d4Cu5CeZSKTIpbpWTAUwHor6q0LyeKjZ8GfPQvRqpcOTbfpDHZfQ BJ7+gokBz0u0M1KBiSssi/l4gTCwqmRRiYM3OrH7teqX1Wps8IHfdSizvn/DH97Rd7Cn MxqOsPhhupxAOOym3G90Eu34OVkluIHvVzTni56AYRQtWiQyv4OQpMw+PY3CLmYq70zz Fdfg== X-Forwarded-Encrypted: i=1; AFNElJ893isKK0i2MzCjKigc7BLCYuXSU4I9Kt+k9UF1ShVDmVwrP0CVP7Hyb+y6K0YzcQFtBRo0b1wu6SDupRg=@vger.kernel.org X-Gm-Message-State: AOJu0Yya3gTnrFYA0uAqzaBfI4Xea0L+3dHzbjmFwGBBTZg2Aw1t1PUN PwEFC9ZOkGWtRiRar0bVQDdbRdjrqwVSan8NojA/FNkRuPpj2QrEN81p X-Gm-Gg: Acq92OFUjcWJuUNQyhBNrQbDGl3XuLpMFeh61ePz6tiwSE9lP3imW/6WvCijsLYFCG2 o/2JHkucjkQxkM9OrozRj9hS8MNHllklnG3ZXZz/5jNdroz1+E0vYlTpPch6O9sBL/aoLC+8oZX zdOlRfYiFwuoU779SF74+LYx8UkS1qf4SeQaiRrCnnSRjm53rpxFdlQPeunyq8HUWieY7bseMrn fuVr+DMr0LDXQ9juFSZjVEMWXZXtYps1Iz9EePPRrClWHskPTdfx2I52Y5nW6cYiooopfVl7RwP tF47MeyyvNm3Puyr4vFOuFd1nGLtbti8oXRlUh35ze2dLIpZqXkAvRSAxqvad1D1wDKtJ07d9LK puO+fhetaWUi/SA+XJffsQKfja14iC9dG5Cq1o5u+RYtEJqLMt2KiHmU8cyi8gJarGtnuPxLRUO qAKEV7pNOxn5FMlVzWF2UcBcnVjTmZWx7g X-Received: by 2002:a05:600c:8b6e:b0:48a:6fd4:d3d3 with SMTP id 5b1f17b1804b1-48fe61ed21amr213731975e9.20.1779082330414; Sun, 17 May 2026 22:32:10 -0700 (PDT) Received: from foxbook (bfk48.neoplus.adsl.tpnet.pl. [83.28.48.48]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fe53ab6aasm243360535e9.2.2026.05.17.22.32.09 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 17 May 2026 22:32:10 -0700 (PDT) Date: Mon, 18 May 2026 07:32:07 +0200 From: Michal Pecio To: Greg KH , Alan Stern , Mathias Nyman Cc: "Xuetao (kirin)" , , , Subject: [PATCH v3 2/3] usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval Message-ID: <20260518073207.5b7d26e7.michal.pecio@gmail.com> In-Reply-To: <20260518073026.5580bb79.michal.pecio@gmail.com> References: <20260518073026.5580bb79.michal.pecio@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Tao Xue found that some common devices violate USB 3.x 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-and-tested-by: Tao Xue Closes: https://lore.kernel.org/linux-usb/20260402021400.28853-1-xuetao09@huawei.com/ Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio --- 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 417140b012bb..d9171bf7bc88 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_is_int_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