From: Johannes Berg <johannes@sipsolutions.net>
To: Dmitry Tarnyagin <abi.dmitryt@gmail.com>
Cc: linux-wireless@vger.kernel.org,
Bartosz MARKOWSKI <bartosz.markowski@tieto.com>,
Janusz DZIEDZIC <janusz.dziedzic@tieto.com>
Subject: Re: [RFC 02/07] compat-wireless: Connection quality monitor extensions
Date: Wed, 12 Oct 2011 10:21:17 +0200 [thread overview]
Message-ID: <1318407677.3933.18.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <op.v27rulkhya27un@edmitar> (sfid-20111012_030243_875021_0262D42B)
On Wed, 2011-10-12 at 03:02 +0200, Dmitry Tarnyagin wrote:
> added:
> * beacon miss threshold - This value specifies the threshold
> for the BEACON loss level
> * tx fail - This value specifies the threshold for the TX loss level
That's a bit short for a changelog for such a big patch. The patch might
stand to be split up into two and be explained better.
Also, as Julian pointed out -- get your compat vs. wireless tree in
order. You don't want to be modifying the compat repository, it's even
impossible, you need to be submitting patches against wireless-next or
-testing. You also need to make sure they apply against those trees,
which this patch obviously can't:
> include/linux/compat-3.0.h | 2 +
as you can see easily :)
> +++ b/include/linux/nl80211.h
> @@ -2311,6 +2311,14 @@ enum nl80211_ps_state {
> * @NL80211_ATTR_CQM_RSSI_THRESHOLD_EVENT: RSSI threshold event
> * @NL80211_ATTR_CQM_PKT_LOSS_EVENT: a u32 value indicating that this many
> * consecutive packets were not acknowledged by the peer
> + * @NL80211_ATTR_CQM_BEACON_MISS_THOLD: BEACON threshold. This value
> specifies
> + * the threshold for the BEACON loss level at which an event will be
> + * sent. Zero to disable.
Should it really be zero to disable rather than leaving it out to
disable?
> + * @NL80211_ATTR_CQM_BEACON_MISS_THOLD_EVENT: BEACON miss event
> + * @NL80211_ATTR_CQM_TX_FAIL_THOLD: TX threshold. This value specifies the
> + * the threshold for the TX loss level at which an event will be
> + * sent. Zero to disable.
> + * @NL80211_ATTR_CQM_TX_FAIL_THOLD_EVENT: TX threshold event
How's this not the same as PKT_LOSS_EVENT?
Some advertising for whether this is supported or not is necessary.
> +++ b/include/net/mac80211.h
Again a fairly complex patch modifying both cfg80211 and mac80211 -- not
good. Keep in mind that there are in fact drivers not using mac80211.
> @@ -244,6 +244,10 @@ enum ieee80211_rssi_event {
> * @cqm_rssi_thold: Connection quality monitor RSSI threshold, a zero
> value
> * implies disabled
> * @cqm_rssi_hyst: Connection quality monitor RSSI hysteresis
> + * @cqm_beacon_miss_thold: Connection quality monitor beacon threshold, a
> zero
> + * value implies disabled
> + * @cqm_tx_fail_thold: Connection quality monitor tx threshold, a zero
> value
> + * implies disabled
Your line-wrapping makes this hard to read :(
> +++ b/net/mac80211/cfg.c
> @@ -1751,6 +1751,58 @@ static int ieee80211_set_cqm_rssi_config(struct
> wiphy *wiphy,
> return 0;
> }
>
> +static int ieee80211_set_cqm_beacon_miss_config(struct wiphy *wiphy,
> + struct net_device *dev,
> + u32 beacon_thold)
> +{
> + struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
> + struct ieee80211_local *local = wdev_priv(dev->ieee80211_ptr);
> + struct ieee80211_vif *vif = &sdata->vif;
> + struct ieee80211_bss_conf *bss_conf = &vif->bss_conf;
> +
> + if (beacon_thold == bss_conf->cqm_beacon_miss_thold)
> + return 0;
> +
> + bss_conf->cqm_beacon_miss_thold = beacon_thold;
> +
> + if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_CQM_BEACON_MISS)) {
> + if (sdata->vif.type != NL80211_IFTYPE_STATION)
> + return -EOPNOTSUPP;
> + return 0;
This looks/is wrong in multiple ways.
> +++ b/net/mac80211/mlme.c
> @@ -2174,7 +2174,10 @@ void ieee80211_sta_work(struct
> ieee80211_sub_if_data *sdata)
> ifmgd->probe_send_count, max_tries);
> #endif
> ieee80211_mgd_probe_ap_send(sdata);
> - } else {
> + } else if (!(local->hw.flags &
> + IEEE80211_HW_SUPPORTS_CQM_BEACON_MISS) &&
> + !(local->hw.flags &
> + IEEE80211_HW_SUPPORTS_CQM_TX_FAIL)) {
> /*
> * We actually lost the connection ... or did we?
> * Let's make sure!
explain.
> diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
> index 21fc970..4194b3e 100644
> --- a/net/wireless/mlme.c
> +++ b/net/wireless/mlme.c
> @@ -1097,6 +1097,7 @@ void cfg80211_gtk_rekey_notify(struct net_device
> *dev, const u8 *bssid,
> }
> EXPORT_SYMBOL(cfg80211_gtk_rekey_notify);
>
> +
> void cfg80211_pmksa_candidate_notify(struct net_device *dev, int index,
spurious whitespace change
johannes
next prev parent reply other threads:[~2011-10-12 8:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-12 1:02 [RFC 02/07] compat-wireless: Connection quality monitor extensions Dmitry Tarnyagin
2011-10-12 3:15 ` Julian Calaby
2011-10-12 8:21 ` Johannes Berg [this message]
2011-10-13 10:42 ` Janusz Dziedzic
2011-10-13 10:49 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1318407677.3933.18.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=abi.dmitryt@gmail.com \
--cc=bartosz.markowski@tieto.com \
--cc=janusz.dziedzic@tieto.com \
--cc=linux-wireless@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.