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 |
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
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
> 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 --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;