From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 0DA0B32571D for ; Thu, 2 Apr 2026 20:18:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775161083; cv=none; b=Kb4JLn8O5vSecdMGwP00zDtT80CYU4tdpt/lF8Ov70D2Ln/REaOMqBiRTvTAQpbfX08jZfU84HhN9SqdQhuToBJhjDvjnCscUSNIX1oY7+bLHy2Uts16hp1yOp0F9zzhtXj9LYbDrENuvxte4Emjj8NjHjKUYdx0KTHaytgMcqw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775161083; c=relaxed/simple; bh=5UsOEcn50cdBc2IpTEpFynqVOam78E9Xv9FXNMb1C8A=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mRzBVI0LZLNKh3frgkX8LymTlsEbVhJRf0CSPP/P+QyfOySKFnxfl1z/O9ZjOSgZ4+YAtTyolOlbZZOBEshpZSXdZ7zxiTqTJNHGJ5GkhmKQ8szJewk/DXjww1QHWW/PKt55kJhSPrbjgMnJbf44/LMhThPO5/j4y/NPiHOzueY= 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=OdiTHaC0; arc=none smtp.client-ip=209.85.128.53 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="OdiTHaC0" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-488895ad947so14430345e9.3 for ; Thu, 02 Apr 2026 13:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775161080; x=1775765880; 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=5UsOEcn50cdBc2IpTEpFynqVOam78E9Xv9FXNMb1C8A=; b=OdiTHaC0gBz7Ws9ArJJe8KabPgKKlNWZiVyVZBWQXms7QwCQfnqSiHfXqkQoGuom8b s0hx3QJ342x72jOmM5l8jzA0bM6UmJgNxcYuh7eApmmCVekf0cRjmm1HIdekuM+wtI3A IIZzni1aXMdsMaQxYny2w8IruUNNEKRnsbHSUaQTZ7YKPgG0tPRMKpRW/xA+Bh37Jxc2 Vt/4/cfi0Hg2dnO1MmkNNv5PCivLZNfn3OQeIqLCMtj4+D9owZ4U4DBwGzCJgpjv1UoN krqqpaAECJYY85fU7agFocobbdC32DV6vaQ0/5dNA3qF7pvYRFlQ60OOXua5ZnXorWs2 KGCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775161080; x=1775765880; 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=5UsOEcn50cdBc2IpTEpFynqVOam78E9Xv9FXNMb1C8A=; b=S/fIE/eNEo7PrfMPqVxo5fViM+eM13jGy0Yz028tVvEv+IObqlcpyBQmhvXiCxa0HC h5VZOoX58Sk8gHl9F6ZRbMqdyrhj4j0WDkHrDKLkqa46TaXo6jDtKo64bJhwavAjDmoV Qx3vGfZHAdc2xsrmK2sdQTFtcgLbqQuQR0iqAFxWjGqyqI0TY33nk9O4c1/p0bfj/Hr1 gw4t7si9UP0sEGYI5kvQB4/Z/tF3xJZL4qLIXGvt1BdLyrkCc9dUpKh6vh5Su7iUSirK lit2v8N7RSC2K8LQJTr52L27KwCvse620ECwkPaAFluV98S7fciLxssvIXcpT0JORT4O HQyQ== X-Forwarded-Encrypted: i=1; AJvYcCWJuXoovcQ7TrzLf7uf5vPM9LY6KgkLEsYgFoTQH6eHQNHHkT2R3f1OcO40y80JcPxoxc88JvOuZM+Akpo=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1ujdgbFVA5+9SxcCj6ubSzkLM2wiLePhCxxJcH2HKcIsSZVJu L3pNNipY5JBTfej+bMN0YVUd5erSHoteJdhpNJ0n+fOI2sjKBbw7CVD/kwxR3A== X-Gm-Gg: ATEYQzzEW7MK7+7VTQRsV+8A52HaZF7q0s6/2zNZ496MOwdgp5a5RS3G87RUTtPejgE w2kb7zYNjffr0dWeQPOydPQFQYvHNFrbemr2gWsvuAD5ClJzUdH2K9d27vVDHuJpLDPrKtSRx1h PxJ/XuMo4gq76Sd+RySWg6Q6Cew4Nu/CyRvBYODUv2RoC3cyzJAvcczKik7TyMZ6E6eQ5313t5F 4s+wGU0VhP3vZrwCFEDTljd0AZd8yyFgKys1We0iSVnfw+wmmK+jcEj6fiHSRLuMx/PIs06X0+b T9ZadUN8YuJ7wHxPdp5ps1Pvi+EiyML98rCkKQ5OSOcFKkaISDvVovCxxEhPR2DJb/jedRCrT66 P1VTtJXNCZH7gTbwwOlvf1EyWJ26WN919YC4ObRkIVpraUmrDLrenBZnQ4NkpLhGG7RB9VSPx5Y YQWkBZbTsoN7FGJrzZvC72hHzc4UK5KxS3Lwt0DmqA4MM= X-Received: by 2002:a05:600c:3f0a:b0:487:2439:b7be with SMTP id 5b1f17b1804b1-488996a34c9mr7304365e9.6.1775161079942; Thu, 02 Apr 2026 13:17:59 -0700 (PDT) Received: from foxbook (bfi53.neoplus.adsl.tpnet.pl. [83.28.46.53]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43d1e4d2971sm10185098f8f.22.2026.04.02.13.17.58 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 02 Apr 2026 13:17:59 -0700 (PDT) Date: Thu, 2 Apr 2026 22:17:55 +0200 From: Michal Pecio To: Alan Stern Cc: "Xuetao (kirin)" , Greg KH , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, caiyadong@huawei.com, stable@kernel.org Subject: Re: [PATCH] usb: core: Fix bandwidth for devices with invalid wBytesPerInterval Message-ID: <20260402221755.3afd7df4.michal.pecio@gmail.com> In-Reply-To: <74f1bb0d-24c3-44be-9583-0585863cdae3@rowland.harvard.edu> References: <20260402021400.28853-1-xuetao09@huawei.com> <2026040241-purveyor-bakery-a9f1@gregkh> <74f1bb0d-24c3-44be-9583-0585863cdae3@rowland.harvard.edu> 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=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 2 Apr 2026 09:56:51 -0400, Alan Stern wrote: > On Thu, Apr 02, 2026 at 02:59:35PM +0800, Xuetao (kirin) wrote: > > 2=E3=80=81Following Alan's suggestion in another email, should I check > > whether wBytesPerInterval is a valid value and handle it in the > > usb_parse_ss_endpoint_companion() ? =20 >=20 > Yes, IMO. Not sure, this could backfire if it turns out that these workarounds will need to become more elaborate and account for wBytesPerInterval. These descriptors aren't blatantly invalid. USB3 9.6.7 doesn't require that wBytesPerInterval =3D=3D wMaxPacketSize * bMaxBurst * Mult. Being greater would be blatantly invalid, but this is already being sanitized by the descriptor parser. > > However, when parsing the device descriptor, we do not know whether > > the actual data length transmitted by the peripheral is greater than > > wBytesPerInterval. =20 Indeed. Device is allowed (actually: required) not to send more data than its wBytesPerInterval on IN endpoints. UVC driver uses this field to pick isochronous altsetting capable of transmitting a particular payload each interval. If we overestimate, there is risk that the device will deliver on its promise and truncate instead of violating USB3 spec. We should rather pick a larger alt. OTOH, when a device lies and sends more than specified, this happens. Some HCs ignore the problem (and may overcommit bandwidth if we enable million such endpoints), others get pedantic and return Babble Error (my mistake, Bandwidth Overrun is specific to isochronous). I think this patch is relatively safe for interrupt, because drivers generally don't look at endpoint descriptors and submit URBs of class specific size. Case in point, everything works when you override xHCI allocation. It also works on HCs ignoring it. Beind the pedant I am, I would restrict this to bMaxBurst=3D=3D0 because that's the known problem case and IDK off-hand what devices might use bursting interrupt endpoints and what gotchas await there. Maybe add a comment that it's a questionable, spec-violating hack. Regards, Michal=20