From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB990C433E0 for ; Tue, 30 Jun 2020 10:47:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9E45D2065F for ; Tue, 30 Jun 2020 10:47:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="K8uobKkB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9E45D2065F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=0JAXWZT06o7N/Md2GOYQsLDV6JVjBBse99RecIvKV/U=; b=K8uobKkBrtPuSJBvxRvTDnbi9 Zh1ud1uRYKWGWPRgIOZ1daWkGutoDE7h1xEopirvJt1j1VEo9sgBCTH9byiYn6DhUSSo1f6ngDDAI w4kYYsYDt+SLz9aBbOwkqEO07pURtzo3r002ZLVRj0JVluGAZa03rLCWIh+XztZ+C4tBc9Flj0/rV zVZAtMqHAYMYF4+nXa6vEvUkeeP4y8dd1ZHPZ4UiFeN/0Pm27AusaXFI2VomTnEazDTckKo7Ul+kH EKdT365WQ3KEYu2l3RTWmTKYbhhjTgYLpJ5TSI3YuDovuXYcRt3+TmCtypD1ekWLgnz7VabQdG0vO Nema/EgAw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqDmq-0000i0-Ss; Tue, 30 Jun 2020 10:46:48 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jqDmo-0000gn-F7 for linux-arm-kernel@lists.infradead.org; Tue, 30 Jun 2020 10:46:47 +0000 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 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-Language: en-GB X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sachin Nikam , Mikko Perttunen , Bryan Huntsman , "joro@8bytes.org" , "linux-kernel@vger.kernel.org" , Pritesh Raithatha , Timo Alho , "iommu@lists.linux-foundation.org" , Nicolin Chen , "linux-tegra@vger.kernel.org" , Yu-Huan Hsu , Thierry Reding , "will@kernel.org" , "linux-arm-kernel@lists.infradead.org" , Bitan Biswas Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel