On 2026-06-01 at 08:28:39, Ratheesh Kannoth (rkannoth@marvell.com) wrote:

quoted

+	enum {
+		FREE = 0,
+		USED = 1,
+	};
+
+	if (cnt != npc_priv.num_subbanks) {
+		dev_err(rvu->dev, "Number of entries(%u) != %u\n",
+			cnt, npc_priv.num_subbanks);
+		return -EINVAL;
+	}
+
+	mutex_lock(&mcam->lock);
+	npc_lock_all_subbank();

This is a pre-existing issue, but does calling npc_lock_all_subbank()
here trigger a lockdep splat?

Need to use nested lock or lockdep_off() to supress this. Since this is preexistig issue
will post a seperate fix patch after this series is merged.

quoted

+const u32 *npc_cn20k_search_order_get(bool *restricted_order, u32 *sz)
+{
+	*restricted_order = restrict_valid;
+	*sz = npc_priv.num_subbanks;
+	return subbank_srch_order;
+}

This is a pre-existing issue, but does the getter return an array that
differs from the actual hardware mapping initialized earlier?
During driver initialization, npc_create_srch_order() creates an array
mapping priority to subbank index. However, npc_subbank_init() accesses
it as sb->arr_idx = subbank_srch_order[idx], treating the same array as
mapping subbank index to priority.
The new devlink getter returns the raw subbank_srch_order array, while
the setter applies it correctly as sb->arr_idx = prio.
Because the initial hardware state does not match the getter output,
will a user-space application performing a devlink get followed by a
set with the exact same array silently flip the hardware priorities from
the inverted order to the intended order?

Preexisting issue, will be addressed as a patch to net tree after the series
is merged