Re: [PATCH 2/2] wifi: ath10k: Removed atomic iteration in bitrate mask clear.

[Jeff Johnson <jeff.johnson@oss.qualcomm.com>]

On 8/5/24 17:40, Rory Little wrote:
> This operation requires some blocking calls, which causes issues when
> attempting to guard this iteration's critical section with an RCU lock.
> Instead, we will take advantage of the held wiphy mutex to protect this
> operation.
> 
> Signed-off-by: Rory Little <rory@candelatech.com>
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 7579a1cd7d15..a1a13b9ad465 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -9502,9 +9502,9 @@ static int ath10k_mac_op_set_bitrate_mask(struct ieee80211_hw *hw,
>  			     ar->normal_mode_fw.fw_file.fw_features);
>  	if (allow_pfr) {
>  		mutex_lock(&ar->conf_mutex);
> -		ieee80211_iterate_stations_atomic(ar->hw,
> -						  ath10k_mac_clr_bitrate_mask_iter,
> -						  arvif);
> +		ieee80211_iterate_stations_mtx(ar->hw,
> +					       ath10k_mac_clr_bitrate_mask_iter,
> +					       arvif);
>  		mutex_unlock(&ar->conf_mutex);
>  	}
>  

+ ath10k list

This was deferred back when Kalle was maintainer, and I'm now revisiting the backlog.
Is this still needed? And if so, is there a reason why the other instance of
ieee80211_iterate_stations_atomic() (which sets the mask) does not need to be
modified?

/jeff