Hi James,

On 10/17/25 19:56, James Morse wrote:

When CPUs come online the MSC's original configuration should be restored.

Add struct mpam_config to hold the configuration. This has a bitmap of
features that were modified. Once the maximum partid is known, allocate
a configuration array for each component, and reprogram each RIS
configuration from this.

CC: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
Tested-by: Fenghua Yu <fenghuay@nvidia.com>
---
Changes since v2:
 * Call mpam_init_reset_cfg() on alloated config as 0 is not longer correct.
 * init_garbage() on each config - the array has to be freed in one go, but
   otherwise this looks weird.
 * Use struct initialiser in mpam_init_reset_cfg(),
 * Moved int err definition.
 * Removed srcu lock taking based on squinting at the only caller.
 * Moved config reset to mpam_reset_component_cfg() for re-use in
   mpam_reset_component_locked(), previous memset() was not enough since zero
   no longer means reset.

[...]

 
+struct reprogram_ris {
+	struct mpam_msc_ris *ris;
+	struct mpam_config *cfg;
+};
+
+/* Call with MSC lock held */
+static int mpam_reprogram_ris(void *_arg)
+{
+	u16 partid, partid_max;
+	struct reprogram_ris *arg = _arg;
+	struct mpam_msc_ris *ris = arg->ris;
+	struct mpam_config *cfg = arg->cfg;
+
+	if (ris->in_reset_state)
+		return 0;
+
+	spin_lock(&partid_max_lock);
+	partid_max = mpam_partid_max;
+	spin_unlock(&partid_max_lock);
+	for (partid = 0; partid <= partid_max + 1; partid++)

Loop overrun. This was correct in the previous version of the patch and
the same shape of loop is done correctly elsewhere in this version. I
think it would be good to standardise on using either:
partid <= partid_max
or
partid < partid_max + 1
I have a preference for the first as you don't need to think about the
size of the type.

-- 
Thanks,

Ben