Re: [PATCH v2 30/30] iommu: remove iova_to_phys from domain_ops and io_pgtable_ops

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The kerneldoc for `iommu_iova_to_phys_length()` is incorrectly updated to state it returns `0` on failure, contradicting its implementation and API contract.
- [Low] The commit breaks compilation of `drivers/iommu/vsi-iommu.c` because it removes the `.iova_to_phys` field from `struct iommu_domain_ops` but leaves its initialization in `vsi_iommu_ops`.
--

commit e371c2338468e326f04a98ffb8dd1fb18a2872a0
Author: Guanghui Feng <guanghuifeng@linux.alibaba.com>
iommu: remove iova_to_phys from domain_ops and io_pgtable_ops

This commit removes the deprecated iova_to_phys interfaces from both
iommu_domain_ops and io_pgtable_ops now that callers are expected to have
migrated to iova_to_phys_length. It drops the fallback path in
iommu_iova_to_phys_length() and updates its kerneldoc.

> Now that all drivers implement iova_to_phys_length and all callers
> have migrated, remove the deprecated interfaces:

[Severity: Low]
Does drivers/iommu/vsi-iommu.c still need to be migrated? It appears to still
initialize the removed .iova_to_phys field in vsi_iommu_ops, which would cause
a compilation error:

drivers/iommu/vsi-iommu.c:
static const struct iommu_domain_ops vsi_iommu_ops = {
	...
	.iova_to_phys		= vsi_iommu_iova_to_phys,
};

> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 1b1aaa53dd16a..84893d4c7c607 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2554,7 +2554,7 @@ EXPORT_SYMBOL_GPL(iommu_detach_group);
>   * Like iommu_iova_to_phys() but additionally returns the page size of the
>   * PTE mapping at @iova through @mapped_length.
>   *
> - * Return: The physical address for the given IOVA, or PHYS_ADDR_MAX if no translation.
> + * Return: The physical address for the given IOVA, or 0 if no translation.

[Severity: Medium]
Is this documentation update accurate?

The implementation of iommu_iova_to_phys_length() still returns
PHYS_ADDR_MAX when the domain ops lack the iova_to_phys_length callback:

	if (!domain->ops->iova_to_phys_length)
		return PHYS_ADDR_MAX;

Could misdocumenting this cause future driver authors to return 0 on
failure instead of PHYS_ADDR_MAX, potentially bypassing safety checks and
treating physical address 0 as a valid mapping?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602104637.1219810-1-guanghuifeng@linux.alibaba.com?part=30