IOMMU probe deferral support
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest posting 2/20 of 8 patches 0 repliesNew
- v3 posting 1/20 of 8 patches 0 repliesSuperseded
Patches in v3 posting 2/2 No applies recorded yet
None of the 8 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v3 yet.
Cover letter [PATCH V3 0/8] IOMMU probe deferral support
Quoted 23 lines · Sricharan
Quoted 15 lines
drivers/iommu/arm-smmu.c static struct iommu_group *arm_smmu_device_group(struct device *dev) · line 1521
Quoted 12 lines
drivers/iommu/arm-smmu.c +2
-1@@ -1516,8 +1516,10 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev) group = smmu->s2crs[idx].group; } -if (group) +if (group) { +iommu_group_get_by_id (iommu_group_id (group));return group;This might as well just be inline, i.e.:
Quoted 7 lines
return iommu_group_get_by_id(iommu_group_id(group));It's a shame we have to go all round the houses when we have the group right there, but this is probably the most expedient fix. I guess we can extend the API with some sort of
iommu_group_get(group)overload in future if we really want to.
Quoted 4 lines
ok, i can send this fix separately then. Otherwise, Will was suggesting on the other thread that there should probably be a separate API to increment the group refcount or get the group from the existing aliasing device. As per me adding the api, looks like another option or post the above ?
I think adding a new function to the API is the way to go -- having code like what you propose above littered around the drivers is hard to read and pretty error-prone, since it looks like a NOP to people who aren't already thinking about ref counts.
Will