[PATCH] arm_mpam: avoid hour-long timeout on invalid ACPI table entry

[Andre Przywara <andre.przywara@arm.com>]

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@arm.com>
---
 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);
 
 	mutex_init(&cur->pcc_chan_lock);
 

base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
-- 
2.43.0