From: Daniel Wagner <dwagner@suse.de>
To: linux-nvme@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, Daniel Wagner <dwagner@suse.de>
Subject: [RFC] nvme: Do not reject dynamic controller cntlid
Date: Thu, 27 Jan 2022 14:36:48 +0100 [thread overview]
Message-ID: <20220127133648.8201-1-dwagner@suse.de> (raw)
The NVME spec states in 3.1.1 Controller Model there are two types
controllers: dynamic and static.
The nvme_validate_cntlid() check ensures that the newly discovered
controller does not have the same cntlid as a known controller. For
the dynamic controller model this check doesn't make sense as all
cntlid will be 0xffff. In this case ignore this check.
Signed-off-by: Daniel Wagner <dwagner@suse.de>
---
I got a bug report with this:
nvme nvme10: pci function 0000:00:19.0
nvme 0000:00:19.0: enabling device (0000 -> 0002)
nvme nvme10: Duplicate cntlid 65535 with nvme7, rejecting
nvme nvme10: Removing after probe failure status: -22
From reading the spec I got the impression that it should be enough to
ignore the cntlid check if the cntlid is 0xffff. Though I might be
completely wrong here.
drivers/nvme/host/core.c | 2 +-
drivers/nvme/host/nvme.h | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index dd18861f77c0..918abb54771c 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2701,7 +2701,7 @@ static bool nvme_validate_cntlid(struct nvme_subsystem *subsys,
if (nvme_state_terminal(tmp))
continue;
- if (tmp->cntlid == ctrl->cntlid) {
+ if (!nvme_ctrl_dynamic(tmp) && tmp->cntlid == ctrl->cntlid) {
dev_err(ctrl->device,
"Duplicate cntlid %u with %s, subsys %s, rejecting\n",
ctrl->cntlid, dev_name(tmp->device),
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index a162f6c6da6e..ed75245263f5 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -539,6 +539,11 @@ static inline struct request *nvme_cid_to_rq(struct blk_mq_tags *tags,
return blk_mq_tag_to_rq(tags, nvme_tag_from_cid(command_id));
}
+static inline bool nvme_ctrl_dynamic(struct nvme_ctrl *ctrl)
+{
+ return ctrl->cntlid == 0xffff;
+}
+
#ifdef CONFIG_FAULT_INJECTION_DEBUG_FS
void nvme_fault_inject_init(struct nvme_fault_inject *fault_inj,
const char *dev_name);
--
2.29.2
next reply other threads:[~2022-01-27 13:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 13:36 Daniel Wagner [this message]
2022-01-27 17:17 ` Keith Busch
2022-01-28 10:31 ` Daniel Wagner
2022-01-28 12:36 ` Daniel Wagner
2022-01-28 17:06 ` Hannes Reinecke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220127133648.8201-1-dwagner@suse.de \
--to=dwagner@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®