On Wed, Jul 15, 2026 at 07:41:50PM +0000, Pranjal Shrivastava wrote:
quoted
@@ -2446,9 +2446,10 @@ static void arm_smmu_cmdq_batch_add_range(struct arm_smmu_device *smmu,
/* Determine how many chunks of 2^scale size we have */
num = (num_pages >> scale) & CMDQ_TLBI_RANGE_NUM_MAX;
+ /* Keep the pre-DS 5-bit truncation when scale > 31 */
cmd->data[0] = orig_data0 |
FIELD_PREP(CMDQ_TLBI_0_NUM, num - 1) |
- FIELD_PREP(CMDQ_TLBI_0_SCALE, scale);
+ FIELD_PREP(CMDQ_TLBI_0_SCALE, scale & 0x1f);
Nit: Not sure what the convention is for these things, but this cap for
host is temporary as Jason's iommupt series expands the scale when DS=1.
I'm not sure if we should note a TODO here or just leave it be for now?
That kind of looks like an existing bug.. Technically it looks like a
very large invalidation could be created that can overflow scale and
break this algorithm. Adding the 0x1f at least keeps this as 'no
change': broken under invalidation, but not broken malformed command..
Let's just leave it like above, my series fixes that little miss too:
scale = fls64((num_tg - 1) / 32);
if (scale > scale_max) {
/*
* Range too large for a single command, use full invalidation.
*/
tlbi->range.use_full_inv = true;
return;
}
Jason