* [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK [not found] <CGME20220418194351uscas1p18e05fad61bc279e8ea18d1a1a8597dc3@uscas1p1.samsung.com> @ 2022-04-18 19:43 ` Vincent Fu 2022-04-19 14:16 ` Pankaj Raghav ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Vincent Fu @ 2022-04-18 19:43 UTC (permalink / raw) To: linux-nvme; +Cc: Vincent Fu Return BLK_STS_OK instead of 0 on success. Since BLK_STS_OK is defined as 0 this patch results in no functional change but to avoid confusion and to be consistent with nvme_setup_write_zeroes as well as nvme_setup_discard we should have nvme_setup_rw also return BLK_STS_OK. Signed-off-by: Vincent Fu <vincent.fu@samsung.com> --- 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 b9b0fbde9..f45665e36 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -895,7 +895,7 @@ static inline blk_status_t nvme_setup_rw(struct nvme_ns *ns, cmnd->rw.control = cpu_to_le16(control); cmnd->rw.dsmgmt = cpu_to_le32(dsmgmt); - return 0; + return BLK_STS_OK; } void nvme_cleanup_cmd(struct request *req) -- 2.25.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK 2022-04-18 19:43 ` [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK Vincent Fu @ 2022-04-19 14:16 ` Pankaj Raghav 2022-04-26 14:14 ` Sagi Grimberg 2022-04-28 15:07 ` Christoph Hellwig 2 siblings, 0 replies; 5+ messages in thread From: Pankaj Raghav @ 2022-04-19 14:16 UTC (permalink / raw) To: Vincent Fu; +Cc: linux-nvme, Pankaj Raghav On Mon, Apr 18, 2022 at 07:43:50PM +0000, Vincent Fu wrote: > Return BLK_STS_OK instead of 0 on success. Since BLK_STS_OK is defined > as 0 this patch results in no functional change but to avoid confusion > and to be consistent with nvme_setup_write_zeroes as well as > nvme_setup_discard we should have nvme_setup_rw also return BLK_STS_OK. > > Signed-off-by: Vincent Fu <vincent.fu@samsung.com> > --- > 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 b9b0fbde9..f45665e36 100644 > --- a/drivers/nvme/host/core.c > +++ b/drivers/nvme/host/core.c > @@ -895,7 +895,7 @@ static inline blk_status_t nvme_setup_rw(struct nvme_ns *ns, > > cmnd->rw.control = cpu_to_le16(control); > cmnd->rw.dsmgmt = cpu_to_le32(dsmgmt); > - return 0; > + return BLK_STS_OK; > } > > void nvme_cleanup_cmd(struct request *req) > -- > 2.25.1 > Small nit: The commit line could be changed to: nvme: return BLK_STS_OK on success in nvme_setup_rw Otherwise, Looks good. Reviewed-by: Pankaj Raghav <p.raghav@samsung.com> -- Pankaj Raghav ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK 2022-04-18 19:43 ` [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK Vincent Fu 2022-04-19 14:16 ` Pankaj Raghav @ 2022-04-26 14:14 ` Sagi Grimberg 2022-04-28 15:07 ` Christoph Hellwig 2 siblings, 0 replies; 5+ messages in thread From: Sagi Grimberg @ 2022-04-26 14:14 UTC (permalink / raw) To: Vincent Fu, linux-nvme Reviewed-by: Sagi Grimberg <sagi@grimberg.me> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK 2022-04-18 19:43 ` [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK Vincent Fu 2022-04-19 14:16 ` Pankaj Raghav 2022-04-26 14:14 ` Sagi Grimberg @ 2022-04-28 15:07 ` Christoph Hellwig 2022-04-28 15:24 ` Vincent Fu 2 siblings, 1 reply; 5+ messages in thread From: Christoph Hellwig @ 2022-04-28 15:07 UTC (permalink / raw) To: Vincent Fu; +Cc: linux-nvme On Mon, Apr 18, 2022 at 07:43:50PM +0000, Vincent Fu wrote: > Return BLK_STS_OK instead of 0 on success. Since BLK_STS_OK is defined > as 0 this patch results in no functional change but to avoid confusion > and to be consistent with nvme_setup_write_zeroes as well as > nvme_setup_discard we should have nvme_setup_rw also return BLK_STS_OK. I really don't see the point. blk_status_t like all __bitwise types is designed to be able to cope with a plain 0 just fine. ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK 2022-04-28 15:07 ` Christoph Hellwig @ 2022-04-28 15:24 ` Vincent Fu 0 siblings, 0 replies; 5+ messages in thread From: Vincent Fu @ 2022-04-28 15:24 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-nvme > -----Original Message----- > From: Christoph Hellwig [mailto:hch@infradead.org] > Sent: Thursday, April 28, 2022 11:08 AM > To: Vincent Fu <vincent.fu@samsung.com> > Cc: linux-nvme@lists.infradead.org > Subject: Re: [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK > > On Mon, Apr 18, 2022 at 07:43:50PM +0000, Vincent Fu wrote: > > Return BLK_STS_OK instead of 0 on success. Since BLK_STS_OK is > defined > > as 0 this patch results in no functional change but to avoid confusion > > and to be consistent with nvme_setup_write_zeroes as well as > > nvme_setup_discard we should have nvme_setup_rw also return > BLK_STS_OK. > > I really don't see the point. blk_status_t like all __bitwise types > is designed to be able to cope with a plain 0 just fine. Thank you for the feedback. This is obviously a small cleanup but I found it confusing that the other nvme_setup_* functions returned BLK_STS_OK whereas nvme_setup_rw returned 0. The code is easier to understand if all of these functions are consistent and this change saves people the trouble of making sure that BLK_STS_OK is defined as 0. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-04-28 15:25 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20220418194351uscas1p18e05fad61bc279e8ea18d1a1a8597dc3@uscas1p1.samsung.com> 2022-04-18 19:43 ` [PATCH] nvme: have nvme_setup_rw return BLK_STS_OK Vincent Fu 2022-04-19 14:16 ` Pankaj Raghav 2022-04-26 14:14 ` Sagi Grimberg 2022-04-28 15:07 ` Christoph Hellwig 2022-04-28 15:24 ` Vincent Fu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.