[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191030152212.ifzhl2w3knapc367@bogus>
Date: Wed, 30 Oct 2019 10:22:12 -0500
From: Rob Herring <robh@...nel.org>
To: Will Deacon <will@...nel.org>
Cc: iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
Robin Murphy <robin.murphy@....com>,
Joerg Roedel <joro@...tes.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Subject: Re: [PATCH 7/7] iommu/arm-smmu: Allow building as a module
On Wed, Oct 30, 2019 at 02:51:12PM +0000, Will Deacon wrote:
> By conditionally dropping support for the legacy binding and exporting
> the newly introduced 'arm_smmu_impl_init()' function we can allow the
> ARM SMMU driver to be built as a module.
>
> Signed-off-by: Will Deacon <will@...nel.org>
> ---
> drivers/iommu/Kconfig | 14 ++++++++-
> drivers/iommu/arm-smmu-impl.c | 6 ++++
> drivers/iommu/arm-smmu.c | 54 +++++++++++++++++++++--------------
> 3 files changed, 51 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 7583d47fc4d5..02703f51e533 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -350,7 +350,7 @@ config SPAPR_TCE_IOMMU
>
> # ARM IOMMU support
> config ARM_SMMU
> - bool "ARM Ltd. System MMU (SMMU) Support"
> + tristate "ARM Ltd. System MMU (SMMU) Support"
> depends on (ARM64 || ARM) && MMU
> select IOMMU_API
> select IOMMU_IO_PGTABLE_LPAE
> @@ -362,6 +362,18 @@ config ARM_SMMU
> Say Y here if your SoC includes an IOMMU device implementing
> the ARM SMMU architecture.
>
> +config ARM_SMMU_LEGACY_DT_BINDINGS
> + bool "Support the legacy \"mmu-masters\" devicetree bindings"
Can't we just remove this now? The only user is Seattle. Is anyone still
using Seattle AND DT? There's been no real dts change since Feb '16.
There's a bit of clean-up needed in the Seattle dts files, so I'd like
to remove them if there's not users.
If there are users, can't we just make them move to the new binding?
Yes compatibility, but that really depends on the users caring.
I though Calxeda was using this too, but I guess we didn't get that
finished. We should probably remove that secure mode flag as well.
Rob
Powered by blists - more mailing lists