From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 AC8213AB26B for ; Thu, 2 Apr 2026 09:44:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775123074; cv=none; b=DpWduxq9xeet5hRbE9qMDA00RHtPK4vjx3DYyWjLQ1OavrAxr95EzELuQ42QEpd21nR/paMJXbLsCnq74Rm4AZFkoIBXuea688r1p+63YVZZcdtsmxVRJV6lC91DfRqFvBFnizk1eOEbT/nM1o3gPggLcL9k7X10ywnIR9sPyb4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775123074; c=relaxed/simple; bh=MVk8UqusO2YAJThlmcP4EVqF+YQQQUkUublTM8NTy4s=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YgiTggRP2Fhf3HsE05tzfiuK+epqFr5IPh5yUzMY9wXdpiblFUqJZ67XH2AzUwm4KTYcAP51TZFYyYKQ5tfAnNxl7pFxFCIbYRBe+3kfRoAldIsKA5MJpGcsFWp5xWCRuURHypTIzBC0KcZdteFSS960zp5xk0EYGXTqMgwQrRM= 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=W9+y0ZN8; arc=none smtp.client-ip=209.85.221.47 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="W9+y0ZN8" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-43cfd832155so355674f8f.1 for ; Thu, 02 Apr 2026 02:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775123066; x=1775727866; 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=qhy6UcHsW2sEceIgi+BWAq7/HDA3iTNjZpezFJtrBio=; b=W9+y0ZN8LziExoDQsUY7gSi4YOrW/R+aZBw1k8L1RrmVCjiDVykV7ISoOjWSd+5bwP ridMnzpA1tOXLWmkVAuBSkG1ciHP6gJzSj9gBQSRIR1bvhiDcSoGDeNc0M7qYdnS8ARK Wbj5dfo5SaLjDqp48NUGMeQ2JHc+ykHRcJvTKj6HIuRs8uYt2MWNXFCbrP96WkpitUOa DcW6KQ2IcZCclC2vy5ql1uKb5itUHyq969QNpZVY1ARB4WVMexsNKeui5C5Nz55m0CzH Tw+TFQPMACp8Tr6GArrrehcsxZa+pZgHjlfuvrEhhXlxYqHNlW/6pj8QNL7kY9fbpW7H QlkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775123066; x=1775727866; 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=qhy6UcHsW2sEceIgi+BWAq7/HDA3iTNjZpezFJtrBio=; b=EaPd6CHurj74HMV2Gg2YXgWkPB6K3XkTRcacLTQHRY8hR9ltvhIJm3/PIe0EOAd+tp ieNlFSka1zdik0jnB2SkDgmHL/lOI6XhN8VSXGEGC8J9Lt6SkAOXmf5ddP6uDcQ2tdsn sT6rwHclJ26XCjmCbo2pT6B3/IJ2xiRxP+Mk9OAcZlo1kZUMEqWVTOZpF6r82VL6gGjR x5/F9pD1rEh4VkXsCNfx05ZzPentfkO1jd8R9L4N5dDrsRonlTMORB6Req4m0by68oo7 vRKDBBwSzIFZmKcNAzsjfESFNw/ggrir20BkkIo2O28sE9hZE29oQ42LTvzMI/DkM0/+ ApRw== X-Forwarded-Encrypted: i=1; AJvYcCWSsVV4AsR9V7E7CvY47u26ScaW2hi3ZWZDs1JLWk8TfT/QQCJoY7Zpfldx+bxERjkocds3FKqVNUo8WNI=@vger.kernel.org X-Gm-Message-State: AOJu0YxeulfZCAlLEn9X5tCP6mDO4ouysQS5pHSK4pDTWEnQO1/z/jjf dq0OLS7bCgJ9Fm/9oQpwkAbl5tOIFLrUUb7FYP+Ir9TgQ2SRZIJsx004 X-Gm-Gg: AeBDievRRom95UY+cCh0EwPlH1147qP0z5sszYBpNvt1M3/1V/6MJ9cAYjuB+jhfVmG Yi2gCogkewIxc+O5Qj4J6+cIYBnnb2wNohYyXZfzDu+iKs2lKqJaCHD2OOwGT/P0009RQa+8sxc of16QBbtD3zpKkUGmjVJc6C5VIiMqgNfHnkX7RaCXZ7YTq1EfYgzFh5Qaxr8PIlLgXp5sb/8Eat BxUZp5zguSLlMw0jNhdb7bSfpJQiIZdpA8K1wV2JB24f44ossOm4H8Oc1EaEtdSNzW02kEA5Zlz hVC47csB+kwAgPMDESZLlYSKuL9hpxe3e5X/FEXcJToo1qEhf0OXdlIns43P7yAKfx/ObpMd6bT 7t1QD2UlHbbe+8pv6VnrgdjOAD8i/UheUtueUDKOl1mqCwZtrC+z8A3OyeqM+ZKGRGYHcrMhPOK IoVIuwLMiciIjE4oqXTIJr2R3FDg4Nx9m2 X-Received: by 2002:a05:6000:230c:b0:43a:4de:fdc2 with SMTP id ffacd0b85a97d-43d15051e7bmr12856124f8f.13.1775123066185; Thu, 02 Apr 2026 02:44:26 -0700 (PDT) Received: from foxbook (bfi53.neoplus.adsl.tpnet.pl. [83.28.46.53]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43d1e2c50a7sm7052418f8f.15.2026.04.02.02.44.24 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 02 Apr 2026 02:44:25 -0700 (PDT) Date: Thu, 2 Apr 2026 11:44:21 +0200 From: Michal Pecio To: Tao Xue Cc: , , , , Subject: Re: [PATCH] usb: core: Fix bandwidth for devices with invalid wBytesPerInterval Message-ID: <20260402114421.738e375a.michal.pecio@gmail.com> In-Reply-To: <20260402021400.28853-1-xuetao09@huawei.com> References: <20260402021400.28853-1-xuetao09@huawei.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 On Thu, 2 Apr 2026 10:14:00 +0800, Tao Xue wrote: > As specified in Section 4.14.2 of the xHCI Specification, the xHC > reserves bandwidth for periodic endpoints according to bInterval and > wBytesPerInterval (Max ESIT Payload). For SuperSpeed endpoints, yes. This follows from USB3 spec 9.6.7. > Some peripherals report an invalid wBytesPerInterval in their device > descriptor, which is either 0 or smaller than the actual data length > transmitted. This issue is observed on ASIX AX88179 series USB 3.0 > Ethernet adapters. Damn, it really does. Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 11 bMaxBurst 0 wBytesPerInterval 0 Any other examples besides AX88179? > These errors may lead to unexpected behavior on certain USB host > controllers, causing USB peripherals to malfunction. Out of curiosity, Bandwidth Overrun Error or something worse? It's an oversight that these URBs aren't rejected with EMSGSIZE in the first place. IIRC zero-length interrupt transfers are allowed by USB specs and a zero-payload endpoint is probably legal per xHCI, but then submitting non-empty URBs to it is not. > To address the issue, return max(wBytesPerInterval, max_payload) when > calculating bandwidth reservation. > > Fixes: 9238f25d5d32 ("USB: xhci: properly set endpoint context fields for periodic eps.") > Cc: > Signed-off-by: Tao Xue > --- > drivers/usb/core/usb.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c > index e9a10a33534c..8f2e05a5a015 100644 > --- a/drivers/usb/core/usb.c > +++ b/drivers/usb/core/usb.c > @@ -1125,6 +1125,8 @@ EXPORT_SYMBOL_GPL(usb_free_noncoherent); > u32 usb_endpoint_max_periodic_payload(struct usb_device *udev, > const struct usb_host_endpoint *ep) > { > + u32 max_payload; > + > if (!usb_endpoint_xfer_isoc(&ep->desc) && > !usb_endpoint_xfer_int(&ep->desc)) > return 0; > @@ -1135,7 +1137,12 @@ u32 usb_endpoint_max_periodic_payload(struct usb_device *udev, > return le32_to_cpu(ep->ssp_isoc_ep_comp.dwBytesPerInterval); > fallthrough; > case USB_SPEED_SUPER: > - return le16_to_cpu(ep->ss_ep_comp.wBytesPerInterval); > + max_payload = usb_endpoint_maxp(&ep->desc) * (ep->ss_ep_comp.bMaxBurst + 1); > + if (usb_endpoint_xfer_isoc(&ep->desc)) > + return max_t(u32, max_payload * USB_SS_MULT(ep->ss_ep_comp.bmAttributes), > + ep->ss_ep_comp.wBytesPerInterval); > + else > + return max_t(u32, max_payload, ep->ss_ep_comp.wBytesPerInterval); Obviously a kludge is necessary here to make these abominable devices work reliably with xHCI, but OTOH exceeding wBytesPerInterval violates USB3 9.6.7 and it's unclear if all devices would be happy. There are devices which define such odd isochronous alt settings with apparent intent to allow fine-grained bandwidth reservation: wMaxPacketSize 0x0400 1x 1024 bytes bInterval 1 bMaxBurst 0 wBytesPerInterval 512 wMaxPacketSize 0x0400 1x 1024 bytes bInterval 1 bMaxBurst 0 wBytesPerInterval 1024 wMaxPacketSize 0x0400 1x 1024 bytes bInterval 1 bMaxBurst 1 # 2 packets per interval wBytesPerInterval 1536 Isochronous drivers use this function to size their URBs or select the right altsetting for given bandwidth. UVC has obeyed wBytesPerInterval since forever with no apparent issues and UAC has recently been patched to work like that too with no issues so far AFAIK. Maybe start with something specific to the known bogus hardware, i.e. interrupt endpoint with one packet and zero payload? In such case it's high chance that the device actually meant it to be wMaxPacket. > default: > if (usb_endpoint_is_hs_isoc_double(udev, ep)) > return le32_to_cpu(ep->eusb2_isoc_ep_comp.dwBytesPerInterval); > -- > 2.17.1 >