From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 30AE72609C5 for ; Sun, 28 Jun 2026 20:41:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782679318; cv=none; b=lkoj9uzCqKrRpKWYAwBwEDYjNPVfrFOCC834uugVyKTYfllhPPKtO1+42YFgdL8n4Vl+mQzy1SKOb+hY0oQcQXccRspCPo9AThYUDtKu1nCt+tLkPiRRMLCcNwUfWGo3DcOJDPnjmoXdfRGbbWSiCYe+XdGA/sv6EaVFJquDK8w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782679318; c=relaxed/simple; bh=j038mUcZjm4sep8U2CON12rveC0DF5YhYcieF8knB5Y=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=H7hGwkcCu1ItaXi24frEtv0+2p/lV0tFXhODayYxY5q2smHiuwd6GGqkeI6txDn/Y1UouX1U0x7O8gxIsOZ71IA2lUllj89A0K9b99JiTeBi1CjBSidpsqn23i75dMrkO9Rbh8WR/oevVjL244dDdVZsEL+IAZRB4qO1yLe2T3k= 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=ouMvpPmf; arc=none smtp.client-ip=209.85.128.54 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="ouMvpPmf" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4926046fbc5so30185175e9.0 for ; Sun, 28 Jun 2026 13:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782679315; x=1783284115; 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=EjHbb/zbi5lY1Aux2naQDbYxfNt6M3ms/FuKtgATrAE=; b=ouMvpPmfZDeWdnA0zR+StyyfvNvqq2pWlaR3aguERJVMq+jLcR3fgsQss8oJ6iDjTg 99aLrye0Bbgt5YwqdALjiJA+h/EIq7X3+qd9rpYMiH4xTwZSAzzypqm+XZFSq+GSrJGj gpUoRRMTGgbv36svLxbNW50AEfCT/7FmOySduV4tiqHj0aVN5NkPgT8xtu3y+IjUV1Kd XgcHN8LQIztle4t6F3680bKTnNV88fLP/dmdoJwAl4KJYNj/NrBIHaHkFCAMVrXdFOF3 szOAshHMQ0leTWXThWjhOzJoqi6fsxdguTS/951W5RUXDfp6R41CF6PcPmKfmTqT5XWU BSWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782679315; x=1783284115; 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=EjHbb/zbi5lY1Aux2naQDbYxfNt6M3ms/FuKtgATrAE=; b=E9prvksXL7DdNL9NhmDJP592Q4TrKEX4q0J++m5eFDTBpUOBQqbog4y/zr0atFIBif Pm6zZR8QakX37DA0ZU16lznswz809QpsVk3ys05AGD+nW/veiZjJLJ4IBoY3xUQopepR ABKKkllvgbPBFMNdQH22JaXjO0Kaem2u1ZdqHCLMX7VJd24vjFyv7ZLNYMSOKJMW/Jp6 YQRseLWuJdinaRoGRNW+DMR7ae1fNXrqEInfgEkUW0kpUurCYYuZN51VRd2mii+U7clB VcPM/rWBd8vEHiFiVD8HndqjqI9/FLjbR3mPZ7L2h+6iF6gv+GM1pHPzGgG5TVIdoK0e hWMA== X-Forwarded-Encrypted: i=1; AFNElJ8MOhxN0ljzY3FhhVpD1h2kHFOx5rKXAPNtP2YxiPC9nuLqewpyG7o5y+JI9KDu1mpXAwPguyuoJNUoDmg=@vger.kernel.org X-Gm-Message-State: AOJu0YxuwQL9I6VXkmBy49xx5yVG1M5CcXWhpElbY4FmmEEg+F668Z6+ S+Jysd0HIG0KzM63i8oORE2cZGnQSkuq5SFkrNCwbK55Y/S4fBUG+zyT X-Gm-Gg: AfdE7ckV8yr2Zmp2FwEne7a2+dKe1Hhx+tKs1fXduWOndm8eWzX8YU16qxYTNilepfZ HnCQx5k8/hKC6u7xKpH9j8+yLAqvms1omUfdYYdwADkUTZvG0m6Mq1XKr/NtLbG0OAkfzuf9RPu PrA42sTSli0rNVdTQ8MP2uQw0MSCtvTFCqerSb+Kbplhc88mmZgRaefcqorkXD8bG8GYv8CVY9F bVCTxXoXnowEdnpEknZv0VKFV4dxSIF7EATFjH9XMpiOxrrEptuBCGTwp3gmr2wp0O/q8FGu9Xv g4geYtzVybbausB7cqCwg8LThhfDVaIX9jimH8Pr66jEX6DdfsNHIdSPRaMIrtFlumBpqYdr5J4 sL3Hrcj98ww/s7MW4jQArOifR/SROTgMZU0v09bG7L4EHwGIKLeTY6y4Jb+rdADEvvZ/jhfx4GP 6Ud6s0EANwR8isEUXzs+2vzDXw X-Received: by 2002:a05:600c:4e88:b0:493:ad8a:e7f2 with SMTP id 5b1f17b1804b1-493ad9a2b29mr18360745e9.13.1782679314528; Sun, 28 Jun 2026 13:41:54 -0700 (PDT) Received: from foxbook (bgu190.neoplus.adsl.tpnet.pl. [83.28.84.190]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49268fcee16sm276918785e9.2.2026.06.28.13.41.53 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 28 Jun 2026 13:41:54 -0700 (PDT) Date: Sun, 28 Jun 2026 22:41:50 +0200 From: Michal Pecio To: Alan Stern Cc: Nikhil Solanke , linux-usb@vger.kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, corbet@lwn.net, skhan@linuxfoundation.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v2] usbcore: Add quirk for 255-bytes initial config read Message-ID: <20260628224150.39990d04.michal.pecio@gmail.com> In-Reply-To: <8f5bb295-fc1b-4698-8f2f-2d40fb4d9f93@rowland.harvard.edu> References: <567e8866-4308-4e5f-819c-fe778dbf74f8@rowland.harvard.edu> <5159fd69-dddf-4073-a8e7-95fa77de0b7f@rowland.harvard.edu> <02060df3-b8c5-4a86-b3ab-3a28eea8a562@rowland.harvard.edu> <20260628165040.76fd608d.michal.pecio@gmail.com> <62e1fab3-1045-41f3-bc74-4c7624011619@rowland.harvard.edu> <20260628190201.00afdccf.michal.pecio@gmail.com> <8f5bb295-fc1b-4698-8f2f-2d40fb4d9f93@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=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 28 Jun 2026 15:18:02 -0400, Alan Stern wrote: > On Sun, Jun 28, 2026 at 07:02:01PM +0200, Michal Pecio wrote: > > If such devices will exist, then it probably won't matter whether > > the delay comes after or before the first request. Purpose isn't > > known, but it appears to be rate limiting configuration descriptor > > requests or delaying other requests after this function returns. > > In fact, the commit that talks about the Logitech webcams does > describe their buggy behavior to some extent. It says that they seem > to reply with stale video data instead of the real config > information, and from there it's a short guess that adding a delay > gives time for the video pipeline to drain or time out. > > In addition, the fact that the delay is needed after the first > request but before the second suggests that the data corruption only > affects transfers longer than 9 bytes -- which the new first request > would be. Therefore it would be appropriate to have the delay before > the new first request. Whether another delay would be needed before > the second request (if there is one) is unknown. Fair enough, that's possible, but even in these specific webcams it's still unclear what delays would be necessary with both quirks. We wait for the HW to complete something, but we don't know what starts it. If it's device reset, then b2a542bbb308 has already doubled all delays so d86db25e53fa6 isn't even necessary anymore. OTOH, if it's the first config request, then a delay between the requests is mandatory, and a delay before the first request is useless. If it's something in between then your approach could be the only viable choice. I would worry about it when a device is known that uses both quirks. > Good point. But I dislike messages that actively produce wrong > information. Nikhil could get rid of the parts of the log messages > you don't like, but he shouldn't leave them as they are. He could > even do that in a second patch, separate from this one. I can agree that the first "descriptor too short" message becomes misleading, because we no longer expect 9 bytes exactly, but anything between 9 and 255. So this could be changed to "requested". But I see no need to change the second message. Regardless of initial request length, the next request (if any) asks for the exact size and we do expect it to produce 'length' bytes. Using different words in these messages has a beneficial side effect of making it possible to tell them apart when wTotalLength == 9. Regards, Michal