Messages in this thread | | | Date | Mon, 14 Nov 2022 13:50:58 +0000 | From | Will Deacon <> | Subject | Re: [PATCH v2] iommu/arm-smmu-v3: Restore prints in arm_smmu_attach_dev() |
| |
On Wed, Nov 09, 2022 at 10:46:36AM -0800, Nicolin Chen wrote: > The prints for incompatible failures in arm_smmu_attach_dev() might be > still useful for error diagnosis. As VFIO and IOMMUFD would do testing > attach() call, having previous dev_err() isn't ideal either. > > Add the prints back using dev_dbg(). > > Fixes: f4a147735793 ("iommu: Use EINVAL for incompatible device/domain in ->attach_dev") > Suggested-by: Will Deacon <will@kernel.org> > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> > Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> > --- > Changelog > v1->v2: > * Add "Fixes" line and Reviewed-by from Jason > > drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > index ab160198edd6..076d3710b1fe 100644 > --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c > @@ -2433,14 +2433,21 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) > goto out_unlock; > } > } else if (smmu_domain->smmu != smmu) { > + dev_dbg(dev, "cannot attach to SMMU %s (upstream of %s)\n", > + dev_name(smmu_domain->smmu->dev), dev_name(smmu->dev)); > ret = -EINVAL; > goto out_unlock; > } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 && > master->ssid_bits != smmu_domain->s1_cfg.s1cdmax) { > + dev_dbg(dev, > + "cannot attach to incompatible domain (%u SSID bits != %u)\n", > + smmu_domain->s1_cfg.s1cdmax, master->ssid_bits); > ret = -EINVAL; > goto out_unlock; > } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 && > smmu_domain->stall_enabled != master->stall_enabled) { > + dev_dbg(dev, "cannot attach to stall-%s domain\n", > + smmu_domain->stall_enabled ? "enabled" : "disabled"); > ret = -EINVAL; > goto out_unlock;
Thanks!
Acked-by: Will Deacon <will@kernel.org>
Will
| |