From: Christoph Hellwig <hch@lst.de>
To: Mike Christie <michael.christie@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
kbusch@kernel.org, axboe@fb.com, sagi@grimberg.me,
martin.petersen@oracle.com, jejb@linux.ibm.com,
linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org,
linux-block@vger.kernel.org
Subject: Re: [PATCH 3/3] nvme: Convert NVMe errors to PT_STS errors
Date: Tue, 15 Nov 2022 10:14:03 +0100 [thread overview]
Message-ID: <20221115091403.GA22594@lst.de> (raw)
In-Reply-To: <8adcb890-ec08-cc75-6e1a-2b8dabdcd640@oracle.com>
On Wed, Nov 09, 2022 at 11:20:07AM -0600, Mike Christie wrote:
> >> + case NVME_SC_BAD_ATTRIBUTES:
> >> + case NVME_SC_INVALID_OPCODE:
> >> + case NVME_SC_INVALID_FIELD:
> >> + case NVME_SC_INVALID_NS:
> >> + sts = PR_STS_OP_INVALID;
> >> + break;
> >
> > Second thoughts on these: shouldn't we just return negative Linux
> > errnos here?
>
> I wasn't sure. I might have over thought it.
>
> I added the PR_STS error codes for those cases so a user could
> distinguish if the command was sent to the device and it
> reported it didn't support the command or the device determined it
> had an invalid field set.
But does it matter if the device or the kernel doesn't support
them? The result for the users is very much the same.
next prev parent reply other threads:[~2022-11-15 9:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 3:11 [PATCH 0/3] block/scsi/nvme: Add error codes for PR ops Mike Christie
2022-11-09 3:11 ` [PATCH 1/3] block: Add error codes for common PR failures Mike Christie
2022-11-09 6:52 ` Christoph Hellwig
2022-11-09 3:11 ` [PATCH 2/3] scsi: Convert SCSI errors to PR_STS errors Mike Christie
2022-11-09 6:52 ` Christoph Hellwig
2022-11-10 18:59 ` kernel test robot
2022-11-10 19:29 ` kernel test robot
2022-11-09 3:11 ` [PATCH 3/3] nvme: Convert NVMe errors to PT_STS errors Mike Christie
2022-11-09 6:53 ` Christoph Hellwig
2022-11-09 17:20 ` Mike Christie
2022-11-15 9:14 ` Christoph Hellwig [this message]
2022-11-15 16:56 ` Mike Christie
2022-11-09 8:28 ` Chao Leng
2022-11-09 17:35 ` Mike Christie
2022-11-10 0:58 ` Chao Leng
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=20221115091403.GA22594@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=jejb@linux.ibm.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=michael.christie@oracle.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