Hi Jason,
On 09 Sep 2025 12:58, Jason Gunthorpe wrote:
> On Tue, Sep 09, 2025 at 08:46:00AM -0700, Shyam Saini wrote:
> > Both ARM SMMU v2/v3 drivers have common set operations for
> > arm_smmu_get_resv_regions(), except iommu_dma_get_resv_regions()
> > call all other operations can be clubed into common code block.
> > So to avoid code duplication put common operations in a new helper
> > function iommu_set_sw_msi() and call this helper function from
> > arm_smmu_get_resv_regions() instead.
> >
> > Suggested-by: Jason Gunthorpe <j...@ziepe.ca>
> > Signed-off-by: Shyam Saini <shyamsa...@linux.microsoft.com>
> > ---
> > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 26 ++-------------
> > drivers/iommu/arm/arm-smmu/arm-smmu.c | 24 ++-----------
> > drivers/iommu/iommu.c | 37 +++++++++++++++++++++
> > include/linux/iommu.h | 6 ++++
> > 4 files changed, 47 insertions(+), 46 deletions(-)
>
> I would do this first, not after you made all the changes to both
> drivers.
>
> And then once you do it:
>
> > - static const u64 msi_bases[] = { MSI_IOVA_BASE, MSI_IOVA_BASE2 };
>
> Can just be constants written here, nothing else in the kernel should
> refer to them any more because they are dynamic. The only way to learn
> the value is to read the IOMMU_RESV_SW_MSI. Thus don't write them out
> in public headers to prevent mis-use.
I wil address these in the next version.
> I'm comfortable with this side from the iommu perspective once you get
> agreement on the DT representation.
We haven’t heard back from the DT folks or Thierry. Do you think we
should wait a few more days for their feedback, or go ahead and send
v5 as an RFC instead?
Thanks,
Shyam
