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;
Subject: Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers
To:     Will Deacon <will@kernel.org>, iommu@lists.linux-foundation.org,
        linux-kernel@vger.kernel.org
Cc:     Joerg Roedel <joro@8bytes.org>,
        Bjorn Helgaas <bhelgaas@google.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
References: <20191030145112.19738-1-will@kernel.org>
From:   Robin Murphy <robin.murphy@arm.com>
Message-ID: <6e457227-ca06-2998-4ffa-a58ab171ce32@arm.com>
Date:   Wed, 30 Oct 2019 15:35:55 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20191030145112.19738-1-will@kernel.org>
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

On 30/10/2019 14:51, Will Deacon wrote:
> Hi all,
> 
> As part of the work to enable a "Generic Kernel Image" across multiple
> Android devices, there is a need to seperate shared, core kernel code
> from modular driver code that may not be needed by all SoCs. This means
> building IOMMU drivers as modules.
> 
> It turns out that most of the groundwork has already been done to enable
> the ARM SMMU drivers to be 'tristate' options in drivers/iommu/Kconfig;
> with a few symbols exported from the IOMMU/PCI core, everything builds
> nicely out of the box. The one exception is support for the legacy SMMU
> DT binding, which is not in widespread use and has never worked with
> modules, so we can simply remove that when building as a module rather
> than try to paper over it with even more hacks.
> 
> Obviously you need to be careful about using IOMMU drivers as modules,
> since late loading of the driver for an IOMMU serving active DMA masters
> is going to end badly in many cases. On Android, we're using device links
> to ensure that the IOMMU probes first.

Out of curiosity, which device links are those? Clearly not the RPM 
links created by the IOMMU drivers themselves... Is this some special 
Android magic, or is there actually a chance of replacing all the 
of_iommu_configure() machinery with something more generic?

Robin.

> 
> Comments welcome,
> 
> Will
> 
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> 
> --->8
> 
> Will Deacon (7):
>    drivers/iommu: Export core IOMMU API symbols to permit modular drivers
>    iommu/of: Request ACS from the PCI core when configuring IOMMU linkage
>    PCI: Export pci_ats_disabled() as a GPL symbol to modules
>    Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular"
>    iommu/arm-smmu-v3: Allow building as a module
>    Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular"
>    iommu/arm-smmu: Allow building as a module
> 
>   drivers/iommu/Kconfig         | 16 ++++++-
>   drivers/iommu/arm-smmu-impl.c |  6 +++
>   drivers/iommu/arm-smmu-v3.c   | 26 +++++++----
>   drivers/iommu/arm-smmu.c      | 86 +++++++++++++++++++++--------------
>   drivers/iommu/iommu-sysfs.c   |  5 ++
>   drivers/iommu/iommu.c         |  8 ++++
>   drivers/iommu/of_iommu.c      |  1 +
>   drivers/pci/pci.c             |  1 +
>   8 files changed, 102 insertions(+), 47 deletions(-)
>