Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp136659ybx; Wed, 30 Oct 2019 12:32:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqwAKeLBxVeIkkDoIuOcopp10BHlhF311bAgZW8yX60LkWq/molCDEueBvyGiO/SgJHnq8zA X-Received: by 2002:a05:6402:1490:: with SMTP id e16mr1605786edv.64.1572463976088; Wed, 30 Oct 2019 12:32:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572463976; cv=none; d=google.com; s=arc-20160816; b=z48r2svmKaoTz6+O3/1Tm4fA4zSqAXT0c2j0qfdfIQ5RjuH4m14ydxPu9u+hsSbKsr V9ZiF1CZCZRYj7TUyIEU69Flq22kYQAxchniYr7Qe2aA/DOTR/aCR0ZeeGlt+QufVN/g 0EMqbRKvBdikLr2/IMX46LP2BzStiTglMyVl+bYHjh1QJpXCJEovOvZbjXokJrwqwfSQ PNf+dGAonFA6HEDDxm93gevG4PeEFTOmUskQj6PwTIwroo4z9PtXDsOfMC6J5Ijl8uj6 xHULq1Q/+kKi5Ht7M/GGE3tp44Rmal8PHerN0HkUJTPmR+DHr+HWzfuau4HorZD6NxjU +E6Q== 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:message-id:subject:cc :to:from:date; bh=VQlaidbF825ZAl5+tQkWugxp5PQnjTYqPiE3yQjo4fI=; b=Xgji8QYTRtgUXz6Wcw8bJTDjKdziHneG0e4v27uF1grexEUnLHBFXIz7hTyr9sEh4Y H8MrGici5oPx71cvprFNmn3/6xv40xDTP2TkQOty8My/t70YU1eGyS/F/J9Iwyu8e6oI 7HXb8/SCJNzouTYe9ctIvVIQvWA9ZYP9rj0l7K1dXFN4sZQV4wLL4EFS1JqvnoOcCchG szzdmCNH18DF8vc9MR0qkb7Vm/dJYdNXg3IPSRG2gE4LpepjUZ8MT0UhsFWOW0B/b0cW I44bUPfmhkOy1S1wiQWIXwimJVId6mwQW4+Rbv5DLbtg+DtAAEKgDqOSNBLsaOBHJgzN 7J+A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d15si1969876ejw.269.2019.10.30.12.32.31; Wed, 30 Oct 2019 12:32:56 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=8bytes.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726530AbfJ3Tbv (ORCPT + 99 others); Wed, 30 Oct 2019 15:31:51 -0400 Received: from 8bytes.org ([81.169.241.247]:50098 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726261AbfJ3Tbv (ORCPT ); Wed, 30 Oct 2019 15:31:51 -0400 Received: by theia.8bytes.org (Postfix, from userid 1000) id 0CD73148; Wed, 30 Oct 2019 20:31:48 +0100 (CET) Date: Wed, 30 Oct 2019 20:31:48 +0100 From: Joerg Roedel To: Will Deacon Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Robin Murphy , Bjorn Helgaas , Lorenzo Pieralisi Subject: Re: [PATCH 5/7] iommu/arm-smmu-v3: Allow building as a module Message-ID: <20191030193148.GA8432@8bytes.org> References: <20191030145112.19738-1-will@kernel.org> <20191030145112.19738-6-will@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191030145112.19738-6-will@kernel.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Will, On Wed, Oct 30, 2019 at 02:51:10PM +0000, Will Deacon wrote: > By removing the redundant call to 'pci_request_acs()' we can allow the > ARM SMMUv3 driver to be built as a module. > > Signed-off-by: Will Deacon > --- > drivers/iommu/Kconfig | 2 +- > drivers/iommu/arm-smmu-v3.c | 1 - > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig > index e3842eabcfdd..7583d47fc4d5 100644 > --- a/drivers/iommu/Kconfig > +++ b/drivers/iommu/Kconfig > @@ -388,7 +388,7 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT > config. > > config ARM_SMMU_V3 > - bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support" > + tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support" > depends on ARM64 > select IOMMU_API > select IOMMU_IO_PGTABLE_LPAEa Sorry for the stupid question, but what prevents the iommu module from being unloaded when there are active users? There are no symbol dependencies to endpoint device drivers, because the interface is only exposed through the iommu-api, right? Is some sort of manual module reference counting needed? Joerg