|SUCCESS| bus/fslmc: fix shadowed variables in queue storage macros

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/162886

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-04-07

commit af625d3e892104f4a5c8b2e1d7c9a3b8e4f7d6c2
Author: Weijun Pan <wpan36 at wisc.edu>

bus/fslmc: fix shadowed variables in queue storage macros

This patch renames local variables in the dpaa2_queue_storage_alloc()
and dpaa2_queue_storage_free() macros to avoid shadowing warnings.

> diff --git a/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h b/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
> index e625a5c035..bbeccd8fc3 100644
> --- a/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
> +++ b/drivers/bus/fslmc/portal/dpaa2_hw_pvt.h
> @@ -204,33 +204,33 @@ struct swp_active_dqs {
>  
>  #define dpaa2_queue_storage_alloc(q, num) \
>  ({ \
> -	int ret = 0, i; \
> +	int qs_ret = 0, qs_idx; \

Does this declaration follow the coding style guideline for variable
declarations? The coding style requires each variable be declared on a
separate line unless the declarations are related or similar in purpose.
Should this be:

	int qs_ret = 0; \
	int qs_idx; \

> @@ -204,33 +204,33 @@ struct swp_active_dqs {
>  
>  #define dpaa2_queue_storage_alloc(q, num) \
>  ({ \
> -	int ret = 0, i; \
> +	int qs_ret = 0, qs_idx; \
>  	\
> -	for (i = 0; i < (num); i++) { \
> -		(q)->q_storage[i] = rte_zmalloc(NULL, \
> +	for (qs_idx = 0; qs_idx < (num); qs_idx++) { \
> +		(q)->q_storage[qs_idx] = rte_zmalloc(NULL, \
>  			sizeof(struct queue_storage_info_t), \
>  			RTE_CACHE_LINE_SIZE); \
> -		if (!(q)->q_storage[i]) { \
> -			ret = -ENOBUFS; \
> +		if (!(q)->q_storage[qs_idx]) { \
> +			qs_ret = -ENOBUFS; \
>  			break; \
>  		} \
> -		ret = dpaa2_alloc_dq_storage((q)->q_storage[i]); \
> -		if (ret) \
> +		qs_ret = dpaa2_alloc_dq_storage((q)->q_storage[qs_idx]); \
> +		if (qs_ret) \

Does this code leak memory when dpaa2_alloc_dq_storage() fails? When
this failure occurs, the previously allocated rte_zmalloc() memory at
(q)->q_storage[qs_idx] has not been freed before breaking out of the
loop. On the allocation failure path, should there be a call to
rte_free((q)->q_storage[qs_idx]) before the break?

Additionally, when the break occurs at any iteration, does this code
leak the q_storage entries allocated in previous loop iterations?
Should dpaa2_queue_storage_free() be called to clean up on failure?

[ ... ]