From: Christoph Hellwig <hch@lst.de>
To: Greg Joyce <gjoyce@linux.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org, kbusch@kernel.org, axboe@fb.com,
sagi@grimberg.me, hare@suse.de, dwagner@suse.de,
msuchanek@suse.de, jonathan.derrick@linux.dev,
okozina@redhat.com, nilay@linux.ibm.com
Subject: Re: [PATCH 1/1] nvme: retry security commands if media not ready
Date: Fri, 4 Oct 2024 07:41:23 +0200 [thread overview]
Message-ID: <20241004054123.GA14423@lst.de> (raw)
In-Reply-To: <fd5ebec0dc273afd5d748a26c999254d3ed28f01.camel@linux.ibm.com>
On Thu, Oct 03, 2024 at 06:35:30PM -0500, Greg Joyce wrote:
> I agree, I wonder about the value/wisdom of the CC.CRIME capability
> especially since there is no way to read status that indicates that the
> media is ready for the Figure 103 commands. But it is a defined feature
> and setting it does cause CSTS.RDY to be asserted before the media is
> ready.
>
> The Kioxia CM7 drive does set both CRWMS and CRIMS (CRMS=11b). And
> these lines in the NVMe driver thus set CC.CRIME:
>
> if (ctrl->cap & NVME_CAP_CRMS_CRWMS && ctrl->cap &
> NVME_CAP_CRMS_CRIMS)
> ctrl->ctrl_config |= NVME_CC_CRIME;
>
> After reading more of the spec and driver code and discussions here, I
> suggest that those two lines be removed. This has the effect of
> returning to the NVMe version 1.4 behavior and CSTS.RDY will not be
> asserted until the media is ready for commands.
Well, it is a useful feature unless random admin commands return
not ready. Which got weaseld into the spec, but really should not
happen to make the feature useful. So I think we'll need to put the
workaround in instead of messing up the proper implementations of
the feature that aren't this silly. And make sure the big companies
put that into their purchase specs.
next prev parent reply other threads:[~2024-10-04 5:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 16:48 [PATCH 0/1] nvme: add retry for media not ready error gjoyce
2024-09-30 16:48 ` [PATCH 1/1] nvme: retry security commands if media not ready gjoyce
2024-10-02 8:16 ` Christoph Hellwig
2024-10-02 16:51 ` Greg Joyce
2024-10-03 12:43 ` Christoph Hellwig
2024-10-03 13:30 ` Greg Joyce
2024-10-03 14:41 ` Christoph Hellwig
2024-10-03 23:35 ` Greg Joyce
2024-10-04 5:41 ` Christoph Hellwig [this message]
2024-10-04 7:22 ` Nilay Shroff
2024-10-04 12:24 ` Christoph Hellwig
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=20241004054123.GA14423@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=dwagner@suse.de \
--cc=gjoyce@linux.ibm.com \
--cc=hare@suse.de \
--cc=jonathan.derrick@linux.dev \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=msuchanek@suse.de \
--cc=nilay@linux.ibm.com \
--cc=okozina@redhat.com \
--cc=sagi@grimberg.me \
/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