Hi, On 5 January 2017 at 06:49, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Wed, 2017-01-04 at 15:19 -0500, Andrew Zaborowski wrote: >> On 4 January 2017 at 10:53, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> >> wrote: >> > Thus, you either need an nl80211 protocol feature bit (enum >> > nl80211_protocol_features) or a new attribute, or so, I think. >> >> True, I'd assumed that netlink would check for exact attribute length >> with NLA_S32. >> >> I'll add the feature bit but I wonder if it's better as a >> driver/device feature (enum nl80211_ext_feature_index) so that it can >> take into account whether rdev->set_cqm_rssi_range_config is set. > > Well, it's even more complicated than that because mac80211 may have > the callback but still not be able to support it, with filtering, > perhaps? Not quite sure now. With the basic mac80211 implementation in my patch 4/4 this feature should be set when IEEE80211_VIF_BEACON_FILTER is not set. The problem with a nl80211_ext_feature is that it's per wiphy instead of per interface. So in the case mac80211, it would need to be set if all interfaces can accept lists of thresholds and that can change dynamically as interfaces are added. And nl80211 has no per-interface features. I wonder if it's better to add a ieee80211_hw_flags flag to advertise this feature per wiphy, or, as an approximation, set the flag based on the default interface that is created in ieee80211_register_hw. Best regards
