On 9/28/26 1:03 AM, Christian Berry via B4 Relay wrote: > From: Christian Berry <[email protected]> > > nvme_wait_ready() polls the controller status every 100ms, although > the controller may become ready much sooner. Every probe then waits > at least 100ms longer than needed, and possibly twice, since both > nvme_disable_ctrl() and nvme_enable_ctrl() wait for readiness. > > Poll every millisecond instead, as Linux does since commit > 3e98c2443f5c ("nvme: Check for readiness more quickly, to speed up > boot time"). The overall timeout is still based on elapsed time, so > it is unaffected. > > Tested on an Arm64 SoC with a Samsung 980 SSD in a Gen3 x4 > configuration, where PCIe + NVMe probe time dropped from 165 ms to > 65 ms. > > Signed-off-by: Christian Berry <[email protected]>
Reviewed-by: Ahmad Fatoum <[email protected]> > --- > drivers/nvme/host/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c > index 345707ecfe..9686268d44 100644 > --- a/drivers/nvme/host/core.c > +++ b/drivers/nvme/host/core.c > @@ -173,7 +173,7 @@ static int nvme_wait_ready(struct nvme_ctrl *ctrl, u64 > cap, bool enabled) > if ((csts & NVME_CSTS_RDY) == bit) > break; > > - mdelay(100); > + udelay(1000); Nitpick: I'd prefer mdelay(1); but you don't need to resend just for this. Cheers, Ahmad > > if (is_timeout(start, timeout)) { > dev_err(ctrl->dev, > > --- > base-commit: 983608b439b803f72f12d56d0ab10bd6ba29e536 > change-id: 20260927-nvme-ready-poll-4bd640377bab > > Best regards, -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
