From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18])
	(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 773C03FF1D8
	for <linux-kernel@vger.kernel.org>; Tue, 11 Aug 2026 16:46:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1786466786; cv=none; b=cvKVs/c44MgiTU3onEv9AiUIpqeTq/QkocO7j5/voOkr/+3s9IW5DEQaC7BTigye4WduJXJrBzBLWu0E3D+Od4TgyY200Cnisv7QsGeRbcu2GT1j7SPaSNXuFLtnGJXldRKY/PUCiDhXuzhEwO7uUG234I3DAr3pomKdl63NESk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1786466786; c=relaxed/simple;
	bh=U4gyz6A06Ae4p254KxTnKJt5v77f+pRuokFLN9CpweI=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=hyczyCkr6YfssRa/1CTha+Ok7Euq/N+Oa19SMo96Ix3F9yQeAweiGcxIEqpZ+9cyuk/I+r+xRNFnFNlBd3me7V6u4/hN+Pa/xsxZGIZJ0Nchse4DiW1mBxprZqBUBmZZE64BIDyx89MArysu8TgSvUTpysfI/qcTtaRRvFHRqtc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S5Q6o6c+; arc=none smtp.client-ip=100.103.45.18
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S5Q6o6c+"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 195BA1F00A3A;
	Tue, 11 Aug 2026 16:46:20 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1786466780;
	bh=LS4JIlqraDcriC4bxlNxrEyn/0oBkj9oHbOV9Olu/ho=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=S5Q6o6c+wz8vPAI8l7cwZFk2KzNNC7Uf0clYL2uSTvHSiAP6qsjlIpPhSrnOby9RS
	 cmXSy840lJWb7uUpWEsGDgFl42KqweDF1QVQhNbL0fV27XpVoa7j4otNU+SfxSgLnM
	 ZIBTqpH0gx6yXYPe0tUal335Duv/e6zPEw7m01HX6dIajPS1uUoXJUx3PLcKiujwlV
	 hzLDL765c9Ga6btaIqbCtxUrGcwSlnFPYeVTa368ILK9P7B6fiX7lBKheFHkhvTxNc
	 4AgJB27Z5WxrJZ/79q1IbOKW4NIs2KvULdOsYzaMlQ5xeOINzSd5Dh4VJBvSjzOA73
	 oe2dJL7Ng0asQ==
Date: Tue, 11 Aug 2026 10:46:18 -0600
From: Keith Busch <kbusch@kernel.org>
To: guzebing <guzebing1612@gmail.com>
Cc: axboe@kernel.dk, hch@lst.de, sagi@grimberg.me,
	linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
	Guzebing <guzebing@bytedance.com>
Subject: Re: [PATCH v4] nvme: reduce firmware activation poll interval
Message-ID: <antR2u1eeBDCr0ux@kbusch-mbp>
References: <20260728121735.1627370-1-guzebing1612@gmail.com>
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
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20260728121735.1627370-1-guzebing1612@gmail.com>

On Tue, Jul 28, 2026 at 08:17:35PM +0800, guzebing wrote:
> +static int nvme_wait_ready(struct nvme_ctrl *ctrl, u32 mask, u32 val,
> +			   u32 timeout, const char *op)
> +{
> +	unsigned long timeout_jiffies = jiffies + timeout * HZ;
> +	u32 csts;
> +	int ret;
> +
> +	ret = nvme_wait_csts(ctrl, mask, val, timeout_jiffies, false, &csts);
> +	if (ret != -ETIMEDOUT)
> +		return ret;
> +
> +	dev_err(ctrl->device,
> +		"Device not ready; aborting %s, CSTS=0x%x\n", op, csts);
> +	return -ENODEV;

Actually, I'm to back this out for a moment to think about this. I like
that you've changed the error to ETIMEDOUT for that condition, but I'm
not sure we need to convert it to ENODEV. None of the callers seem to
care about the specific error, and the user visible side effect of the
condition is more informative than ENODEV.

So if we can get rid of that legacy behavior, then this simplifies even
more. Thoughts?