From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 5598F35292A for ; Sun, 28 Jun 2026 14:50:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782658248; cv=none; b=oscyQ3acw/dCWtTMDYqYcnAiG5cmrnj4zrOZSMirqymHSuC9NW/zEBsufmRbe8meHc/WTzqDl5TgP3W+9jO61h3UTi03mSF2yXJ+Ij5lrCisgGdiPxqNB829TvQ3kvT6WnBZP/xVBPaiax+Fj/kdby2snnBe1XMjHmBrRJPC8zU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782658248; c=relaxed/simple; bh=4sy1Y4WR9ugVm1F65RWh7OvYWb4yYk3Tn9QjzRV+Rq0=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cbVCOi2g2pBbZRP/VXCnH5grLgA1I0YP4hAL/DsmqfOJZLdm7AaCEw4NvRcpPXvUzK6Z/uRcq6tmMbhgJ/BX5yKbsoFjtWO7kG+ECzl+9Ek3JF4Sgip2bvZipI2WRGGaiyg3k+XAf74FzMs3hmiGHeuq3Y5+0uAWY8pvb75vfPM= 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=dXqjuEyi; arc=none smtp.client-ip=209.85.128.49 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="dXqjuEyi" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-493a54b80a5so10104335e9.2 for ; Sun, 28 Jun 2026 07:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782658246; x=1783263046; 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=DIbIf43pbwX/hQV/fKrmKMDT2zLMO167rrGvyP3bRww=; b=dXqjuEyidrp8mZ7tBLHJkteW8ltO3ZFVT6Z64dVPHZAewV+vI2mrFfevHD/nNjwJK7 qzvOMwGg172+ZjbOWMJmObKTr5zj4ku3DecV0wl+4jXzqakEqB4HfAuiKv9hy3+a0dvl 3Wjehu1VSLFFtkR5P3405ewO9UY67z/Qm8wfsIlS1w0QxdeO05z659n2b+A+MEvGhzvd rJy/wMxcZjUzZWADTbjaRfJ/tVTT/AiQ4vo7k12RnSaKDyBcRAkEdLzd6UJQ7wcMz4cD RJpKEu3KK17Tia8rkPLv2PpZ1D8HvpSZotAPk6ok5+fP2RziW1+/ektnkFK6ga5xE56C s5Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782658246; x=1783263046; 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=DIbIf43pbwX/hQV/fKrmKMDT2zLMO167rrGvyP3bRww=; b=nR8aDI8YLXcyeDvIEfyAlcNN8sOnq6OhTLhLnjijFw9h+wijna0x/9ypUCxFvANBCy 939gKw3l710H7TBQbM3QTYTY8orosznTkvIp19FMFEgZPw6QJ4Hed9ryRCcxPFalQsvw JpU2o5QxKxhNSfM2Ds8hx1E+ZxdClvEB0o4Xs4R560jJjnUeLmwamYqohvmBDvNf18CP 8tbgi2W3Yb/QoSUNet56IewE1FNf0Tkqsn/IPsqKo9KUmsEcPPkAV0kMaB6UteTjz6u0 CW5mNYKjq4gRC3zNLoyU8VzoZyM0ivaCD5Xrhtc85ydz51F6ZvBnSJZPZ6GiM84kbqJD 4VgA== X-Forwarded-Encrypted: i=1; AFNElJ/L456BeDONwTUEaixd8rVR9NJZlvsYAAAo7XKx5H7CYoFtk7jVU2p5qSWEBETNxMqGSPH+EWET2pLYX8g=@vger.kernel.org X-Gm-Message-State: AOJu0Yw2HvgeRcBLfEkxZ6n2lVrFaHDknaWXXwsTa7AO65Bc54x7MuRo CpuCLimPvxjEHktLyrpoO5LSl2uslZLH9ZYNlnvYlo72p72LRICeiyFg X-Gm-Gg: AfdE7cndPhFBaHH0Q+ijNQa0rMho9O+JG/KU8Ubn3Y98Y2mxlRxwC15nGq8VoXUI9f1 KSPt30dPHbmEvk/BcQJNPY9ymi4Lrsy7417+DLfr4NIDp6n6gzGofjZrUgqo4JXeGa7exjHefDi 57cXXK3LumkpefIp24CUW7wqTR2+4w4wk//JmztvO07c2I4IEzORhhEx58vyULV1KQ1AZA0ADyS wzFTKUHEt7wYWAUaD3va1eAY4r/ZY+b0ZGrN9zcyxYC2yDYWIdk2zYKGVA0EzeUMA6CtadPLw2f bbXaTTJ1tAHnAHDmWxcPaMnQRyFoDtBENSyKqibhw8GO3WWjFCQ+Tt2Rk9dbnmtN/a6hVp57exz wDl6rO1/yHxk/KkUzqBnf5tBQP6d7GSploNX81gBOn586ckvkTIZ+zikICiKMrQjkZGUBLiDYmM aPVg01cdCW8JkHHc9cBKTDJx+2 X-Received: by 2002:a05:600c:c4aa:b0:492:3445:ecf8 with SMTP id 5b1f17b1804b1-4926685fe2dmr206794015e9.3.1782658245742; Sun, 28 Jun 2026 07:50:45 -0700 (PDT) Received: from foxbook (bgu190.neoplus.adsl.tpnet.pl. [83.28.84.190]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4926c00a34esm136115845e9.0.2026.06.28.07.50.43 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Sun, 28 Jun 2026 07:50:45 -0700 (PDT) Date: Sun, 28 Jun 2026 16:50:40 +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: <20260628165040.76fd608d.michal.pecio@gmail.com> In-Reply-To: <02060df3-b8c5-4a86-b3ab-3a28eea8a562@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> 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=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 28 Jun 2026 09:55:07 -0400, Alan Stern wrote: > On Sun, Jun 28, 2026 at 11:53:09AM +0530, Nikhil Solanke wrote: > > I need some help with the USB_QUIRK_DELAY_INIT part. I can't figure > > out how to make it properly work with my patch because of the > > following reasons: > >=20 > > 1. I don't want to move it to the top because, from my pov, there > > must have been some reason for placing that quirk where it is now. > > so i don't want to mess with it. git blame is your friend: The DELAY_INIT quirk only reduces the frequency of enumeration failures with the Logitech HD Pro C920 and C930e webcams, but does not quite eliminate them. We have found that adding a delay of 100ms between the first and second Get Configuration request makes the device enumerate perfectly reliable even after several weeks of extensive testing. The reasons for that are anyone's guess, > >=20 > > 2. Regarding my idea of adding a condition =E2=80=94 so that it doesn't > > change the behavior when the quirk isn't set =E2=80=94 if the full > > configuration set exceeds 255 bytes, we would have to issue a 2nd > > request. In this case the existing behavior would be more justified. > >=20 > > So, I'm a bit confused about how to implement this properly. Adding > > yet another condition to fix the second case doesn't feel right to > > me. It would look unnecessarily complicated. I would appreciate a > > bit of help and advice. =20 >=20 > If the 255-byte quirk flag isn't set, do the delay before the second=20 > transfer just as it is now. >=20 > If the 255-byte quirk flag is set, do the delay before the first=20 > transfer. If a second transfer is needed, you can do a second delay=20 > before it or not -- I suspect it doesn't matter. If you want to be=20 > safe, add the second delay. 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? Regards, Michal