From: Mostafa Saleh <smostafa@google.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Daniel Mentz <danielmentz@google.com>,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
Will Deacon <will@kernel.org>,
Pranjal Shrivastava <praan@google.com>,
Liviu Dudau <liviu.dudau@arm.com>,
Rob Clark <robin.clark@oss.qualcomm.com>
Subject: Re: [PATCH 2/2] drivers/arm-smmu-v3: Implement .iotlb_sync_map callback
Date: Mon, 29 Sep 2025 12:24:28 +0000 [thread overview]
Message-ID: <aNp6fJNoehs8hMyF@google.com> (raw)
In-Reply-To: <20250929115803.GF2617119@nvidia.com>
On Mon, Sep 29, 2025 at 08:58:03AM -0300, Jason Gunthorpe wrote:
> On Sat, Sep 27, 2025 at 10:39:53PM +0000, Daniel Mentz wrote:
> > @@ -3700,6 +3713,7 @@ static const struct iommu_ops arm_smmu_ops = {
> > .map_pages = arm_smmu_map_pages,
> > .unmap_pages = arm_smmu_unmap_pages,
> > .flush_iotlb_all = arm_smmu_flush_iotlb_all,
> > + .iotlb_sync_map = arm_smmu_iotlb_sync_map,
>
> Shouldn't this avoid defining the op on coherent systems?
Does that mean we need to have 2 iommu_ops, one for
coherent/non-coherent SMMUs, as both can be mixed in the same system.
The current implementation would skip the page table call on coherent
SMMUs, As in the first patch it only sets the pointer for them:
.iotlb_sync_map = cfg->coherent_walk ? NULL : arm_lpae_iotlb_sync_map.
Thanks,
Mostafa
>
> Jason
next prev parent reply other threads:[~2025-09-29 12:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-27 22:39 [PATCH 1/2] iommu/io-pgtable-arm: Implement .iotlb_sync_map callback Daniel Mentz
2025-09-27 22:39 ` [PATCH 2/2] drivers/arm-smmu-v3: " Daniel Mentz
2025-09-29 11:58 ` Jason Gunthorpe
2025-09-29 12:24 ` Mostafa Saleh [this message]
2025-09-29 12:47 ` Jason Gunthorpe
2025-09-30 0:23 ` Pranjal Shrivastava
2025-09-30 9:27 ` Mostafa Saleh
2025-09-30 14:56 ` Pranjal Shrivastava
2025-09-29 12:25 ` Mostafa Saleh
2025-09-29 12:21 ` [PATCH 1/2] iommu/io-pgtable-arm: " Mostafa Saleh
2025-09-29 21:00 ` Daniel Mentz
2025-09-30 9:10 ` Mostafa Saleh
2025-11-04 13:28 ` Will Deacon
2025-11-04 13:37 ` Jason Gunthorpe
2025-09-29 19:57 ` Pranjal Shrivastava
2025-09-29 20:42 ` Daniel Mentz
2025-09-29 22:24 ` Pranjal Shrivastava
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=aNp6fJNoehs8hMyF@google.com \
--to=smostafa@google.com \
--cc=danielmentz@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liviu.dudau@arm.com \
--cc=praan@google.com \
--cc=robin.clark@oss.qualcomm.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