From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 55A541632DD for ; Sun, 28 Jun 2026 17:02:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782666129; cv=none; b=c07ax53aA8hgdTDNeDILpiDq3EpPbUY4rAjMhB268D/SPpO8hEs/esT6fBRuhpdzIudFO3FaQ9naxkBAwcrXpfFtacCtzgpbGhnd1MYsMdMq56sTZNPh3P1d0ZXWkFn8ahhSfnyAhQTSuOp3e/dCfpuYzvfpM3JVfHKd0bwz39Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782666129; c=relaxed/simple; bh=3OsNKGn84AmZ7EpZHONA4D/sDqC0/NfOYHvlRuLYVb0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=C3SUYBCKeAYGldQg9XcFgDGaxmYqv+NVnbRMcK2a18P+pTdHLBqU9kqU68f4xOC4K/KmpzJY/xv85cmUZjx15XlHT9o97zY/g3xaCUJgERq5/dkFUQkoSJIF39ZsZXhX6FSgHT5fgYDXPrlf5G2ahmXgJ+1quytLyqKd78Ly10g= 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=pEOUIvb/; arc=none smtp.client-ip=209.85.128.43 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="pEOUIvb/" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49395888c7bso15425505e9.0 for ; Sun, 28 Jun 2026 10:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782666127; x=1783270927; 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=aVQvFBwvnO1RdffMStECk4dJQSfRULIl6EHx460540M=; b=pEOUIvb/4MIZkIuL+pC95YgEKqOE62Ma0vBd6s+iBvLfa4aFcauDFP3TOK8NtSvGUZ BsbIp2vR3PdopNLUsJLT/zMjgai8EU709ZC0npyt2918w53PA7OBXsPZKo5KjtiOoLbs zJrcloJG42z+LzTu1ns6hXqIcI+o9dSrwujg2oyeOMl263JyOwnnAJ6eAJz+xvxTBMgq iyLq6Cw4Ao76/hK9xS/Av8cNk+2yXcjfwo9fnQ5pjL5h4CSwH4GUIGPt6BcPIJTRr/o2 K8T7FU9Z6+4xhLBFB59bLLzSmXxJ4pSWCrDYX6j0i40+4aSnqtZjxR6+5R/xQATe7UR7 v2nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782666127; x=1783270927; 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=aVQvFBwvnO1RdffMStECk4dJQSfRULIl6EHx460540M=; b=Rndoxc5ODoCauQ8cLa1IbVbZzOaFocp+pD0PLkfqAMw4f1RnCzdI1TPK+y7xmqLlQn It/AVt9yW+E959auytKz2WkuJ7v7kijcpktJGUBvr9X1em3msuznu0PwtRq4DSJtXpbg TulC/AXpt6uNQUAJPOxDryUZw8/F6r872zvoh1vd1BpXljcKin1b8+gtqLUNgwmCFB3x +NLwUphGICfdnGrdoY0QqEgJMlW9XNphNSG9g4bieekHQ36ebaUtdf6MypJBYEyxqjX7 34GgXi+yMSJ8O/pxWbpvlPu7lo2+8ZkR5ZLa7H70tuzquRezJ15FLDzWjEXskJNR8Hvy Gn1A== X-Forwarded-Encrypted: i=1; AFNElJ8JY+RakSxUFfaxCXityFoR3XuUj+JOmCn/OV+/LmhvnKl7fOwGPTg7BPiIFysGEBnP3EOtBkw5A/0DI8s=@vger.kernel.org X-Gm-Message-State: AOJu0Ywnnz15yEJF+4JDZQf7f816m+RQZcMYJjP3+xgp0u1Pg/ViF7E9 sAXLfHuQA70Kl0kcFm+/++K0K25bvBvVXMQPe9GYEgH4+7lN0twSb7+h X-Gm-Gg: AfdE7cnrrTAuLzVAPziq9GaJNt4od/V3JB0rsUQbMs2DDal3nmDF01t7GXUrhDibuGk 9WqV4nluqRnWD5JzPHglrcGmpqgIzE5xeEqKtvF5eiI8PPMM8I2flYmwStGcULBfIhhljEu8TZ9 jiaMFpcQkGsvJwVuGeT2JQ/xVupBXcfrTHd1Jnqjkgcm19kU6F5rOMkjLASFK6HWpwZXmfYuA+t dpD2L9nE64KJjD6npLQ9v1lt269wudTTwM0axrLW6SFik+3MGw96KEV2+t5yozzSWRDSPrZeZRb Iea5NRnzBY23ed9V16dQXv/RsVv8m2OcxpWci6TZQhGUyjKYrG4aXvo1puPi8T6RUBChvjwSDRp GKkW1O+lCSsJ+ITWE1+G2sA6uvB4dcXwdavLTuLWwsYdYRgR/3fcbZSrOzSh0gTGrAG3xUn3X71 oEoDJyTBrnLzf+OrOyEFZE3p2K X-Received: by 2002:a05:600c:c16f:b0:493:a7fd:15d6 with SMTP id 5b1f17b1804b1-493a7fd1852mr32215115e9.9.1782666126285; Sun, 28 Jun 2026 10:02:06 -0700 (PDT) Received: from foxbook (bgu190.neoplus.adsl.tpnet.pl. [83.28.84.190]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4926c2954efsm160059395e9.2.2026.06.28.10.02.05 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 28 Jun 2026 10:02:05 -0700 (PDT) Date: Sun, 28 Jun 2026 19:02:01 +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: <20260628190201.00afdccf.michal.pecio@gmail.com> In-Reply-To: <62e1fab3-1045-41f3-bc74-4c7624011619@rowland.harvard.edu> References: <20260623161035.5792-1-nikhilsolanke5@gmail.com> <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> 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 11:48:36 -0400, Alan Stern wrote: > > How about "keep unrelated changes out of a stable patch", i.e. always > > do the delay (if any) after the first request, regardless of size? > > This is not an unrelated change. Rather, it's deciding on how to behave > in an entirely new control pathway -- the one where the 255-byte quirk > flag is set. The old pathway is completely unaffected. > > I suspect no devices will have both this quirk flag and the DELAY_INIT > flag set, which means the location of any delays in the new pathway > won't matter at all since they will never be used. If no devices will have both quirks then new delay added before the first configuration request will never execute. 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. Either way, no known need exists to add another delay before the first request or alter the existing delay (or its conditions) in any way. In general, I always object to code which serves no purpose because such code is easy to add but very hard to remove when it gets in the way. There are no known users, no test cases, only paranoia. So I would keep the delay code completely unchaged. And skip other random changes like error string nitpicking. Reliable and up to date information about how many bytes are requested, "expected" (what does it even mean, to somebody reading dmesg?), received or verified to exist can be gained from source and usbmon. A stable patch is supposedly supposed to be 100 lines with context ;) Regards, Michal