Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3472964ybt; Tue, 30 Jun 2020 03:47:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxMJY7BNrBjyfgPq0l8s1pfz2A4BDhsg82kEbALLzoX7J2IjM7RpobyLdt9KnTC3/nn4bFl X-Received: by 2002:a17:906:2b04:: with SMTP id a4mr17018970ejg.199.1593514069633; Tue, 30 Jun 2020 03:47:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593514069; cv=none; d=google.com; s=arc-20160816; b=MK/02Pw37WMCDAgBGSXwEDJ/xUEkX7wwZIpxxGfsZi45Mry3TeKBZAu0mBVyEUShnH drJWMhrQkqwhEjxWbgKijlFR3YafXklzsJ3F7nZHk6Lz+SJZYq5PpH5eEMoKLKv57OLa O4qoBYCgpCSfSNm0apBEJ1F84kqgyy7m57npcp7iph4IKz62T99Ihm6YBwqIe6qPNiHY ituJOjkD/aLN/UsNbFrjhu8LCDBAsigbtcoWAoUChYR7Vv6rTFVl7siFUDWhjp64qkz8 WpopAzm3yumWkVTbF/Yct4DJsFv3qvgR5U5EAsNt3d5z2VCkTPjO1I8N3wmGh3g90lAl o/bQ== 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; bh=I2u7mr7mDqUW04g3JxCi/a7RNRlgqt/zEVQwzBXYJ5E=; b=eWBP4JldV6lBu7M8WCHy0rzwSSQ1szPkGdcf2T5WcQ3XdhXron8IGfZlGWl/Esam16 93kuCRaoP/A2qHnJJSqBaEqA46lb6nadjyT9FYon0Mqyc9E/Vt+LOsoXvR7EXoD1rUlf AWf8+5FGtV1Zf1VF1AkMFm3L25o5RUtkNWdZbQI8GrNexuBRw5W5jSs1+xv+IBQ92yGI Or74MBnRo1wGil/5N8h33Hx4qzmeNvvUHhMkbaTkwGtM2thXTT3PDkna8G9q2/vrEt3e XkrC2BBQcd1QH6vPe4dgHKUJ/3A04EVpmbwSfCWW/nVQokr+o2zIo1+OrARA3l12u2qU EgsA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g22si1577035edr.336.2020.06.30.03.47.26; Tue, 30 Jun 2020 03:47:49 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732607AbgF3Kqp (ORCPT + 99 others); Tue, 30 Jun 2020 06:46:45 -0400 Received: from foss.arm.com ([217.140.110.172]:37864 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732510AbgF3Kqo (ORCPT ); Tue, 30 Jun 2020 06:46:44 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D59BF30E; Tue, 30 Jun 2020 03:46:43 -0700 (PDT) Received: from [10.57.21.32] (unknown [10.57.21.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 06D153F68F; Tue, 30 Jun 2020 03:46:40 -0700 (PDT) Subject: Re: [PATCH v7 1/3] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage To: Jon Hunter , Krishna Reddy , Nicolin Chen Cc: "joro@8bytes.org" , "will@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "iommu@lists.linux-foundation.org" , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" , Thierry Reding , Yu-Huan Hsu , Sachin Nikam , Pritesh Raithatha , Timo Alho , Bitan Biswas , Mikko Perttunen , Nicolin Chen , Bryan Huntsman References: <20200629022838.29628-1-vdumpa@nvidia.com> <20200629022838.29628-2-vdumpa@nvidia.com> <20200629215124.GD27967@Asurada-Nvidia> From: Robin Murphy Message-ID: Date: Tue, 30 Jun 2020 11:46:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-06-30 11:23, Jon Hunter wrote: > > On 29/06/2020 23:49, Krishna Reddy wrote: >>>> + if (!nvidia_smmu->bases[0]) >>>> + nvidia_smmu->bases[0] = smmu->base; >>>> + >>>> + return nvidia_smmu->bases[inst] + (page << smmu->pgshift); } >> >>> Not critical -- just a nit: why not put the bases[0] in init()? >> >> smmu->base is not available during nvidia_smmu_impl_init() call. It is set afterwards in arm-smmu.c. >> It can't be avoided without changing the devm_ioremap() and impl_init() call order in arm-smmu.c. > > > Why don't we move the call to devm_ioremap_resource() to before > arm_smmu_impl_init() in arm_smmu_device_probe()? From a quick look I > don't see why we cannot do this and seems better than what we are > currently doing which is quite confusing and hard to understand. Yeah, I don't see any problem with adding a patch to do that. impl_init() does need to happen before generic probe starts touching any registers, but it wouldn't have any business overriding the platform resources or anything that would affect the ioremap itself. Plus it's reasonable that some theoretical future impl_init() might want to check registers for, say, a particular hardware revision, so having smmmu->base mapped and valid at that point would be no bad thing. Robin.