>> +static int nl80211_set_sta_mon(struct sk_buff *skb, struct genl_info
>> +*info) {
>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> + struct net_device *dev = info->user_ptr[1];
>> + struct nlattr *attrs[NL80211_ATTR_CQM_MAX + 1];
>> + bool fixed_thold = false;
>> + struct nlattr *sta_mon;
>> + u8 *addr = NULL;
>> + int err;
>> +
>> + if (!wiphy_ext_feature_isset(&rdev->wiphy,
>> +
>> NL80211_EXT_FEATURE_STA_MON_RSSI_CONFIG))
>> + return -EOPNOTSUPP;
>> +
>> + sta_mon = info->attrs[NL80211_ATTR_CQM];
>> + if (!sta_mon || !(info->attrs[NL80211_ATTR_MAC]))
>> + return -EINVAL;
>> +
>> + err = nla_parse_nested(attrs, NL80211_ATTR_CQM_MAX, sta_mon,
>> + nl80211_attr_cqm_policy, info->extack);
>> + if (err)
>> + return err;
>> +
>> + addr = nla_data(info->attrs[NL80211_ATTR_MAC]);
>> + fixed_thold =
>> +
>> + nla_get_flag(info->attrs[NL80211_ATTR_STA_MON_FIXED_THOLD]);
>> +
>> + if (attrs[NL80211_ATTR_CQM_RSSI_THOLD] &&
>> + attrs[NL80211_ATTR_CQM_RSSI_HYST]) {
>> + const s32 *thresholds =
>> + nla_data(attrs[NL80211_ATTR_CQM_RSSI_THOLD]);
>> + int len = nla_len(attrs[NL80211_ATTR_CQM_RSSI_THOLD]);
>> + u32 hysteresis =
>> + nla_get_u32(attrs[NL80211_ATTR_CQM_RSSI_HYST]);
>> +
>> + if (len % 4)
>> + return -EINVAL;
>> +
>> + err = nl80211_validate_rssi_tholds(thresholds, len / 4);
>> + if (err)
>> + return err;
>> +
>> + return rdev_set_sta_mon_rssi_config(rdev, dev, addr,
>> thresholds,
>> + hysteresis, len / 4,
>> + fixed_thold);
>> + }
>> +
>> + return -EINVAL;
>> +}
>IIUC there is a noticeable overlap between this new command and existing
>nl80211_set_cqm_rssi command. Is there any reason why >nl80211_set_cqm_rss can
>not be adapted for AP case ?
[Tamizh] This new command for AP mode introduced as per the previous
discussion.
>If there is a reason to handle AP case separately, then it looks like it makes
>sense to add explicit check for supported iftype in this new command.
>>Besides, it looks like there is no generic way to handle disabling of RSSI
>monitoring in the new command.
>As a result, we may end up in multiple driver specific implementations.
[Tamizh] thanks for pointing me out. I'll add the ifmode check in the next
patchset version.
Thanks,
Tamizh.
