On Wed, Jul 09, 2025 at 04:14:26PM +0530, Naresh Kamboju wrote:
I have tested this patch on top of Linux next-20250702 tag, and found kernel warning,
Oh, yeah, I guess that hacky fix is not going to work.
Then this is probably good enough (against linux-next):
--- a/drivers/iommu/arm/arm-smmu/qcom_iommu.c +++ b/drivers/iommu/arm/arm-smmu/qcom_iommu.c @@ -335,7 +335,7 @@ static struct iommu_domain *qcom_iommu_domain_alloc_paging(struct device *dev)
mutex_init(&qcom_domain->init_mutex); spin_lock_init(&qcom_domain->pgtbl_lock); - qcom_domain->domain.pgsize_bitmap = SZ_4K | SZ_64K | SZ_1M | SZ_16M; + qcom_domain->domain.pgsize_bitmap = SZ_4K | SZ_2M;
return &qcom_domain->domain; }
I believe the original text was a copy and pasto from an ARMv7s driver (ie the 32 bit ARM page table) which uses that unique combination of sizes. It is not a sane bitmap for HW with 64 bit page table support, there is never a 1M option for instance.
So this removes 64k page support, which maybe didn't even work?
I also prepared a proper rework that puts the pgtable allocation into the qcom_iommu_domain_alloc_paging(). I've attached it, but it is involved enough it probably breaks something else. However if you want to test it maybe we can progress it too.
Thanks, Jason