[PATCH 2/2] wifi: ath10k: Removed atomic iteration in bitrate mask clear.
Jeff Johnson
jeff.johnson at oss.qualcomm.com
Wed Oct 22 10:59:15 PDT 2025
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 at 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
More information about the ath10k
mailing list