From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (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 C4A3736D9F5 for ; Mon, 10 Aug 2026 06:12:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786342341; cv=none; b=GtZBe3CfQzZTGVvdQIylTy418RXAU4mDYJ1a+rllQfXfgYRe2+Jh0QcLCXuKOw2L+Pg/vHUmJpVbWJ/Hi33phV8wuTD2WXeoO2KlUZciA/e7Azt/jnyWDKv/Ycr0E9rBqdMTGGx1t41k4GkSNjq1jP2d6NPLCKZ/xlbTVnEySe0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786342341; c=relaxed/simple; bh=CcJOyrNv/v2EaQu2FZ57TDe+Cl1Nf2GThdi/dHHT7iE=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=bh8zkS2kOdQpm9ZNa1reIt7w3pSnNgMDbLiTHZ19JhqSS8mUgBWfl8ufFWLCDCZ4PeEoEMMZ19quXDnOANidZPnRmDdDMDoi9EQotavkeWPy9dDYj9YPVSJcxMV8o66l6H/imARA2qhXmZC0hCmgOdAiWBteKEXhWqwgMx/BnyU= 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=NbVndAh7; arc=none smtp.client-ip=209.85.128.45 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="NbVndAh7" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49557167508so11900215e9.1 for ; Sun, 09 Aug 2026 23:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786342338; x=1786947138; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=F5NO9iuQibAOt2y4Xoj9Oz8+6b5gn3Kh/p2fleGsaSw=; b=NbVndAh74JFeCydI305fCTbXcqcwcwN8EcH6NcHYLjIK1limQssHZ4ir4u1cHVahMB AOg/kQSQ1avDkQgtS93tG9Nz5F9WusPqegDo2RrFzLtvYZVA6kHO/p4OF/Zg/MeOoba6 U0VPnoZVe9u419KtIXDqHAnAEMFLl2TZDUih8O4gS3dn9mtHq2yl0ejD4KDzjY9R1XgL klxcV7Mwqu48bEzdiuqNDuGY1O1n303SEJhKYitVQ5od7XkmvPb7xOH22OB4tYSVbb58 wMxqx6/LfJ66Xemp+eudiWMmKxdzWvR9L74A1Q5xskAmi+56wlDpy8NNorpld1a+CqZz K51g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786342338; x=1786947138; h=content-transfer-encoding:content-type:mime-version:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=F5NO9iuQibAOt2y4Xoj9Oz8+6b5gn3Kh/p2fleGsaSw=; b=oqPPn+kJBLZJ9byS+JIsOOgYEM3yAFT2TtNGCfKBhAYuVAsci1c32bkEjPkwLx31Pq cyvKHSFcB5PFhd6Cojwj8rMGL+gUXNcNW/16S0TMimuwFAq2hOVsMwZow6D5aGc+rCKa 2bIp8z29ONF2B4AbYxdKsQI4i8bhjNStis1UITHF8hwKQ8lneJS/Fxax7Ktw6gGIhlSp y7GcWSCcS+YaccLr/mzbe87BzbN6KPD0SAGHzW5/S7sSkdyXMv2jibbxV29yWxJAiWid gM1EUPHO7sOdGvz7t3cP7qojpxGSsnD8+zmHFJSjgKRyk+1XX0/7kPjunIO+W383wS8S EkSQ== X-Forwarded-Encrypted: i=1; AHgh+RrruogArLm16Mr1G/yxienvCHkisUToF13hAEPps9jsxWtEfjV/OBabaRGA1udujddmIQtj7lSAz06QpxU=@vger.kernel.org X-Gm-Message-State: AOJu0YwJG3cUfVdC0JPucOKZKm6+uPRee66Iwv3TLfVXKmTtNEfeTUz8 LJocsv64nTZbt11GFyQX/2nLPn47nv5kDwRbdhVflInm/wxudCNPYQEM X-Gm-Gg: AR+sD119Vl6vmBtZbyyjLvoiDMPs3XKQyeAfWcpmbqrj/5ybXR5B5B9Pb3k1ISwvNjp bi24e5bJURa2VYlgVIxctOsyaDWXiEtRHIuPN17hebBObkm4UH1tgtBVpbi8mwNb89XMQOqrY1p PE5IxyFNY9K/glH88UVfOXkKmeR9k+ASPVykk7Dm/QRzgm9bVuvTEFIdtrcWeozUjq7Sj/901Em KviEyOfSPdfiQWEX0he0xVO5FqRC7bzdEjnkVOSC5EIdHlhIvg9I7tLAnHbY098G+F8MoV3FMAB WfI6NfXrTn7uUFuCJZ+WI0QI910Yj7v3rxBhkJpTvZf3I8LKmTJkQet4IuIgkqCsAmDioyUcAQo 8X9C/KR7h6ifx9NFjCLFoY91Nup6NzO7j7VR4Ii3rZhqTk+BL4dRIAOWLkzLQicCq0MJaHcM4cZ +my2etw5j/HG98Tn7mpKT0AbQf0dpWr4nz34k2slJDluOTpWZnTP7iAbd8IOH+MH+WMxrfxCWR X-Received: by 2002:a05:600c:1d23:b0:499:51b8:d649 with SMTP id 5b1f17b1804b1-49951b8d652mr455964575e9.3.1786342337792; Sun, 09 Aug 2026 23:12:17 -0700 (PDT) Received: from foxbook (bgt135.neoplus.adsl.tpnet.pl. [83.28.83.135]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4995420c68fsm356032505e9.1.2026.08.09.23.12.17 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 09 Aug 2026 23:12:17 -0700 (PDT) Date: Mon, 10 Aug 2026 08:12:12 +0200 From: Michal Pecio To: Greg Kroah-Hartman , Alan Stern Cc: Mathias Nyman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] usb: core: Remove unused SuperSpeed EP0 maxpacket handling Message-ID: <20260810081212.59877d78.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 512 is the only control endpoint max packet size defined by USB 3, encoded logarithmically as 9 in the 8-bit bMaxPacketSize0 field. Up to v6.5 in 2023, core assumed 512 and ignored the descriptor, but now it tries to decode and use it. One (emulated) device was found to specify 8, see commit c78c3644b772 ("usb: Fix regression caused by invalid ep0 maxpacket in virtual SuperSpeed device"). Thankfully, xhci_setup_addressable_virt_dev() always initializes EP 0 packet size to 512 and xhci_check_[ep0]_maxpacket() has never been called on SuperSpeed endpoints, which means that none of this has any effect and 512 works for all devices ever supported. The regression was caused by core refusing to enumerate bogus devices. Drop pointless calculations and correct misleading logs, because we don't actually use out of spec packet sizes. Moreover, some HCs (NEC/Renesas, old AMD) reject them, though others don't and there is some effect - enumeration fails with -EOVERFLOW or -EPROTO. But those effects are only seen when patching xhci-hcd; altering ep0.desc does nothing, even after the usb_ep0_reinit() call. Signed-off-by: Michal Pecio --- By the way, xhci-hcd only updates max packet size at full-speed, which means that the high-speed workaround doesn't work either. Renesas does accept high-speed overrides, this time Etron doesn't. Whether any of that works correctly with actual devices with unusual packet size, and whether they really need a workaround (unlikely if all their descriptors are shorter than bMaxPacketSize0) is unknown. drivers/usb/core/hub.c | 23 +++++++++-------------- 1 file changed, 9 insertions(+), 14 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 5262e11c12cd..d9409943f388 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -5143,22 +5143,14 @@ hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1, /* * Check the ep0 maxpacket guess and correct it if necessary. - * maxp0 is the value stored in the device descriptor; - * i is the value it encodes (logarithmic for SuperSpeed or greater). */ i = maxp0; - if (udev->speed >= USB_SPEED_SUPER) { - if (maxp0 <= 16) - i = 1 << maxp0; - else - i = 0; /* Invalid */ - } if (usb_endpoint_maxp(&udev->ep0.desc) == i) { ; /* Initial ep0 maxpacket guess is right */ - } else if (((udev->speed == USB_SPEED_FULL || - udev->speed == USB_SPEED_HIGH) && - (i == 8 || i == 16 || i == 32 || i == 64)) || - (udev->speed >= USB_SPEED_SUPER && i > 0)) { + } else if (udev->speed >= USB_SPEED_SUPER && i == 9) { + ; /* Logarithmic encoding of 512 */ + } else if ((udev->speed == USB_SPEED_FULL || udev->speed == USB_SPEED_HIGH) + && (i == 8 || i == 16 || i == 32 || i == 64)) { /* Initial guess is wrong; use the descriptor's value */ if (udev->speed == USB_SPEED_FULL) dev_dbg(&udev->dev, "ep0 maxpacket = %d\n", i); @@ -5169,8 +5161,11 @@ hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1, } else { /* Initial guess is wrong and descriptor's value is invalid */ dev_err(&udev->dev, "Invalid ep0 maxpacket: %d\n", maxp0); - retval = -EMSGSIZE; - goto fail; + if (udev->speed < USB_SPEED_SUPER) { + retval = -EMSGSIZE; + goto fail; + } + /* else: bogus USB 3.0 descriptors exist, we use 512 anyway */ } descr = usb_get_device_descriptor(udev); -- 2.48.1