diff mbox series

rtw88: set WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL, mac80211 supports it

Message ID 20200213050819.13467-1-yhchuang@realtek.com (mailing list archive)
State Rejected
Delegated to: Kalle Valo
Headers show
Series rtw88: set WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL, mac80211 supports it | expand

Commit Message

Tony Chuang Feb. 13, 2020, 5:08 a.m. UTC 
From: Yan-Hsuan Chuang <yhchuang@realtek.com>

Set wiphy flag WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL, because mac80211
actually supports it. With the flag set, driver can accept ROC
event from wpa_supplicant or some other user space tools.

Do note that driver is most used to run a station mode vif and is
using sw_scan instead of use_chan_ctx. So, if the driver is going
to use chan_ctx or hw_scan, must make sure that ROC can work.

Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
---
 drivers/net/wireless/realtek/rtw88/main.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Arend Van Spriel Feb. 13, 2020, 9:56 a.m. UTC | #1 
On 2/13/2020 6:08 AM, yhchuang@realtek.com wrote:
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
> 
> Set wiphy flag WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL, because mac80211
> actually supports it. With the flag set, driver can accept ROC
> event from wpa_supplicant or some other user space tools.

This does not seem right. mac80211 does set this flag itself when the 
driver provides remain_on_channel callback. Does that mean you already 
have that callback? This patch is either wrong or unnecessary.

Regards,
Arend
Arend Van Spriel Feb. 13, 2020, 10:02 a.m. UTC | #2 
On 2/13/2020 10:56 AM, Arend Van Spriel wrote:
> 
> 
> On 2/13/2020 6:08 AM, yhchuang@realtek.com wrote:
>> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>>
>> Set wiphy flag WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL, because mac80211
>> actually supports it. With the flag set, driver can accept ROC
>> event from wpa_supplicant or some other user space tools.
> 
> This does not seem right. mac80211 does set this flag itself when the 
> driver provides remain_on_channel callback. Does that mean you already 
> have that callback? This patch is either wrong or unnecessary.

Re-reading the commit message I guess it is ok to claim 
remain-on-channel support when using sw_scan. If this is true it seems 
better to extend the condition in ieee80211_alloc_hw_nm() for setting 
the flag.

Regards,
Arend
Tony Chuang Feb. 18, 2020, 8:01 a.m. UTC | #3 
> On 2/13/2020 10:56 AM, Arend Van Spriel wrote:
> >
> >
> > On 2/13/2020 6:08 AM, yhchuang@realtek.com wrote:
> >> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
> >>
> >> Set wiphy flag WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL, because
> mac80211
> >> actually supports it. With the flag set, driver can accept ROC
> >> event from wpa_supplicant or some other user space tools.
> >
> > This does not seem right. mac80211 does set this flag itself when the
> > driver provides remain_on_channel callback. Does that mean you already
> > have that callback? This patch is either wrong or unnecessary.
> 
> Re-reading the commit message I guess it is ok to claim
> remain-on-channel support when using sw_scan. If this is true it seems
> better to extend the condition in ieee80211_alloc_hw_nm() for setting
> the flag.
> 

It looks like we can set the flag in ieee80211_alloc_hw_nm(). Such as:
if (!use_chan_ctx || (use_chan_ctx && ops->remain_on_channel)).

Yan-Hsuan
diff mbox series

Patch

diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index 2845d2838f7b..38c77678fa5b 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -1484,6 +1484,7 @@  int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw)
 				     BIT(NL80211_IFTYPE_MESH_POINT);
 
 	hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS |
+			    WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL |
 			    WIPHY_FLAG_TDLS_EXTERNAL_SETUP;
 
 	hw->wiphy->features |= NL80211_FEATURE_SCAN_RANDOM_MAC_ADDR;