From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2E8682E84F; Wed, 27 Mar 2024 07:44:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711525493; cv=none; b=j8RxJZheyB0+8mnaQ2/hcHIaTv4wyTd98GEJsIGi0X1AM2kzDumSZm6P4D7GDIIOFc6O4fwdcRkB0KgUSsRh5cKaqfZiFz2JL7AmjMRAaOcbkZTaC6ddjf6W+7YePVTQvMaiqrflMoCk/gl9+EYy+pz5cNNC7Mpy8naad/ibRAs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711525493; c=relaxed/simple; bh=Vo4tpCBhH8KPWILqOFDHjrb/brtS1Awao540EB/KPuc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=csuwJwZRFNTtPxp8ZNN1o7g1KElVy+LwEWdSo1YkU56rnY+UQEXq7Uo2Qk5+YqsUEYFund9R2L8ksEkqzyH8kkxH42knb2yFs1bHFL3Md7+POGZZMEXy3B4tS/S7+uRUzOjH7c8ng0qRazUyLPfUuJtP1BEW2r7MSerTDOm15gI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=CIv7bUYu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="CIv7bUYu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39F61C433F1; Wed, 27 Mar 2024 07:44:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1711525492; bh=Vo4tpCBhH8KPWILqOFDHjrb/brtS1Awao540EB/KPuc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CIv7bUYuMv9e1s3cMH9nfYHCAYTvSpkFc9yT8AtQgxaRr1c3NzUjWn/t7SrqhP5bZ LtKGtCJccNCaO6Rqqqa6T1FXB/zyPTFk1Q/XMC8uNNqzhwcdpY9AFMUJqyYyBNNJNW dhruLWIm6Albrld8kCIJy3il66qOYPjTA0bvsfdI= Date: Wed, 27 Mar 2024 08:44:49 +0100 From: Greg KH To: Norihiko Hama Cc: "stern@rowland.harvard.edu" , "linux-usb@vger.kernel.org" , "usb-storage@lists.one-eyed-alien.net" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] usb-storage: Optimize scan delay more precisely Message-ID: <2024032745-transfer-dazzler-2e15@gregkh> References: <20240327055130.43206-1-Norihiko.Hama@alpsalpine.com> <2024032757-surcharge-grime-d3dd@gregkh> 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, Mar 27, 2024 at 07:39:55AM +0000, Norihiko Hama wrote: > > Sorry, but module parameters are from the 1990's, we will not go back to that if at all possible as it's not easy to maintain and will not work properly for multiple devices. > > > > I can understand wanting something between 1 and 0 seconds, but adding yet-another-option isn't probably the best way, sorry. > 1 second does not meet with performance requirement. Who is requiring such a performance requirement? The USB specification? Or something else? > I have no good idea except module parameter so that we can maintain backward compatibility but be configurable out of module. > Do you have any other better solution? How long do you exactly need to wait? Why not figure out how long the device takes and if it fails, slowly back off until the full time delay happens and then you can abort? thanks, greg k-h