[1/6,v3] wifi: ath10k: cleanup CE ring initialization

Commit 25d0dbcbd5c7 ("ath10k: split ce initialization and allocation")
changes 'ath10k_ce_init_src_ring()' and 'ath10k_ce_init_dest_ring()'
so these functions can't return -ENOMEM but always returns 0. This way
both of them may be converted to 'void', and 'ath10k_ce_init_pipe()'
may be simplified accordingly.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
---
v3: split to smaller units per Jeff's suggestion
v2: change 'ath10k_ce_alloc_rri()' to return -ENOMEM in case
of 'dma_alloc_coherent()' failure and fix error handling in
'ath10k_snoc_hif_power_up()'
---
 drivers/net/wireless/ath/ath10k/ce.c | 38 ++++++++--------------------
 1 file changed, 10 insertions(+), 28 deletions(-)

Dmitry Antipov <dmantipov@yandex.ru> writes:

> Commit 25d0dbcbd5c7 ("ath10k: split ce initialization and allocation")
> changes 'ath10k_ce_init_src_ring()' and 'ath10k_ce_init_dest_ring()'
> so these functions can't return -ENOMEM but always returns 0. This way
> both of them may be converted to 'void', and 'ath10k_ce_init_pipe()'
> may be simplified accordingly.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
> ---
> v3: split to smaller units per Jeff's suggestion
> v2: change 'ath10k_ce_alloc_rri()' to return -ENOMEM in case
> of 'dma_alloc_coherent()' failure and fix error handling in
> 'ath10k_snoc_hif_power_up()'

[...]

> -static int ath10k_ce_init_src_ring(struct ath10k *ar,
> -				   unsigned int ce_id,
> -				   const struct ce_attr *attr)
> +static void ath10k_ce_init_src_ring(struct ath10k *ar,
> +				    unsigned int ce_id,
> +				    const struct ce_attr *attr)

I have on purpose avoided to use void functions in ath10k/ath11k/ath12k.
The problem is that if some of the functions return void and some of the
functions return int it's much harder to review the code. If most/all of
the functions return the same error value type as int it makes a lot
easier to read the code.

Is there a benefit from function returning void? Why do this in the
first place?

On 9/20/23 16:23, Kalle Valo wrote:

> I have on purpose avoided to use void functions in ath10k/ath11k/ath12k.
> The problem is that if some of the functions return void and some of the
> functions return int it's much harder to review the code. 

I realize that you're constantly overloaded with reviewing a lot of patches...

> If most/all of the functions return the same error value type as int  > it makes a lot easier to read the code.

...but still not sure that this is reasonable for any non-trivial piece
of the source code.

OTOH if both you and Jeff are agreed on preserving existing ath1x style,
I will definitely take this decision into account and try to redesign
this series in attempt to fit the current design as much as possible.

Dmitry

Dmitry Antipov <dmantipov@yandex.ru> writes:

>> If most/all of the functions return the same error value type as int
>> it makes a lot easier to read the code.
>
> ...but still not sure that this is reasonable for any non-trivial piece
> of the source code.

What's the concrete benefit from having few functions which return void
instead of 'return 0'? For me the benefit would have to be significant
justifying the code churn and the time used.

> OTOH if both you and Jeff are agreed on preserving existing ath1x style,
> I will definitely take this decision into account and try to redesign
> this series in attempt to fit the current design as much as possible.

Please stop fixing the design (unless you are the driver maintainer or
asked specifically by one) as that doesn't really benefit anyone,
actually the opposite. Instead focus on fixing actual bugs. But if you
have no means for testing your fixes then stick to compiler warnings and
similar.

For example, didn't I suggest you about fixing all sparse warnings in
wireless code? I would be very happy to get such patches as we really
would want to be sparse warning free.