Received-SPF: pass (google.com: domain of linux-kernel+bounces-123830-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
From: Norihiko Hama <norihiko.hama@alpsalpine.com>
To: Alan Stern <stern@rowland.harvard.edu>, Matthew Dharm
	<mdharm-usb@one-eyed-alien.net>
CC: Greg KH <gregkh@linuxfoundation.org>, "linux-usb@vger.kernel.org"
	<linux-usb@vger.kernel.org>, "usb-storage@lists.one-eyed-alien.net"
	<usb-storage@lists.one-eyed-alien.net>, "linux-kernel@vger.kernel.org"
	<linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] usb-storage: Optimize scan delay more precisely
Thread-Topic: [PATCH] usb-storage: Optimize scan delay more precisely
Thread-Index: AQHagSuLspWlvFs4ZkGDPqS33FWwALFNzt0g
Date: Thu, 28 Mar 2024 23:38:37 +0000
Message-ID:
 <TYVPR01MB107818669DF1EB88BA7D9D2A7903B2@TYVPR01MB10781.jpnprd01.prod.outlook.com>
References: <20240327055130.43206-1-Norihiko.Hama@alpsalpine.com>
 <2024032757-surcharge-grime-d3dd@gregkh>
 <TYVPR01MB107814D7A583CB986884AD4B290342@TYVPR01MB10781.jpnprd01.prod.outlook.com>
 <a446cdf4-3a9b-43d8-b22b-78c20cce2b4f@rowland.harvard.edu>
 <TYVPR01MB10781AA8B37E147E318597B46903B2@TYVPR01MB10781.jpnprd01.prod.outlook.com>
 <0c99daaf-c727-467f-b8c1-ba8846d8a9ab@rowland.harvard.edu>
 <CAA6KcBBcpug-rOytgnbb=c4O54m-Pfy=divqp12qOMrgmQrz7w@mail.gmail.com>
 <2483fb37-8939-4723-ae8d-7a7a7dba3322@rowland.harvard.edu>
In-Reply-To: <2483fb37-8939-4723-ae8d-7a7a7dba3322@rowland.harvard.edu>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
 =?utf-7?B?bVIwa2tvd01zcG04OTZoNVBHSFcxZmRHQlFtYUhORGliYUM4NkJMS25waWNK?=
 =?utf-7?B?ZTNIdW1OQWxZYXZIMUVDZHR0ZElhNG9iQUhvM1ZtOVlzVzV2bjl6NTJvQ3pE?=
 =?utf-7?B?VmFINXAxRzlvZ0daWS9heGpCOG1SaUtoODJNWEtzdDFlanl1SDhmcU5JbDQz?=
 =?utf-7?B?OFBrWDI1UXpkL3h3UUhSRkV3VVVqWG83enozbWZRMjhLQXU3bmZ5d090VEh0?=
 =?utf-7?B?TzNRYmtPYTBMaGZlY1Q2MFpZWmFGU2pMZ2lQbnE5UnBSUENiT3JIQzRtTVVX?=
 =?utf-7?B?a2tKdDd1azQ3bDBQWU5obkR4ZC9sckpZbFdIejNGblZzUTQwem9LMTZaNVAz?=
 =?utf-7?B?UklzMDJzMUVWNHN0MGN3bzRJeFNvUWFURHg5SGhwUlIrLWYzNUpwTTUvZTVM?=
 =?utf-7?B?WkRoVGtXU1VkOHo1dGd1Z2YxbGNFWVprbzVjNDBTaHlOTjljdTVxVE52M3Vt?=
 =?utf-7?B?NWFyYnJIbUhYSVhKd056ajNoRjZhY2M4S29nMk1BUCstTkZQZW5kcUxWMHJP?=
 =?utf-7?B?dzFIMnl0UWxaUEI4YzhCTDRsR2VQbTJlM2ZRVlJGZFNWRm9CZXpNUkk1RHM1?=
 =?utf-7?B?d3NJYXZwNkRaUm03azV0QXRXMUxNcDVUeGpSWDg0Y1ZmU0YrLS85RmJ4V1Ex?=
 =?utf-7?B?WFB2VDVlalI1S3p3U2dhZ1FGSEJPdnN4Vlh5S1ZjaU1BM3B3aWFreEVXMkJa?=
 =?utf-7?B?SDIzM3pkcld4M0NMVnkzTEtwM0thbFkxZjQyMmh5cm40ZVB3N1RvdmU1bmRQ?=
 =?utf-7?B?Z09QN2d5MkRKbXdPWExBR2VLaThFSi9DMTJnbGxSMW9JSjZpY2FyeEtkbjNz?=
 =?utf-7?B?WnhqblE1ZmdPdVBUYy9EdzA1TjRCZlQvTDFtMUhhQ29KRE1IMC9md2FxaTdS?=
 =?utf-7?B?Ky1haGhtY00zL3hXQ05kMFEvMXZGc2FiVFdjM1FxSThSdjFiNExlYzYzM1RJ?=
 =?utf-7?B?MzVqWktMNDZoVVRnSUdKYWlZU0xLY1cyWExoMGhVRVhtRWZ3bk5TMGRGTUdh?=
 =?utf-7?B?QmR5ZFBRYUZrNGROTnZNVFJsWUR5UUZjVUdYKy1INHNDZ3hWVUJ1OXg2R0pR?=
 =?utf-7?B?cXFoKy1CT1E0S3UrLUtBNE94aDgrLXZET04zVzdtN2M3cFJJOFpMcnkyNllW?=
 =?utf-7?B?bDByTUQxNlBnZ2ZFVUJpZU9hYWFPeDhLNTc2V243RzZkWWNrVzl4T2FtRHRt?=
 =?utf-7?B?R2F0MnllUUtvaG9xcnhmb2hwdElTRmdQeXZNNUIySUs0bnFWSHdDeWx5L0Ey?=
 =?utf-7?B?YystR01aY09YL0RoTU1xUCsteGNPSWdURHJhUS9mbDEzSENFOHhhbDNmR2NY?=
 =?utf-7?B?YTZWaHFPcTNwTTArLUJDWXNlVHJTZUhMS2traW93ZHI2dWd3dVBjdlk3Ymdz?=
 =?utf-7?B?b01YUjM4V3oweG1zNm4wTmRHTVlVM1NuMjZoWTRtMHR4NlZVT0dBSWZmcm9i?=
 =?utf-7?B?clNkKy1MMnIvT3A3b1VBWTdHRVBDQjM0amsvNDJFcDd0M0NMZnp2UnN5ZFFk?=
 =?utf-7?B?Sm9HV3lWWWIwcDk5ODZLb25YTm5COERrUWFYanJxc2hiY0o4dWtiTDE4aTZN?=
 =?utf-7?B?d2ttYkwySzcvNWZCUGZTcmljZ0JkMDJtSW0wQTluU2NFUHVmSmJaNVc2Ukg2?=
 =?utf-7?B?RlJvOEJWVmZ5WUpOVi9lOFVGTmo3YVJ1ZHV4WnUrLXRKVVRab3lOMll6TlJz?=
 =?utf-7?B?ZnR4RDdXbW5iNnhJMkw1RFNNenZLOUpESTE1U3FHMnIrLVpSem9QRHdvTkJ1?=
 =?utf-7?B?ZlZiT1RsU1kxaDU0M1gvRkRscE9Jc3RnWmNoc0hta0s2NlYzMGpiUmw1czZq?=
 =?utf-7?B?YndLbld6WW05UUFZRUhHRjJKVFpINXdVRThKWXcrLWIrLU84VXN6aVdYbzY3?=
 =?utf-7?B?SFp3VkJuSktUVUkrLTR4enFFNUxuTEcxKy1aUGpZWWN2NlIrLXI1b3BDNDNp?=
 =?utf-7?B?akdRQ2FFYS96NVJ6MXBaMHVIcUxLTGtZNlVYTXMvWkhrVXF2Ky00UWY4Zkk4?=
 =?utf-7?B?dW42R1dESWFkTG0rLURJMGI2ZzN1NjhEbzBva1BNajJNWGJiNkx1NDZLNS9y?=
 =?utf-7?B?ZlV1cW5hRk10ZHBQRlFIODU5UHBFM044NDg4VlQvSlRubkNRNHhLL25yRnRr?=
 =?utf-7?B?WDFkNEFBMnk4WURnbk9FT3ZpT1ZzamJjcmh3S3B6RWk2RFVFWjI5YThKeWp6?=
 =?utf-7?B?cA==?=
Content-Type: text/plain; charset="utf-7"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
X-OriginatorOrg: alpsalpine.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: TYVPR01MB10781.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 54c3fa4e-a693-4679-cb2a-08dc4f803122
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2024 23:38:37.8001
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 57e76998-77bd-4b82-a424-198f46eb2254
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3tF5w5cGrUl3/973/hizyfxPEdkUs1KO7ytUxFhVjzu+JzwiZlwj/RJX/HJrfSx2edEBNbr5phbdzKUHcah7tw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS0PR01MB5761

+AD4- +AD4- +AD4- Here's an approach that Greg might accept.
+AD4- +AD4- +AD4-
+AD4- +AD4- +AD4- Since we already have a delay+AF8-use module parameter, w=
e could add a=20
+AD4- +AD4- +AD4- delay+AF8-use+AF8-ms parameter.  The two module parameter=
s would display the=20
+AD4- +AD4- +AD4- same value, but delay+AF8-use+AF8-ms would be in millisec=
onds instead of in=20
+AD4- +AD4- +AD4- seconds.  (This is similar to what we did for the autosus=
pend and=20
+AD4- +AD4- +AD4- autosuspend+AF8-delay+AF8-ms sysfs attributes.)
+AD4- +AD4-=20
+AD4- +AD4- What about just changing the parser on the currently delay+AF8-=
use=20
+AD4- +AD4- parameter to accept an optional suffix?  If it's just digits, i=
t is in=20
+AD4- +AD4- seconds.  If it ends in +ACI-ms+ACI-, then interpret it as mill=
iseconds.  This=20
+AD4- +AD4- would be backwards compatible with existing uses, give you the=
=20
+AD4- +AD4- flexibility you want, avoid adding another modules parameter, a=
nd=20
+AD4- +AD4- potentially be expandable in the future (if, for some reason, s=
omeone=20
+AD4- +AD4- wanted microseconds or kiloseconds).
+AD4-
+AD4- A little unconventional, I think (at least, I don't know offhand of a=
ny other module parameters or sysfs attributes that work this way), but it =
would work.
+AD4-
+AD4- Noriko, would you like to write a patch to do this?

Thank you for your advice.
I understand and will try to do that.

Best regards,
Norihiko Hama