On Wed, Jul 09, 2025 at 06:50:02PM +0200, Arnd Bergmann wrote:
On Wed, Jul 9, 2025, at 18:26, Jason Gunthorpe wrote:
On Wed, Jul 09, 2025 at 04:14:26PM +0530, Naresh Kamboju wrote:
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?
My guess would be that this bug is specific to this SoC running in 32-bit mode.
Sorry, it was unclear.
This driver always uses the ARM page table format with 64 bit entries. It uses the ARM_32_LPAE_S1 sub-flavour of it.
This is different from the ARM page table format with 32 bit entries called ARM_V7S. Only this format uses the 'SZ_4K | SZ_64K | SZ_1M | SZ_16M' bitmap.
Looking more closely when a driver selects ARM_32_LPAE_S1 it calls arm_32_lpae_alloc_pgtable_s1() which does:
cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);
So the 1 line patch looks OKish (maybe drop the SZ_2M to be conservative), despite putting it in the bitmap 64K would have never be used in the iommu no matter what the CPU is doing.
Jason