public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: joro@8bytes.org, will@kernel.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, baolu.lu@linux.intel.com
Subject: Re: [PATCH v3 2/7] iommu: Decouple iommu_present() from bus ops
Date: Mon, 18 Sep 2023 14:12:16 -0300	[thread overview]
Message-ID: <20230918171216.GK13733@nvidia.com> (raw)
In-Reply-To: <b7cd933aa7774ad687c695ebe5e00c17178a7542.1694693889.git.robin.murphy@arm.com>

On Fri, Sep 15, 2023 at 05:58:06PM +0100, Robin Murphy wrote:
> Much as I'd like to remove iommu_present(), the final remaining users
> are proving stubbornly difficult to clean up, so kick that can down
> the road and just rework it to preserve the current behaviour without
> depending on bus ops.
> 
> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> 
> ---
> 
> v3: Tweak to use the ops-based check rather than group-based, to
>     properly match the existing behaviour
> ---
>  drivers/iommu/iommu.c | 17 ++++++++++++++++-
>  1 file changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 4566d0001cd3..2f29ee9dea64 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1907,9 +1907,24 @@ int bus_iommu_probe(const struct bus_type *bus)
>  	return 0;
>  }
>  
> +static int __iommu_present(struct device *dev, void *unused)
> +{
> +	return dev_has_iommu(dev);
> +}

This is not locked right..

Rather than perpetuate that, can we fix the two callers instead?

Maybe this for mtk:

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 93552d76b6e778..e7fe0e6f27de85 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -500,6 +500,8 @@ static int mtk_drm_kms_init(struct drm_device *drm)
                dev_err(drm->dev, "Need at least one OVL device\n");
                goto err_component_unbind;
        }
+       if (!device_iommu_mapped(dma_dev))
+               return -EPROBE_DEFER;
 
        for (i = 0; i < private->data->mmsys_dev_num; i++)
                private->all_drm_private[i]->dma_dev = dma_dev;
@@ -583,9 +585,6 @@ static int mtk_drm_bind(struct device *dev)
        struct drm_device *drm;
        int ret, i;
 
-       if (!iommu_present(&platform_bus_type))
-               return -EPROBE_DEFER;
-
        pdev = of_find_device_by_node(private->mutex_node);
        if (!pdev) {
                dev_err(dev, "Waiting for disp-mutex device %pOF\n",


? It doesn't seem to use the iommu API so I guess all it is doing is
trying to fix some kind of probe ordering issue? Maybe the probe
ordering issue is already gone and we can just delete the check?

And tegra:

	if (host1x_drm_wants_iommu(dev) && iommu_present(&platform_bus_type)) {
		tegra->domain = iommu_domain_alloc(&platform_bus_type);
		if (!tegra->domain) {

Lets do the same:

	if (host1x_drm_wants_iommu(dev) && device_iommu_mapped(dev->dev.parent)) {

?

Alternatively how about:

bool iommu_present(void)
{
	bool ret;

	spin_lock(&iommu_device_lock);
	ret = !list_empty(&iommu_device_list);
	spin_unlock(&iommu_device_lock);
	return ret;
}
EXPORT_SYMBOL_GPL(iommu_present);

Since neither of the two users is really needing anything more than that?

Jason

  reply	other threads:[~2023-09-18 17:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15 16:58 [PATCH v3 0/7] Iommu: Retire bus ops Robin Murphy
2023-09-15 16:58 ` [PATCH v3 1/7] iommu: Factor out some helpers Robin Murphy
2023-09-18 16:36   ` Jason Gunthorpe
2023-09-15 16:58 ` [PATCH v3 2/7] iommu: Decouple iommu_present() from bus ops Robin Murphy
2023-09-18 17:12   ` Jason Gunthorpe [this message]
2023-09-18 19:21     ` Robin Murphy
2023-09-18 23:25       ` Jason Gunthorpe
2023-09-15 16:58 ` [PATCH v3 3/7] iommu: Validate that devices match domains Robin Murphy
2023-09-18  5:49   ` Baolu Lu
2023-09-18 10:08     ` Robin Murphy
2023-09-15 16:58 ` [PATCH v3 4/7] iommu: Switch __iommu_domain_alloc() to device ops Robin Murphy
2023-09-18  6:10   ` Baolu Lu
2023-09-18 10:36     ` Robin Murphy
2023-09-15 16:58 ` [PATCH v3 5/7] iommu/arm-smmu: Don't register fwnode for legacy binding Robin Murphy
2023-09-15 16:58 ` [PATCH v3 6/7] iommu: Retire bus ops Robin Murphy
2023-09-15 16:58 ` [PATCH v3 7/7] iommu: Clean up open-coded ownership checks Robin Murphy
2023-09-18 16:24 ` [PATCH v3 0/7] Iommu: Retire bus ops Jason Gunthorpe

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=20230918171216.GK13733@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.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