Re: [PATCH v17 net-next 4/8] octeontx2-af: npc: cn20k: add subbank search order control

[Ratheesh Kannoth <rkannoth@marvell.com>]

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

>> +	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.

>> +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