Re: [PATCH v7 4/5] iommu: Use EINVAL for incompatible device/domain in ->attach_dev
From: Will Deacon <will@kernel.org>
Date: 2022-11-08 13:20:56
Also in:
linux-arm-msm, linux-iommu, linux-mediatek, linux-tegra, lkml, virtualization
On Mon, Nov 07, 2022 at 04:14:32PM -0800, Nicolin Chen wrote:
On Mon, Nov 07, 2022 at 03:26:45PM +0000, Will Deacon wrote:quoted
quoted
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 ba47c73f5b8c..01fd7df16cb9 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c@@ -2430,23 +2430,14 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev) goto out_unlock; } } else if (smmu_domain->smmu != smmu) { - dev_err(dev, - "cannot attach to SMMU %s (upstream of %s)\n", - dev_name(smmu_domain->smmu->dev), - dev_name(smmu->dev)); - ret = -ENXIO; + ret = -EINVAL; goto out_unlock; } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 && master->ssid_bits != smmu_domain->s1_cfg.s1cdmax) { - dev_err(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_err(dev, "cannot attach to stall-%s domain\n", - smmu_domain->stall_enabled ? "enabled" : "disabled"); ret = -EINVAL; goto out_unlock; }quoted
I think it would be helpful to preserve these messages using dev_err_ratelimited() so that attach failure can be diagnosed without having to hack the messages back into the driver.Thank you for the review. The change is already picked up last week. Yet, I can add prints back with a followup patch, if no one has a problem with that.
Sorry, I fell behind with upstream so I got to this late. A patch on top would be fantastic!
Also, I am not quite sure what the use case would be to have an error print. Perhaps dev_dbg() would be more fitting if it is just for diagnosis?
Sure, that works for me. I think the messages are useful for folks triggering this path e.g. via sysfs but if they're limited to debug I think that's better than removing them altogether. Cheers, Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel