From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) (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 3276A228CB0 for ; Wed, 24 Jun 2026 14:01:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782309673; cv=none; b=e5HIN1e6vfDkxopjj3vGBU1gP1QV4EkjDOq0YU8PEKxdk2tVvaxzE9JMLDJ4iquFHXSeimvlpV3fB5sKBqATgZfgaL8MYwzljxGaPkSR3kbxL8atAmOv56tI3Q+E/kfDDtZ+P+p7JvUYd5kCGDdqNr5qBOmDP+wXLQO5NEWqP38= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782309673; c=relaxed/simple; bh=sqz/nCl4XMoZ5TKKVVNz5tAI/LScRoJeM9WbyPmJx3E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aBWX/PWsN5XK3JqiTh5ZIbWeBRhjES7ciRiD82fHCWV7QbD9+nGT8XFFErGJ2qlWxcor8fc3o1L3HliZoZU7dTj82QLnfvh+Uq2aFl2q8mJ23h8ZBXMyK7ECS+t+tXGcKGTh3B6V0Zz3eAP9+WLpSkNHYItEuVgf6yJDMSPSd2s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu; spf=fail smtp.mailfrom=g.harvard.edu; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b=KstfDJkD; arc=none smtp.client-ip=209.85.222.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=g.harvard.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b="KstfDJkD" Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-915b5ce94c7so93378185a.2 for ; Wed, 24 Jun 2026 07:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1782309671; x=1782914471; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=wsEoW4DBoKT0fUYLZPdL7MZJTkz7+GAlNaoQ4msQnkg=; b=KstfDJkDlEZuT1HYy2wLN0zzVO7os9Mav9CMPrsd7Kv98rDcLUS7Wg5ukVEMLr3LVG wrMAP69DjNNNzDVB2ZNOfiTOc1hFWk6LOgZdLKLlC+joHQiuqFZ40e7hNzcPh9oWhGY/ 2G/O2HjDTmBS9oRGG1S37xQaTYUM3wBJHlcPNdyjlvsE1IDgBr7ovk0ZlAyLMvD5K4F2 s+LsOd3mFqtYmxhVb2PFHtvW7RF7jgiJBAVwWIQuzP65aYXobwjDznATwWFVkYABsJXZ LVH9wW2TsSZf+p2SWTS7/3e2nLXqldUfpW6QUJzVbbrD9x+kGVzbxfNNIV+4CBNNqAON puzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782309671; x=1782914471; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wsEoW4DBoKT0fUYLZPdL7MZJTkz7+GAlNaoQ4msQnkg=; b=IJ4Hq/0N2ZXJ03b1nyUn0OGKQlVG6YACBf+x4TSkaTfjEh3h8bLhxRvzSSx1ywXMyx E3szdr4kl6jJo/3bsoj3S0zwi8WshizgaVuaaQyVnfB7aXTY7yiSUDtgkI2RqCcsB9HL tVyP8zR3KC+Az414LKckZ8Fo2w0jHvmjSL14rhi7kK68AwfX7opZS7L3OBdntDVh5yLF 0rXchumGWBtQif25Q9LqJROD3Tq96gS4Kx7GgQEapL/dfn8u64J/XUO1uPdLWR4vwQ86 kepTX8E27aovSAmJp1tq2UsSiV28npbpPbUkWnvim/7uKteA9/yyf5ETPirGUUmcD/iK sv4g== X-Forwarded-Encrypted: i=1; AFNElJ9hxl+DjfEDBrxK5pCEg8n/UU+u7cLCz0SRUsn2zXp9sDCf0YbGlGkLCLA5+k2GrQFt5pZoQSP/KF+ge6w=@vger.kernel.org X-Gm-Message-State: AOJu0YxJ1RhS6+5H9s2M4hi8q54b4Ffi8fq1BnWM1c+WYkdBOZy9sB+4 imX9K9uv7rC0O8U9a3t4uS1oay0PgrpllKyBTEO1GuFkJyZz8TjN3Y5/vYlIRVYwug== X-Gm-Gg: AfdE7ckQeii5WaWnmOBlIOfsPrf58ABeEQk4atKKd2OjhQWxUxubFTQ1+hlFqm6DBRl cOUgbg+tRcaNfygO5GpR71fuIAC3dUYlzBmGF6G8hkFbud5Cd3602fmyokSbXAsfsKegrBcLBLj Bm98/7ziF5qkOozxHpLTm2QJFMjVFBvmG2t1EdTQH0++AiVfs8RmVwIhKMVcYDlofg67oxG5ee0 26GVqsDtS8G9a/KCF5HWKo92ghK7j3Z0pa4SQZjOj1jy9+gebDIfmSD2L4FT0/y5Mx81+DsD99K XClmgNKaBD0FdlR0lgNc1dHc2NNCUXENDckxA7JRwT7ywt3F8Wz+L0nMJqIAJN7lnqEwCFzG/l3 5TsQVmYEcaJ85MfjcIMgQYfyz+VCzfD7l1RlM1212QT/xGJGHZcgt37z+TlQ2atzBe0D/waOjSQ KrxSSKpClJA7ELCeTzwKanosnlC4Cftyi+ X-Received: by 2002:a05:620a:1a09:b0:915:cb5c:7f70 with SMTP id af79cd13be357-927800a2787mr561454085a.29.1782309641938; Wed, 24 Jun 2026 07:00:41 -0700 (PDT) Received: from rowland.harvard.edu ([2601:19b:d01:d210:d62f:1911:f952:16ba]) by smtp.gmail.com with ESMTPSA id af79cd13be357-92600c7bf55sm552191785a.46.2026.06.24.07.00.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2026 07:00:41 -0700 (PDT) Date: Wed, 24 Jun 2026 10:00:38 -0400 From: Alan Stern To: Nikhil Solanke Cc: linux-usb@vger.kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, michal.pecio@gmail.com, 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: References: <20260623161035.5792-1-nikhilsolanke5@gmail.com> <567e8866-4308-4e5f-819c-fe778dbf74f8@rowland.harvard.edu> <5159fd69-dddf-4073-a8e7-95fa77de0b7f@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-Disposition: inline In-Reply-To: On Wed, Jun 24, 2026 at 01:36:28PM +0530, Nikhil Solanke wrote: > > Actually, the best approach here would be to put this single change into > > a separate patch that comes before the current one. That removes issues > > of making more than one functional change in one patch and improves > > bisectability. > > Before? Shouldn't it be after my changes? That would make it easier to > justify the changes. And just to be sure, you did mention it does > align with what the intention of USB_QUIRK_DELAY_INIT, but it does > change its behavior when the quirk is not set. Atleast from what I > understood from the documentation and an LLM's summary, the device > needs time to prepare the full configuration set. So, does delaying > before the first header read really work? I can't test this since I > don't have a device that requires the quirk to be set. > > I personally think adding a condition to check if the quirk is set and > then delaying before sending the first request would be appropriate. > What are your opinions on this. Well, put it this way: If you change the existing behavior, that change belongs in a separate patch. If you want to redo this patch so that it doesn't change anything when the quirk flag isn't set, that's fine. > Also is it fine if the string lines exceed 100 columns? In lines containing long strings, it's okay for the string to extend well beyond 80 columns. But then you should break the line at some point closely following the end of the string. I'm sure you can find examples of this if you look through some of the other source files. > Also, is there a need to check for krealloc()'s return value? Since we > are only shrinking the buffer, there won't be any moves or completely > new blocks (at least as per my understanding). Do I still need to > check its return value for completeness' sake? It's a little tricky to track this down, but if you look in include/linux/slab.h you'll see that krealloc() is defined as krealloc_node(), which is defined as krealloc_node_align(), which is defined as krealloc_node_align_noprof(), which is declared with __must_check. So yes, you need to check the return value from krealloc(). Of course, you could simply try not checking the return value and seeing if that provokes a warning or error from the compiler. Alan Stern