> Signed-off-by: Tamizh chelvam <tamizhr@xxxxxxxxxxxxxx>
> ---
> include/net/cfg80211.h | 28 +++++++++
> include/uapi/linux/nl80211.h | 18 ++++++
> net/wireless/nl80211.c | 131 +++++++++++++++++++++++++++++++++++++-----
> net/wireless/rdev-ops.h | 18 ++++++
> 4 files changed, 181 insertions(+), 14 deletions(-)
...
> +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 ?
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.
Regards,
Sergey
