From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (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 38F7034D907 for ; Thu, 23 Apr 2026 09:10:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776935406; cv=none; b=gV7p8teJUYavspA7kJPg1WO9k6TCAWj79lqD4Sw8ZoDJkXKo6uGTJGVmF8+7zGlB15veVw1g9LI7ZQUjATFiOku5yuqqhuNW2ZFIOoKTKGHZDYHWdYf1fK/vqTIJjgjGxVr4/3uCA9BKaMbtdyo3iILOFJ18YlbryDY5uQ7ueZM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776935406; c=relaxed/simple; bh=vwEKsA+nbFYpTCh5gVuvr4S/uIi6G5nwFRfHmkEiQRo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=I1BEE/+j9NGVJ5ReBvTZXNP1hC6TyrSMsnvSzfAcugvZ+eWjPOD1P5Ac7xnltd4bYrhtArVboq46Fja/DXd/TD5WGWL0ge8OnfrLVlKCkJskWoVkvKOqPlU5hBeSb1KE2/oXA+ttPCTg69uee8pvCHQCRQ1I79VKLkGtFSw+W+8= 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=Eb+kjSBq; arc=none smtp.client-ip=209.85.167.50 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="Eb+kjSBq" Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-5a62a049c1fso3674947e87.3 for ; Thu, 23 Apr 2026 02:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776935403; x=1777540203; 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=8GW2PNNDkAuBpg1bMRvNWzBprqg1m58YQcX7A6vaBfA=; b=Eb+kjSBq9RLx+Uj5JEgUd50LWroueLfjZt5RgcPaMI416zosW9b+bjC0vllzYoopZK uuUUeEwY01JoYY3Q7G13OJVkxd/p8S4d52kZTnOItLUb6wyjqzFpe2vFMnb0MPpDtbFd rTxH+HmOd3pSvuRLkGnOUZOdkCFQUwhHEk24MONdqMS4G1VKa424GYbkl6v7zY366E8k gRUfUBulOutaJ3CguoYrEr25o0pS+6bKLs06ZQn2+uyE1ZOjBRz9ufhdqfq1IpB8PQoG ThIZsxi16Zq92XXQ/1+7lhJbWZ68l17WLwBCRHg8JqWY9YUAOD2Zm0Scw3FKOOfNf8Ci gDFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776935403; x=1777540203; 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=8GW2PNNDkAuBpg1bMRvNWzBprqg1m58YQcX7A6vaBfA=; b=hbuCO/IdmOdyfconisCXskKTowfg/kQ2y6Arr33GWeC1tv8Hm3b7wYVICkH0h62gfT s5enWSV9XNtoe4+ldtsqNm7N9iLUw8CHgB5Kkl5i+ISfO/ZlQ6rTirdTY2Geo6IxAYdN qTXTJziQBseozEXh/rmPtqdp/iwNxRJkNOrKmnAO3XPIsehAiFKtBMMQA4lSAbX1is5J qzK2qaC/GfdUwCSEtDF1XQTb5aUjwB227OHOPD8HrB+AvTG8tdfJg5vs/ym+CIdTL//A Q51yuVUrqdV/4Ta6qVWH0oSDE9dJxiT2KFB+ax3GTkiul0vx22JEEhI0oX36TZQ+EMLL xAdA== X-Forwarded-Encrypted: i=1; AFNElJ+AU59hY+2+X0YL5jOy1Njl9TIEXMgbIvuwoVxY8EGEk92o7cCw/sXKpy2BoXfi9YnnJUtdW7qPwA+0msU=@vger.kernel.org X-Gm-Message-State: AOJu0YwdU8OvGyqlrSaxe+sdc33po076tbyTEolt119/2qkbu1y3yd3Y 4nazqgPycFbDUU8IFWBcIzHhHEid4D/yry0JndclvjCynVhZo52jMenO X-Gm-Gg: AeBDietY8ksmw3h75IfuKrZ1Q9nsCDX29RJ0f6ZcXnUQxNTOPx3EdiSb6W+NY8C0eCo Dy+l0homRH2nrHbTZ7WNODzwUkIZCs1dXnYFbZwx23Z76gYRwjq4Z5Genas/BRzz8Ue91gJOcJ4 OZLgHjQrk5d72YFEPhBK5uJJz8035dfNlCkOflFaQ4UUO4esgWVbUaeonC47Pg7tOJSf7ld764O CqVsFj/8w6TdyvPTdXSUhCVLWpUnHP7s4srYbpzXPBvknHNRLNbWbTbK2hVh+9oSe8PAMJ5dzXh HAJngkOp3ENVEiGmTzLdVcig0TYCQN3tcUYf4oXZ4/OgPGOvFykOqM6pMFqRnno+nFSPBceYmG+ ttbd8BtCduTiPGmon92qAB0t63phYtDKLwYBBde7pVq50q+O0d14JOSZ3Sqvhhy1BqBHHzmQVyv dRuzQcxn2teAojmfF8R286Jo3UeXiWgoCyVwPC8p/Laxc= X-Received: by 2002:a05:6512:3193:b0:5a3:ed0a:efb4 with SMTP id 2adb3069b0e04-5a417303404mr8846063e87.38.1776935403246; Thu, 23 Apr 2026 02:10:03 -0700 (PDT) Received: from foxbook (bfh75.neoplus.adsl.tpnet.pl. [83.28.45.75]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5a4187e7ca0sm4992067e87.65.2026.04.23.02.10.02 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 23 Apr 2026 02:10:02 -0700 (PDT) Date: Thu, 23 Apr 2026 11:09:59 +0200 From: Michal Pecio To: "Xuetao (kirin)" Cc: Greg KH , Alan Stern , , , , Subject: [PATCH 2/2] usb: core: Fix up Interrupt IN endpoints with bogus wBytesPerInterval Message-ID: <20260423110959.0e2f1a4e.michal.pecio@gmail.com> In-Reply-To: <20260423110648.158ec861.michal.pecio@gmail.com> References: <20260402021400.28853-1-xuetao09@huawei.com> <2026040241-purveyor-bakery-a9f1@gregkh> <74f1bb0d-24c3-44be-9583-0585863cdae3@rowland.harvard.edu> <2026040221-reclusive-garland-6281@gregkh> <00ad170a-2546-4d7a-8f8b-af6d46e09a73@huawei.com> <20260423110517.664745da.michal.pecio@gmail.com> <20260423110648.158ec861.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 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 Closes: https://lore.kernel.org/linux-usb/20260402021400.28853-1-xuetao09@huawei.com/ Cc: stable@vger.kernel.org Signed-off-by: Michal Pecio --- 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