On Thu, Jun 19, 2025 at 03:53:25PM -0300, Jason Gunthorpe wrote:
> On Thu, Jun 19, 2025 at 11:47:24AM +0000, Pranjal Shrivastava wrote:
> > I'm not sure if I get this right.. if the user (while porting a VMM or
> > something) mistakenly passes *type == IOMMU_HW_INFO_TYPE_INTEL_VTD here,
> > they'll get impl-specific info?
>
> It should call the impl hw_info which should fail?
>
> +static void *tegra241_cmdqv_hw_info(struct arm_smmu_device *smmu, u32
> *length,
> + u32 *type)
> +{
> + if (*type != IOMMU_HW_INFO_TYPE_TEGRA241_CMDQV)
> + return ERR_PTR(-EOPNOTSUPP);
>
> If impl ops is null/etc then it fails:
>
> + if (!impl_ops || !impl_ops->hw_info)
> + return ERR_PTR(-EOPNOTSUPP);
>
> Where does IOMMU_HW_INFO_TYPE_INTEL_VTD return something?
>
I mean, the check in the driver (for e.g. arm-smmu-v3) is:
if (*type != IOMMU_HW_INFO_TYPE_DEFAULT &&
*type != IOMMU_HW_INFO_TYPE_ARM_SMMUV3)
// call impl_ops
My point is that in-case someone passed INTEL_VTD type, we would end up
calling impl_ops->hw_info and then the impl_ops->hw_info shall check for
the type to return -EOPNOTSUPP. Either we should clearly mention that
each impl_op implementing hw_info *must* add another type and check for
it OR we could have sub-types for implementations extending a main type
somehow?
> > I agree in that case the impl-specific
> > driver needs to check the type, but shouldn't we simply return from here
> > itself if the type isn't arm-smmu-v3?
>
> Then how do you return IOMMU_HW_INFO_TYPE_TEGRA241_CMDQV?
>
The current version is just fine with a doc string mentioning type
checks within impl_ops->hw_info OR we could have sub-types for
implementations extending some architectural IOMMU.
I'm just trying to avoid weird bug reports in the future because some
impl didn't check for their type.
> Jason
Thanks
Praan
