From: Robin Murphy <robin.murphy@arm.com>
To: Thierry Reding <thierry.reding@gmail.com>,
Rob Herring <robh+dt@kernel.org>, Joerg Roedel <joro@8bytes.org>
Cc: Will Deacon <will@kernel.org>, Nicolin Chen <nicolinc@nvidia.com>,
Krishna Reddy <vdumpa@nvidia.com>,
Dmitry Osipenko <dmitry.osipenko@collabora.com>,
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>,
Janne Grunau <j@jannau.net>, Sameer Pujar <spujar@nvidia.com>,
devicetree@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-tegra@vger.kernel.org, asahi@lists.linux.dev
Subject: Re: [PATCH v9 5/5] iommu/tegra-smmu: Support managed domains
Date: Fri, 7 Oct 2022 14:48:19 +0100 [thread overview]
Message-ID: <b541eb50-fd9d-1105-4ae1-640ec7df1c68@arm.com> (raw)
In-Reply-To: <20220923123557.866972-6-thierry.reding@gmail.com>
On 2022-09-23 13:35, Thierry Reding wrote:
> From: Navneet Kumar <navneetk@nvidia.com>
>
> Allow creating identity and DMA API compatible IOMMU domains. When
> creating a DMA API compatible domain, make sure to also create the
> required cookie.
Nit: this description is now confusingly outdated.
> Signed-off-by: Navneet Kumar <navneetk@nvidia.com>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> Changes in v5:
> - remove DMA cookie initialization that's now no longer needed
>
> drivers/iommu/tegra-smmu.c | 38 +++++++++++++++++++++-----------------
> 1 file changed, 21 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> index 57b4f2b37447..7ad993330634 100644
> --- a/drivers/iommu/tegra-smmu.c
> +++ b/drivers/iommu/tegra-smmu.c
> @@ -20,6 +20,8 @@
> #include <soc/tegra/ahb.h>
> #include <soc/tegra/mc.h>
>
> +#include "dma-iommu.h"
> +
> struct tegra_smmu_group {
> struct list_head list;
> struct tegra_smmu *smmu;
> @@ -277,7 +279,9 @@ static struct iommu_domain *tegra_smmu_domain_alloc(unsigned type)
> {
> struct tegra_smmu_as *as;
>
> - if (type != IOMMU_DOMAIN_UNMANAGED)
> + if (type != IOMMU_DOMAIN_UNMANAGED &&
> + type != IOMMU_DOMAIN_DMA &&
> + type != IOMMU_DOMAIN_IDENTITY)
Since there's apparently no actual handling of IOMMU_DOMAIN_IDENTITY
being added anywhere, AFAICS it's still going to set up an address space
for translation with nothing mapped in its pagetable, which is pretty
much the opposite of what's required :/
> return NULL;
>
> as = kzalloc(sizeof(*as), GFP_KERNEL);
> @@ -287,25 +291,16 @@ static struct iommu_domain *tegra_smmu_domain_alloc(unsigned type)
> as->attr = SMMU_PD_READABLE | SMMU_PD_WRITABLE | SMMU_PD_NONSECURE;
>
> as->pd = alloc_page(GFP_KERNEL | __GFP_DMA | __GFP_ZERO);
> - if (!as->pd) {
> - kfree(as);
> - return NULL;
> - }
> + if (!as->pd)
> + goto free_as;
>
> as->count = kcalloc(SMMU_NUM_PDE, sizeof(u32), GFP_KERNEL);
> - if (!as->count) {
> - __free_page(as->pd);
> - kfree(as);
> - return NULL;
> - }
> + if (!as->count)
> + goto free_pd_range;
>
> as->pts = kcalloc(SMMU_NUM_PDE, sizeof(*as->pts), GFP_KERNEL);
> - if (!as->pts) {
> - kfree(as->count);
> - __free_page(as->pd);
> - kfree(as);
> - return NULL;
> - }
> + if (!as->pts)
> + goto free_pts;
Nit: all this part is now just unrelated refactoring.
Thanks,
Robin.
>
> spin_lock_init(&as->lock);
>
> @@ -315,6 +310,15 @@ static struct iommu_domain *tegra_smmu_domain_alloc(unsigned type)
> as->domain.geometry.force_aperture = true;
>
> return &as->domain;
> +
> +free_pts:
> + kfree(as->pts);
> +free_pd_range:
> + __free_page(as->pd);
> +free_as:
> + kfree(as);
> +
> + return NULL;
> }
>
> static void tegra_smmu_domain_free(struct iommu_domain *domain)
> @@ -1012,7 +1016,7 @@ static const struct iommu_ops tegra_smmu_ops = {
> .probe_device = tegra_smmu_probe_device,
> .release_device = tegra_smmu_release_device,
> .device_group = tegra_smmu_device_group,
> - .get_resv_regions = of_iommu_get_resv_regions,
> + .get_resv_regions = iommu_dma_get_resv_regions,
> .of_xlate = tegra_smmu_of_xlate,
> .pgsize_bitmap = SZ_4K,
> .default_domain_ops = &(const struct iommu_domain_ops) {
next prev parent reply other threads:[~2022-10-07 13:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 12:35 [PATCH v9 0/5] iommu: Support mappings/reservations in reserved-memory regions Thierry Reding
2022-09-23 12:35 ` [PATCH v9 1/5] dt-bindings: reserved-memory: Document iommu-addresses Thierry Reding
2022-10-07 13:45 ` Robin Murphy
2022-10-07 13:54 ` Thierry Reding
2022-10-07 14:21 ` Robin Murphy
2022-10-07 15:22 ` Thierry Reding
2022-10-07 16:25 ` Robin Murphy
2022-09-23 12:35 ` [PATCH v9 2/5] iommu: Implement of_iommu_get_resv_regions() Thierry Reding
2022-10-07 13:47 ` Robin Murphy
2022-10-07 15:28 ` Thierry Reding
2022-10-07 16:35 ` Robin Murphy
2022-10-19 18:03 ` Thierry Reding
2022-10-20 14:34 ` Thierry Reding
2022-09-23 12:35 ` [PATCH v9 3/5] iommu: dma: Use of_iommu_get_resv_regions() Thierry Reding
2022-09-23 12:35 ` [PATCH v9 4/5] iommu/tegra-smmu: Add support for reserved regions Thierry Reding
2022-09-23 12:35 ` [PATCH v9 5/5] iommu/tegra-smmu: Support managed domains Thierry Reding
2022-10-07 13:48 ` Robin Murphy [this message]
2022-10-07 15:40 ` Thierry Reding
2022-10-07 12:51 ` [PATCH v9 0/5] iommu: Support mappings/reservations in reserved-memory regions Thierry Reding
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=b541eb50-fd9d-1105-4ae1-640ec7df1c68@arm.com \
--to=robin.murphy@arm.com \
--cc=alyssa.rosenzweig@collabora.com \
--cc=asahi@lists.linux.dev \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.osipenko@collabora.com \
--cc=iommu@lists.linux-foundation.org \
--cc=j@jannau.net \
--cc=joro@8bytes.org \
--cc=linux-tegra@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=robh+dt@kernel.org \
--cc=spujar@nvidia.com \
--cc=thierry.reding@gmail.com \
--cc=vdumpa@nvidia.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).