Thread (21 messages) 21 messages, 3 authors, 2021-08-09

Re: [PATCH RFC v1 3/7] rtw88: Use rtw_iterate_stas where the iterator reads or writes registers

From: Johannes Berg <johannes@sipsolutions.net>
Date: 2021-07-19 06:36:19
Also in: lkml, netdev

On Sat, 2021-07-17 at 22:40 +0200, Martin Blumenstingl wrote:
quoted hunk ↗ jump to hunk
--- a/drivers/net/wireless/realtek/rtw88/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
@@ -721,7 +721,7 @@ static void rtw_ra_mask_info_update(struct rtw_dev *rtwdev,
 	br_data.rtwdev = rtwdev;
 	br_data.vif = vif;
 	br_data.mask = mask;
-	rtw_iterate_stas_atomic(rtwdev, rtw_ra_mask_info_update_iter, &br_data);
+	rtw_iterate_stas(rtwdev, rtw_ra_mask_info_update_iter, &br_data);
And then you pretty much immediately break that invariant here, namely
that you're calling this within the set_bitrate_mask() method called by
mac80211.

That's not actually fundamentally broken today, but it does *severely*
restrict what we can do in mac80211 wrt. locking, and I really don't
want to keep the dozen or so locks forever, this needs simplification
because clearly we don't even know what should be under what lock.

So like I said on the other patch, I don't have a fundamental objection
to taking such a patch, but the locking mess that this gets us into is
something I'd rather not have.

Maybe just don't support set_bitrate_mask for SDIO drivers for now?

The other cases look OK, it's being called from outside contexts
(wowlan, etc.)

johannes
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help