Hi Ben,

On 2025/10/23 0:17, Ben Horgan wrote:

quoted

Also fix the handling of overflow amount calculation. There's no need to
subtract mbwu_state->prev_val when calculating overflow_val.

Why not? Isn't this the pre-overflow part that we are missing from the
running count?

The MSMON_MBWU register accumulates counts monotonically forward and
would not automatically cleared to zero on overflow.

The overflow portion is exactly what mpam_msmon_overflow_val() computes,
there is no need to additionally subtract mbwu_state->prev_val.

quoted

Signed-off-by: Zeng Heng <redacted>
---
  drivers/resctrl/mpam_devices.c | 8 +++++---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
index 0dd048279e02..06f3ec9887d2 100644
--- a/drivers/resctrl/mpam_devices.c
+++ b/drivers/resctrl/mpam_devices.c

@@ -1101,7 +1101,8 @@ static void __ris_msmon_read(void *arg)
  	clean_msmon_ctl_val(&cur_ctl);
  	gen_msmon_ctl_flt_vals(m, &ctl_val, &flt_val);
  	config_mismatch = cur_flt != flt_val ||
-			  cur_ctl != (ctl_val | MSMON_CFG_x_CTL_EN);
+			 (cur_ctl & ~MSMON_CFG_x_CTL_OFLOW_STATUS) !=
+			 (ctl_val | MSMON_CFG_x_CTL_EN);

This only considers 31 bit counters. I would expect any change here to
consider all lengths of counter. Also, as the overflow bit is no longer
reset due to the config mismatch it needs to be reset somewhere else.

Yes, overflow bit needs to be cleared somewhere. I try to point out in
the next patch mail.

Best Regards,
Zeng Heng