Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp585942imm; Thu, 31 May 2018 06:04:49 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJtKROOZzGygduGy4xA/mZfKrK6S17AKtsogVslaAD/EtyzVNbFsK1Rti3dFuu6ZHVbiykW X-Received: by 2002:a62:249b:: with SMTP id k27-v6mr6764940pfk.143.1527771889561; Thu, 31 May 2018 06:04:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527771889; cv=none; d=google.com; s=arc-20160816; b=nDHyc5R6579jTmfmmCrqxBNDQ+4/Mo4skFSBWiS9hQq3mN6bkspmDKC+Bw3p5qXLGi zxiGkMCylo1qNP937+OVCg/UrKeA5DMXYQXxT2kJF+zn6fN9gGvGm+OFjauS6aba/W+T kIclP2siJdpsIjOpx7N6RuPTcVVwU4vsjj5r81emu3gAk4QrP+2DQRyMKQWIdXhiEsOD WqO2ExtFBvJTS8y5IZZlXYUijL3v5dyGJhZb0jb4Fhe6ZfVkDZL49+QyDfRIcaeheUs0 +oSC4nOdlOIkrDgh4hcGM/ajwsFp8RdX6s0iVS2W+Qq4Cq2lxlHd4+zc6QRDKsUJxdqJ 4EIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=9S7VBfFPkKDnQpwaGJbJNRud9afJ1B5ooltcXYIq7qQ=; b=B6laC61HDVWTjQYvUrnTKHPReiwTSY5kSzY9VbFEajIrIv2ZLJIBoPdlMzMuUh/svK kLreUgeqBULw47zYyvMhrYuungeYLJ0rz6xWyNQ5JcojJ0P1aKatMTYHYJt3AEevNgoy x+Yc3hGTF4S/zpW5xT7M8m4Mz9nNHXasiy0s201g83oLrbqB29Ctr7i8SGtNBqmXLdt+ PGTC9CwiPzTAOOfvZIh2slqyBPV3suK29CqwJIqUoULHZI38SIPlu1lyqbmqhvINI35+ pCARvWe82ZtKgTKEtwzmapRQRxTUUoYxQardgtr+NDAvYicahCeMtyMLIqqxVSRKhmC1 Mr5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e5-v6si29108501pgs.317.2018.05.31.06.04.35; Thu, 31 May 2018 06:04:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755129AbeEaNDu (ORCPT + 99 others); Thu, 31 May 2018 09:03:50 -0400 Received: from foss.arm.com ([217.140.101.70]:41138 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755042AbeEaNDr (ORCPT ); Thu, 31 May 2018 09:03:47 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 90BE715AD; Thu, 31 May 2018 06:03:46 -0700 (PDT) Received: from [10.1.210.88] (e110467-lin.cambridge.arm.com [10.1.210.88]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4687D3F53D; Thu, 31 May 2018 06:03:44 -0700 (PDT) Subject: Re: [PATCH 1/7] iommu/dma: fix trival coding style mistake To: Zhen Lei , Will Deacon , Matthias Brugger , Rob Clark , Joerg Roedel , linux-mediatek , linux-arm-msm , linux-arm-kernel , iommu , linux-kernel Cc: Hanjun Guo , Libin , Guozhu Li , Xinwei Hu References: <1527752569-18020-1-git-send-email-thunder.leizhen@huawei.com> <1527752569-18020-2-git-send-email-thunder.leizhen@huawei.com> From: Robin Murphy Message-ID: Date: Thu, 31 May 2018 14:03:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1527752569-18020-2-git-send-email-thunder.leizhen@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31/05/18 08:42, Zhen Lei wrote: > The static function iova_reserve_iommu_regions is only called by function > iommu_dma_init_domain, and the 'if (!dev)' check in iommu_dma_init_domain > affect it only, so we can safely move the check into it. I think it looks > more natural. As before, I disagree - the logic of iommu_dma_init_domain() is "we expect to have a valid device, but stop here if we don't", and moving the check just needlessly obfuscates that. It is not a coincidence that the arguments of both functions are in effective order of importance. > In addition, the local variable 'ret' is only assigned in the branch of > 'if (region->type == IOMMU_RESV_MSI)', so the 'if (ret)' should also only > take effect in the branch, add a brace to enclose it. 'ret' is clearly also assigned at its declaration, to cover the (very likely) case where we don't enter the loop at all. Thus testing it in the loop is harmless, and cluttering that up with extra tabs and braces is just noise. Robin. > No functional changes. > > Signed-off-by: Zhen Lei > --- > drivers/iommu/dma-iommu.c | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c > index ddcbbdb..4e885f7 100644 > --- a/drivers/iommu/dma-iommu.c > +++ b/drivers/iommu/dma-iommu.c > @@ -231,6 +231,9 @@ static int iova_reserve_iommu_regions(struct device *dev, > LIST_HEAD(resv_regions); > int ret = 0; > > + if (!dev) > + return 0; > + > if (dev_is_pci(dev)) > iova_reserve_pci_windows(to_pci_dev(dev), iovad); > > @@ -246,11 +249,12 @@ static int iova_reserve_iommu_regions(struct device *dev, > hi = iova_pfn(iovad, region->start + region->length - 1); > reserve_iova(iovad, lo, hi); > > - if (region->type == IOMMU_RESV_MSI) > + if (region->type == IOMMU_RESV_MSI) { > ret = cookie_init_hw_msi_region(cookie, region->start, > region->start + region->length); > - if (ret) > - break; > + if (ret) > + break; > + } > } > iommu_put_resv_regions(dev, &resv_regions); > > @@ -308,8 +312,6 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base, > } > > init_iova_domain(iovad, 1UL << order, base_pfn); > - if (!dev) > - return 0; > > return iova_reserve_iommu_regions(dev, domain); > } >