Re: [PATCH] nvme: make firmware activation poll interval configurable

[guzebing <guzebing1612@gmail.com>]

On 7/9/26 11:07 PM, Keith Busch wrote:
> On Thu, Jul 09, 2026 at 05:06:11PM +0800, guzebing wrote:
>> The Samsung PM9D3a Gen5 SSD reports MTFA = 10, i.e. 1000 ms.
>>
>> I also checked another device, an Intel/Solidigm P5520 Gen4 drive.  It
>> reports MTFA = 100, i.e. 10000 ms, while the observed online activation
>> time is about 800 ms.
>>
>> I agree that deriving the polling interval from MTFA would be better
>> than adding a module parameter.  Given that MTFA is a conservative upper
>> bound rather than a good estimate of the common activation time, would
>> using a small fraction of it, for example MTFA / 100 clamped to 10..100
>> ms, be a reasonable policy for v2?
>>
>> That would give 10 ms for the PM9D3a device above, while keeping the
>> current 100 ms interval for the P5520 case and for large-MTFA devices.
> 
> nvme_wait_ready() has a similar polling loop on the csts register, but
> it does a udelay_range for 1-2 msecs no matter what the ready timeout
> is. Maybe just do the same for consistency?

Keith, using the same 1-2 ms sleep range as nvme_wait_ready() looks
simpler to me as well.

I measured two long-running nvme_wait_ready() calls in the normal
nvme-pci NVMe controller-reset path for a live Intel P5520
(SSDPF2KX076T1), not the PCIe FLR fallback:

  nvme_disable_ctrl() cleared NVME_CC_ENABLE in ctrl->ctrl_config,
  wrote the cached value to CC, and then waited for CSTS.RDY == 0:
  1353 ms

  nvme_enable_ctrl() set NVME_CC_ENABLE in ctrl->ctrl_config, wrote
  the cached value to CC, and then waited for CSTS.RDY == 1: 1070 ms

Both long-running waits used an effective timeout argument of 30
seconds. The same drive reports MTFA = 100 (10 seconds), while its
observed online firmware activation time was about 800 ms. Thus, on
this device, the ready waits already use the 1-2 ms sleep range for
longer than the observed firmware activation.

Thanks both for the suggestions. Christoph, would this approach work
for you as well? If so, I can respin v2 to drop the module parameter
and replace msleep(100) with usleep_range(1000, 2000) in
nvme_fw_act_work().