Re: [PATCH] arm_mpam: avoid hour-long timeout on invalid ACPI table entry
From: Srivathsa L Rao
Date: Tue Nov 03 2026 - 09:12:15 EST
Hi Andre,
On 11/2/2026 4:57 PM, Andre Przywara wrote:
The ACPI PCCT table contains a "nominal latency" field for the expected
maximum time it takes to handle a command in the PCC mailbox.
The generic ACPI code reads this value, but leaves the handling to the
protocol users.
For MPAM-Fb based MSC signalling, we use a value derived from that number
as the mailbox timeout. However if the ACPI table leaves this entry at 0,
the mailbox timeout code interprets this as "forever", and waits for one
hour.
Avoid that lengthy timeout and just add one microsecond to the read value,
to come up with a non-zero result in any case.
Found by Sashiko.
Fixes: cb351e3f304b ("arm_mpam: detect and enable MPAM-Fb PCC support")
Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
---
drivers/resctrl/mpam_devices.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
index c067b6d57d71e..fb596ed19a648 100644
--- a/drivers/resctrl/mpam_devices.c
+++ b/drivers/resctrl/mpam_devices.c
@@ -102,9 +102,9 @@ static struct mpam_pcc_chan *mpam_pcc_chan_get(struct device *dev,
/*
* Timeout based on the "nominal latency" in us, from the
* PCC ACPI table. tx_tout is in ms.
- * Add some margin here to be on the safe side.
+ * Add some margin here to be on the safe side, and avoid using 0.
*/
- cur->pcc_cl.tx_tout = DIV_ROUND_UP(cur->pcc_chan->latency * 5, 1000);
+ cur->pcc_cl.tx_tout = DIV_ROUND_UP((cur->pcc_chan->latency + 1) * 5, 1000);
Would an explicit floor, e.g max(DIV_ROUND_UP(latency * 5, 1000), MPAM_PCC_MIN_TIMEOUT_MS), with a comment, be better than "+ 1"? It also avoids the side effect on non-zero. Just a suggestion.>
mutex_init(&cur->pcc_chan_lock);
base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
Reviewed-by: Srivathsa L Rao <srivathsa.rao@xxxxxxxxxxxxxxxx>
Best Regards,
Srivathsa