From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.85.221.42 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793813769; b=Q9gExaOHbrDAdDisPJlecjI1oI5LbvVupULXai0NaY2IM3LN40VJ3cbJ/Ug2mYs9IBY3 Gm7PKIWZTOJmTdLj+DbSdolIr029x9cvODUAfs54YDxX5cpG3ik9CHnAKhxnXVZcYf9dg hlIqjsbfEE88LK5m7yXrIuK1ED5VpMlVrZqDMw5uKJxXNndNFAIpKRwlf2m/7Ody4sFN9 BpEJlmSZrjMhbGouoHDr+WmMdIWqHya2P+pE6OjVCPeilGwLmch75T0ea46sK1oEp/EgQ xnFE1WK3db5eWEkSh+FST2noDhtj9Wv1Lvy6vvFq5u80OwZxydWwuZt55PUT0aooXBQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793813769; h=DMARC-Filter:Received:DKIM-Signature:X-Google-DKIM-Signature: X-Forwarded-Encrypted:X-Gm-Message-State:X-Gm-Gg:X-Received:Received: Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type:Content-Transfer-Encoding; bh=6zWWmAM/EjSfX+fzNtWWpqxiPfU3InnZ+YWyZ8VpU1Y=; b=2uVU/lAHzM/gvuRd/Z4K1P7MyQtDu3hWvqEwNElRM4GSCk9vKtLS4DZbRae4n8EltTe/ jkpzxL4ADVzC0Zlq0I3QdkXwfJqiU/HU8owiop6eddhSfokY5ylvkNVZPcps7/D4ApvH+ Yi9ljm5Nc5AQ0bGGuos0k28TLaw0qAInYgJCWbpOWdbTxriMBaUxwOrxZQzGwKi5I+cZL 6xdvJN+0xKFhv82Olf+fqowBNuFZMURMRHMnYJ9IipF75PsUQp7SccFvJLsjsKzzhdNg5 fIdXXoOf84kh5yv6Bpg8FI7DvXsX5tL3MOsaTi3mgm9JzPD+p1OEKK9EYPouTiAOXYA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b="wufik20/"; arc=none smtp.remote-ip=209.85.221.42 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 602F6606A337 for ; Wed, 4 Nov 2026 17:36:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 602F6606A337 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, unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20260707 header.b=wufik20/ Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-48b042c0759so590383f8f.2 for ; Wed, 04 Nov 2026 09:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1793813768; x=1794418568; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=6zWWmAM/EjSfX+fzNtWWpqxiPfU3InnZ+YWyZ8VpU1Y=; b=wufik20/hF2eGBxiq5EJOIEIs3TvBuHcrkCWZl4iunPIc/jhCgNNuuYqUB/VKoz4nb rdlyC7Q0EPWILdkaRhUzDeEyKof0V28bqH2T0TlHfpRVt1Qe5Baf1lwWsvLU/75RZlbh bqB0ykMxUep4Ur8yvE6fkibug9V5IZpeyAAIDrui3507ekFUacV6zsNvNAAMT3plDzfU 264qGYsGhaynzVWx2lPks/HF4qzlYieu62zoC2GL/yrIul+6mlfr4wr5bM1HKLPEqyOl 5CCD9HtILxCwa+SUjsFF0ysOHZLYiIna7ALDMU7R2oKtXjqJMScQ4bK1U58WOy0n75d9 TakQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793813768; x=1794418568; h=content-transfer-encoding:content-type: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 :content-type; bh=6zWWmAM/EjSfX+fzNtWWpqxiPfU3InnZ+YWyZ8VpU1Y=; b=N4PHrcbTw7U+ER1Tj6l1h1xwGWImiyqAuLiPPGbb2Xnbxchh9EaKVSClo6lVS/bSLq BKItF0sPQ5sSMsOBB/Z+1EB4zh9UApHcj8yUNnuAB24KiyuftGYTNRHI4abeVuG5GABp U5eFLpXNqVu9p21CDFd6wfoat8HUpdA8sLgbyRCfvHGkGMdj5HVJNMVjV4F/cdG0pkRq AMUOSINgFaSL8Y86qC5pRzoX1ItXcBoxO/KDscSiSUY7v4vjG+H9gEtJ6U+F9fCQgN8w P+Sd9rpRlgpOwubLUpxYI1BkOUEgSANzamxg5SPpjF4sRYd+eNWTJTFxWZcy9LozGlt6 4hfg== X-Forwarded-Encrypted: i=1; AKwUvBxLxsaOFLMu/CW11k+qR0xtjixwGc6AY+YVEJECJ5MDpFJiQrnEsa/KFpKRquYPhwgQqSIm3M+Bhto=@vger.kernel.org X-Gm-Message-State: APuU4Z8RRJbyfxYHBQ3gKsleC/rmqTFXP+Wb1LoJTesXUgAmiQEmPLCU 9/StdCs8b7mvdzN5rrqs5xlvbysjOK4vNxQ2JkvQ3wNjZRXsLhZeLMbV X-Gm-Gg: AYBFou2suvFxMOmOgEO9SB1g/B9YIcb2b/x8ayLRopUb1P8R7v5NoxLFt9WJRI1XP+1 kjLy7ZZf141sxODf0m8fRrNeRI8qw4kS4qdu6UYpSZFAoq2oxOaPtqetMtzL2MOfPEMeSrqAYq8 +eLJ2/4+/uM7Ad3Gqw4Y0cwm1QESkzRqCRV1YHNZWHGQq6k2H6wGSlAPuti3wgi5N5xaLktSLf4 0WKBZbwSLvNsPWpxjd5xmywpKUzj9Sy1WnwOkTHZz0TqNcCP9n1UfKxvxJ0Wf3wHyeFKlkUu90d Etwqa2qXIVS+n/ZX+BWn5U/c9KW8HyaxgGv2YZ9QWC9resheXlMJE6DgsZoJI5OPmK9aZJmaq2k uNkGXZuXzr96Ww3M8Zx5PoIB7gRHTDPd1BcXfnCda7yUvK3MV3+oXPmkyQ6dSSNmlCTec81j6dW WCQ2uot0dTyqkfOY8NV7BHZNcFZugjxtvwQBGnxHxWTgkg8TPXAv8FWtxSt3+heJ+TzN5LmmohI M/59qOERBwji0L0sslF42Ew0O42SEbdCcBOAacGGcArgKK1Kw+t+S6tUvK5PkMTBscPC30fcYuH ueMlsZP3esMSn/XkMTeNFK6str1ucprRS30buIHCsynvpjriB322qqemJQ1y X-Received: by 2002:a05:6000:400c:b0:48e:35d4:55b5 with SMTP id ffacd0b85a97d-48e6e518368mr33802651f8f.52.1793813767532; Wed, 04 Nov 2026 09:36:07 -0800 (PST) Received: from foxbook (bfg124.neoplus.adsl.tpnet.pl. [83.28.44.124]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48fecac2772sm4825519f8f.18.2026.11.04.09.36.06 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 04 Nov 2026 09:36:07 -0800 (PST) Date: Wed, 4 Nov 2026 18:36:03 +0100 From: Michal Pecio To: Alan Stern Cc: Pengfei Lv , gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, xuhaiyang5@hisilicon.com, xuetao09@huawei.com, caiyadong@huawei.com, suzhuangluan@hisilicon.com Subject: Re: [PATCH] usb: core: hub: Re-guess ep0 maxpacket size on reset Message-ID: <20261104183603.17d663ce.michal.pecio@gmail.com> In-Reply-To: References: <20261104124402.1269650-1-lvpengfei20@huawei.com> X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 4 Nov 2026 09:59:24 -0500, Alan Stern wrote: > On Wed, Nov 04, 2026 at 08:44:02PM +0800, Pengfei Lv wrote: > > Per USB 2.0 spec section 5.5.3, the ep0 maxpacket size is fixed for > > all device speeds except full-speed devices, where it can be 8, 16, > > 32, or 64 bytes and can only be determined by reading the device > > descriptor. During the initial enumeration of a full-speed device, > > the USB core guesses 64 bytes (hub_port_init() with initial=true); > > after reading the descriptor, the real value (e.g. 8) is stored in > > udev->ep0.desc.wMaxPacketSize and propagated to the xHCI ep0 context > > via an Evaluate Context command (xhci_check_maxpacket()). > > > > After a port reset (usb_reset_and_verify_device() -> hub_port_init() > > with initial=false), the "if (initial)" guard added by commit > > ff33299ec8bb ("USB: core: Fix race by not overwriting udev->descriptor in hub_port_init()") skips the ep0 maxpacket > > guess block, so udev->ep0.desc.wMaxPacketSize retains the real value > > (e.g. 8). The xHCI Reset Device command preserves the ep0 context > > as well, so the xHC ep0 max_packet also stays at 8. > > > > When the subsequent re-enumeration then uses the "new scheme" and > > issues a 64-byte GET_DESCRIPTOR (get_bMaxPacketSize0 with size=64), > > xhci_check_maxpacket() sees hw==sw==8 and does not issue an Evaluate > > Context command. The xHC queues a Data TRB of length 64 but applies > > ep0 max_packet=8 for short-packet detection. > > That's exactly what we want it to do. Should we want it, though? Were there known devices with bMaxPacketSize0 <= 16 which required the whole transfer to complete before they are reset? That's not what happens in the initial iteration, so it seems any such devices would always take two iterations to begin working. Is this what the only correct Proprietary Operating System does? > > If the device's first > > data packet is exactly 8 bytes and it sends no ZLP, the xHC does not > > recognise a short packet, keeps issuing IN tokens for the remaining > > 56 bytes, and the control transfer hangs in the Data stage until URB > > timeout. > > That is the correct behavior. Indeed, the same issue applies to _any_ > 64-byte transfer (not just control and not just Get-Descriptor) when the > maxpacket value is 8. If the device sends an 8-byte reply with no ZLP > following, the transfer will hang in the data stage. That's _supposed_ > to happen. Right, all those details about HC behavior and xHCI internals aren't important here. The device is out of spec, apparently expecting the host to always use MPS=64 for this particular request. It should send the full descriptor in response to further polling. More useful would be information about impact: what this abomination is, does it always fail to enumerate on the first try and trigger this unsuccessful retry, or only in exceptional cases? And of course, > Have you observed this problem in actual testing or is it purely > theoretical? Regards, Michal