From: Jordan Crouse <jcrouse@codeaurora.org>
To: Will Deacon <will@kernel.org>
Cc: iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH 6/7] Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular"
Date: Wed, 30 Oct 2019 17:09:41 -0600 [thread overview]
Message-ID: <20191030230941.GA8188@jcrouse1-lnx.qualcomm.com> (raw)
In-Reply-To: <20191030145112.19738-7-will@kernel.org>
On Wed, Oct 30, 2019 at 02:51:11PM +0000, Will Deacon wrote:
> This reverts commit addb672f200f4e99368270da205320b83efe01a0.
>
> Let's get the SMMU driver building as a module, which means putting
> back some dead code that we used to carry.
>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> drivers/iommu/arm-smmu.c | 32 +++++++++++++++++++-------------
> 1 file changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 7c503a6bc585..53bbe0663b9e 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -27,8 +27,7 @@
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/iopoll.h>
> -#include <linux/init.h>
> -#include <linux/moduleparam.h>
> +#include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_address.h>
> #include <linux/of_device.h>
> @@ -59,10 +58,6 @@
> #define MSI_IOVA_LENGTH 0x100000
>
> static int force_stage;
> -/*
> - * not really modular, but the easiest way to keep compat with existing
> - * bootargs behaviour is to continue using module_param() here.
> - */
> module_param(force_stage, int, S_IRUGO);
> MODULE_PARM_DESC(force_stage,
> "Force SMMU mappings to be installed at a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
> @@ -1878,6 +1873,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
> { .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
> { },
> };
> +MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
>
> #ifdef CONFIG_ACPI
> static int acpi_smmu_get_data(u32 model, struct arm_smmu_device *smmu)
> @@ -2165,12 +2161,12 @@ static int arm_smmu_legacy_bus_init(void)
> }
> device_initcall_sync(arm_smmu_legacy_bus_init);
>
> -static void arm_smmu_device_shutdown(struct platform_device *pdev)
> +static int arm_smmu_device_remove(struct platform_device *pdev)
> {
> struct arm_smmu_device *smmu = platform_get_drvdata(pdev);
>
> if (!smmu)
> - return;
> + return -ENODEV;
>
> if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS))
> dev_err(&pdev->dev, "removing device with active domains!\n");
> @@ -2186,6 +2182,12 @@ static void arm_smmu_device_shutdown(struct platform_device *pdev)
> clk_bulk_disable(smmu->num_clks, smmu->clks);
>
> clk_bulk_unprepare(smmu->num_clks, smmu->clks);
> + return 0;
> +}
> +
> +static void arm_smmu_device_shutdown(struct platform_device *pdev)
> +{
> + arm_smmu_device_remove(pdev);
> }
>
> static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
> @@ -2235,12 +2237,16 @@ static const struct dev_pm_ops arm_smmu_pm_ops = {
>
> static struct platform_driver arm_smmu_driver = {
> .driver = {
> - .name = "arm-smmu",
> - .of_match_table = of_match_ptr(arm_smmu_of_match),
> - .pm = &arm_smmu_pm_ops,
> - .suppress_bind_attrs = true,
> + .name = "arm-smmu",
> + .of_match_table = of_match_ptr(arm_smmu_of_match),
> + .pm = &arm_smmu_pm_ops,
> },
> .probe = arm_smmu_device_probe,
> + .remove = arm_smmu_device_remove,
> .shutdown = arm_smmu_device_shutdown,
> };
> -builtin_platform_driver(arm_smmu_driver);
> +module_platform_driver(arm_smmu_driver);
I know this is a revert, but wouldn't you still want to be at device_init()
level for built in drivers? It always preferable to not defer if given the
choice to do so and device_init() is the right level for this driver IMO.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2019-10-30 23:09 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-30 14:51 [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers Will Deacon
2019-10-30 14:51 ` [PATCH 1/7] drivers/iommu: Export core IOMMU API symbols to permit modular drivers Will Deacon
2019-10-30 14:51 ` [PATCH 2/7] iommu/of: Request ACS from the PCI core when configuring IOMMU linkage Will Deacon
2019-10-30 14:51 ` [PATCH 3/7] PCI: Export pci_ats_disabled() as a GPL symbol to modules Will Deacon
2019-10-30 20:30 ` Bjorn Helgaas
2019-10-30 14:51 ` [PATCH 4/7] Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular" Will Deacon
2019-10-30 14:51 ` [PATCH 5/7] iommu/arm-smmu-v3: Allow building as a module Will Deacon
2019-10-30 19:31 ` Joerg Roedel
2019-10-31 15:42 ` Will Deacon
2019-11-04 19:15 ` Jean-Philippe Brucker
2019-11-08 14:54 ` Will Deacon
2019-11-05 12:15 ` Joerg Roedel
2019-11-08 11:03 ` Will Deacon
2019-10-30 14:51 ` [PATCH 6/7] Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular" Will Deacon
2019-10-30 23:09 ` Jordan Crouse [this message]
2019-10-31 12:03 ` Will Deacon
2019-10-31 15:32 ` Jordan Crouse
2019-10-30 14:51 ` [PATCH 7/7] iommu/arm-smmu: Allow building as a module Will Deacon
2019-10-30 15:22 ` Rob Herring
2019-10-30 15:26 ` Will Deacon
2019-10-30 15:33 ` Robin Murphy
2019-11-04 19:34 ` Isaac J. Manjarres
2019-11-07 12:48 ` Will Deacon
2019-10-30 15:35 ` [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers Robin Murphy
2019-10-30 15:54 ` Will Deacon
2019-10-31 0:57 ` Saravana Kannan
2019-10-31 19:37 ` Jean-Philippe Brucker
2019-10-31 23:34 ` Saravana Kannan
2019-11-01 10:27 ` John Garry
2019-11-01 21:13 ` Saravana Kannan
2019-11-04 12:16 ` John Garry
2019-11-04 13:29 ` Robin Murphy
2019-11-07 6:11 ` Saravana Kannan
2019-11-07 9:13 ` Jean-Philippe Brucker
2019-11-07 6:02 ` Saravana Kannan
2019-11-01 11:41 ` Jean-Philippe Brucker
2019-11-01 12:28 ` Lorenzo Pieralisi
2019-11-01 21:26 ` Saravana Kannan
2019-11-04 11:43 ` Lorenzo Pieralisi
2019-11-07 5:55 ` Saravana Kannan
2019-11-01 17:21 ` Will Deacon
2019-11-04 7:54 ` Jean-Philippe Brucker
2019-11-07 6:16 ` Saravana Kannan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191030230941.GA8188@jcrouse1-lnx.qualcomm.com \
--to=jcrouse@codeaurora.org \
--cc=bhelgaas@google.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).