Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp143883ybt; Tue, 7 Jul 2020 18:33:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyEJ2q5OpOzyJFFo6wWwFGI+l8c4WMCp8X5QGweHG/gLtiqdZM/7uvmb71MyRIUC5n4jr+W X-Received: by 2002:a17:906:c0da:: with SMTP id bn26mr48644832ejb.359.1594172024456; Tue, 07 Jul 2020 18:33:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594172024; cv=none; d=google.com; s=arc-20160816; b=SYkMsEAlXIVGkeon8KN64pC8JTcCKxtiaG+BIuXvQUOrldery9igxCFE1GuA33/v2J AL5Wh16VjWoIH5P/GqzA0qiTzquMBbqSJ11LeCHsUTeRnV2EMhoXl43UWNCvh7d64jNM gD72enJAJ+YZv6ewb5J0BNdhj1oYBgwrBjdPFEFs5YxegCSjgYOqtS1/4dKygxjn/CI0 sONc+HO0KaLKB++CzvVzd1vVZTo4rEhxviOIIdWnXlCFd+Bij6TWjO7nSKtafYBTcfPU JiVImDsJWc7L/CZhICJfbknJs7ofV4XqeigzUkCYX5pkN7DO+ul6SiZYMhxPP27dtkFg 41Tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:message-id :subject:cc:to:from:date; bh=JM/6CASx3a0O8at5o00kDNBamcJgnFUHYPE6B2dOyFw=; b=WCvS5J+OLIdAqkDJNgqbDxL353rUrgOyChR/0HyFVU6FqA8F0dP/E/FIlekZeuqBix qBAm8vhzpEFDDIMk32NyOFtDq5gdMESqRaHPrg7wnyRIPyCOnPVeLrcVN/uAAznXeLpu IkOxTs5pA2BY6rsCxXhvrDFXn7OWSfSEibpp2I89dhVEv7TeqV+cShhmvQ8TPDaqT7Z5 qEfEaCV73iEr6Ed1ZN+65J3eHBS+JxZW4v+52bsczF6mCx5avRv+39gZVaBfQygONIJC B0duO3x1DIOyIyzZwTJZIS6YkfwdOfLySstltXk/P/dTlPfmeEGdwcCTfcRIvCb5lZrh zzvA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p1si12777601edm.302.2020.07.07.18.33.21; Tue, 07 Jul 2020 18:33:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729215AbgGHBZ1 (ORCPT + 99 others); Tue, 7 Jul 2020 21:25:27 -0400 Received: from out4436.biz.mail.alibaba.com ([47.88.44.36]:15597 "EHLO out4436.biz.mail.alibaba.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728208AbgGHBZ1 (ORCPT ); Tue, 7 Jul 2020 21:25:27 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R201e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e07484;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0U243BBC_1594171524; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0U243BBC_1594171524) by smtp.aliyun-inc.com(127.0.0.1); Wed, 08 Jul 2020 09:25:25 +0800 Date: Wed, 8 Jul 2020 09:25:24 +0800 From: Baolin Wang To: Keith Busch Cc: axboe@fb.com, hch@lst.de, sagi@grimberg.me, baolin.wang7@gmail.com, linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 5/5] nvme-pci: Use standard block status macro Message-ID: <20200708012524.GA117160@VM20190228-100.tbsite.net> Reply-To: Baolin Wang References: <20200707190123.GB1997220@dhcp-10-100-145-180.wdl.wdc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200707190123.GB1997220@dhcp-10-100-145-180.wdl.wdc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 07, 2020 at 12:01:23PM -0700, Keith Busch wrote: > On Fri, Jul 03, 2020 at 10:49:24AM +0800, Baolin Wang wrote: > > static blk_status_t nvme_map_data(struct nvme_dev *dev, struct request *req, > > @@ -844,7 +844,7 @@ static blk_status_t nvme_map_metadata(struct nvme_dev *dev, struct request *req, > > if (dma_mapping_error(dev->dev, iod->meta_dma)) > > return BLK_STS_IOERR; > > cmnd->rw.metadata = cpu_to_le64(iod->meta_dma); > > - return 0; > > + return BLK_STS_OK; > > } > > This is fine, though it takes knowing that this value is 0 for the > subsequent 'if (!ret)' check to make sense. Maybe those should change to > 'if (ret != BLK_STS_OK)' so the check uses the same symbol as the > return, and will always work in the unlikely event that the defines > are reordered. Okay, I will send another patch to convert to 'if (ret != BLK_STS_OK)' validation. Thanks.