Update compat-wireless to 2.6.36-5-spn

Update compat-wireless to 2.6.36-5-spn (for better AR9380 support)

Replaces local chromium os changes with patches submitted to linux-wireless

mac80211: Add support for CQM tx bitrate monitoring

Add state, work proc and debugging parameters for monitoring
transmit-rate changes.

Signed-off-by: Paul Stewart <pstew@google.com>;

cfg80211: Add cfg80211/nl80211 calls for bitrate threshold

Add calls for accepting nl80211 bitrate thresholds from user space,
and add a function calls for sending out threshold notifications.

Signed-off-by: Paul Stewart <pstew@google.com>;

mac80211: probe the AP when resuming

Check the connection by probing the AP (either using nullfunc or a
probe request). If nullfunc probing is supported and the assoc is no
longer valid, the AP will send a disassoc/deauth immediately.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>;

mac80211: calculate beacon loss time accurately

Instead of using a fixed 2 second timeout, calculate beacon loss interval
from the advertised beacon interval and a frame count.  With this beacon
loss happens after N (default 7) consecutive frames are missed which
for a typical setup (100TU beacon interval) is ~700ms (or ~1/3 previous).

Signed-off-by: Sam Leffler <sleffler@chromium.org>;
Signed-off-by: Felix Fietkau <nbd@openwrt.org>;

mac80211: restart beacon miss timer on system resume from suspend

Signed-off-by: Paul Stewart <pstew@google.com>;
Signed-off-by: Felix Fietkau <nbd@openwrt.org>;

mac80211: reduce the number of retries for nullfunc probing

Since nullfunc frames are transmitted as unicast frames, they're more
reliable than the broadcast probe requests, so we need fewer retries
to figure out whether the AP is really gone.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>;

mac80211: use nullfunc instead of probe request for connection monitoring

nullfunc frames are better for connection monitoring, because probe requests
are answered even if the AP has already dropped the connection, whereas
nullfunc frames from an unassociated station will trigger a disassoc/deauth
frame from the AP (WLAN_REASON_CLASS3_FRAME_FROM_NONASSOC_STA), which allows
the station to reconnect immediately instead of waiting until it attempts to
transmit the next unicast frame.

This only works on hardware with reliable tx ACK reporting, any other hardware
needs to fall back to the probe request method.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>;

BUG=none
TEST=matfunc+secmat

[Sam Leffler, 2010-12-01 00:23:44]

You appear to be missing at least one cherry-picked CL that affects ampdu
teardown

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/driver...
File chromeos/compat-wireless/drivers/net/wireless/ath/ath9k/rc.c (right):

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/driver...
chromeos/compat-wireless/drivers/net/wireless/ath/ath9k/rc.c:541: u16 rate_flags
= rate_table->info[i].rate_flags;
looks like a local patch was dropped

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
File chromeos/compat-wireless/net/mac80211/debugfs_netdev.c (left):

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/debugfs_netdev.c:93: "true" :
"false");				\
dropped local changes

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/debugfs_netdev.c:166:
IEEE80211_IF_FILE(short_slot, vif.bss_conf.use_short_slot, BOOL);
local changes

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/debugfs_netdev.c:310:
DEBUGFS_ADD(short_slot);
local changes

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
File chromeos/compat-wireless/net/mac80211/main.c (right):

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/main.c:116: local->oper_channel !=
local->tmp_channel) {
<come back to this>

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
File chromeos/compat-wireless/net/mac80211/mlme.c (right):

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:31: #define
IEEE80211_MAX_NULLFUNC_TRIES 2
lost local change

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:54: #define
IEEE80211_PROBE_WAIT		(HZ / 2)
lost local change

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:1071:
!ieee80211_is_nullfunc(hdr->frame_control))
should be able to recognize NullData frame w/ one compare

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:1114: run_again(ifmgd,
ifmgd->probe_timeout);
this should not run for the send_nullfunc case as there will always be a tx
status callback

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:1192: ieee80211_set_disassoc(sdata,
true);
missing local changes

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:1920: * Let's make sure!
comment is wrong

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:1926: bssid, (1000 *
IEEE80211_PROBE_WAIT)/HZ);
this msg is wrong for the nulldata case which is why it was changed locally

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:2028:
ieee80211_restart_sta_timer(sdata);
this restarts more than just the connection monitor work, why?

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
File chromeos/compat-wireless/net/mac80211/status.c (right):

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/status.c:268: ieee80211_frame_acked(sta,
skb);
these changes are wrong; you don't notify when tx status shows !ACK'd

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
File chromeos/compat-wireless/net/mac80211/tx.c (right):

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/tx.c:289: printk(KERN_DEBUG "%s: dropped
data frame to not "
lost local change

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/wi...
File chromeos/compat-wireless/net/wireless/mlme.c (right):

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/wi...
chromeos/compat-wireless/net/wireless/mlme.c:186: if (wdev->sme_state ==
CFG80211_SME_CONNECTED) {
not sure about these changes

http://codereview.chromium.org/5326002/diff/1/chromeos/scripts/compat_wireles...
File chromeos/scripts/compat_wireless_config (right):

http://codereview.chromium.org/5326002/diff/1/chromeos/scripts/compat_wireles...
chromeos/scripts/compat_wireless_config:54: CONFIG_COMPAT_IWLWIFI=m
is this right?

[nbd, 2010-12-02 23:06:54]

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
File chromeos/compat-wireless/net/mac80211/mlme.c (right):

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:54: #define
IEEE80211_PROBE_WAIT		(HZ / 2)
On 2010/12/01 00:23:44, Sam Leffler wrote:
> lost local change
Intentionally dropped. Should be unnecessary with proper !ACK handling.

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:1114: run_again(ifmgd,
ifmgd->probe_timeout);
On 2010/12/01 00:23:44, Sam Leffler wrote:
> this should not run for the send_nullfunc case as there will always be a tx
> status callback
I think we should run this one even for the nullfunc case. The tx status
callback might be significantly delayed in situations where strong interference
kills beacons and delays transmissions.

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:2028:
ieee80211_restart_sta_timer(sdata);
On 2010/12/01 00:23:44, Sam Leffler wrote:
> this restarts more than just the connection monitor work, why?
The interface may have collected some unprocessed frames before the suspend
(e.g. action frames). I thought it would be a good idea to speed up the
processing here. If nothing is pending, then running this won't do any harm.

[Sam Leffler, 2010-12-08 18:37:56]

I hate to ask this but please split out the changes to probe the AP w/ the
NullData frames.  Everything else LGTM and it would be better to break this up
anyway because it's a combo of upstream compat-wireless 2.6.36-5 + these other
mods.

To be clear, please just keep the existing logic that does not support both
NullData+ProbeReq frames and move your rewrite into a separate CL.  That'll let
us commit these changes and the other CL's that are blocked by this one.

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
File chromeos/compat-wireless/net/mac80211/mlme.c (right):

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:54: #define
IEEE80211_PROBE_WAIT		(HZ / 2)
But you upped the max tries to 2 so there is now a 1/2 sec delay between probe
frames which is just wasted time.

http://codereview.chromium.org/5326002/diff/1/chromeos/compat-wireless/net/ma...
chromeos/compat-wireless/net/mac80211/mlme.c:1114: run_again(ifmgd,
ifmgd->probe_timeout);
I don't understand how interference relates to starting this timer.  It should
never be used in the NullData case because we will always get a TX status
callback on sending the frame.  It is only needed when sending ProbeReq frames.

http://codereview.chromium.org/5326002/diff/9001/chromeos/compat-wireless/net...
chromeos/compat-wireless/net/mac80211/mlme.c:31: #define
IEEE80211_MAX_NULLFUNC_TRIES 2
until we can override upstream defaults w/o modifying the code this should be 1

http://codereview.chromium.org/5326002/diff/9001/chromeos/compat-wireless/net...
chromeos/compat-wireless/net/mac80211/mlme.c:1070: if
(!ieee80211_is_data(hdr->frame_control) &&
this should check is_nullfunc instead and remove the check below

http://codereview.chromium.org/5326002/diff/9001/chromeos/compat-wireless/net...
chromeos/compat-wireless/net/mac80211/mlme.c:1082: 
this code is confusing because there are no comments and because you depend on
side effects from sta_reset_conn_monitor to reset probe_send_count to zero

there are two cases to handle: ack and !ack

when the NullData frame is ack'd you want to reset the timer and set
probe_send_count to 0; this is done by ieee80211_sta_reset_conn_monitor

when NullData is !ack'd you want to record the ack failed status and q sta work
to check state (probe again, declare connection lost, etc)

http://codereview.chromium.org/5326002/diff/9001/chromeos/compat-wireless/net...
chromeos/compat-wireless/net/mac80211/mlme.c:1109:
ieee80211_send_probe_req(sdata, dst, ssid + 2, ssid[1], NULL, 0);
it appears you are setting this here because the work q processing code is a
mashup of code for the NullData case and the ProbeReq case; if you split that I
think this code would be much less tangled

http://codereview.chromium.org/5326002/diff/9001/chromeos/compat-wireless/net...
chromeos/compat-wireless/net/mac80211/mlme.c:1927: ieee80211_set_disassoc(sdata,
true);
I find this combined code too complicated; I think you would be much better off
splitting the NullData and ProbeReq cases into separate routines/work q items.

http://codereview.chromium.org/5326002/diff/9001/chromeos/compat-wireless/net...
chromeos/compat-wireless/net/mac80211/mlme.c:1954:
ieee80211_queue_work(&sdata->local->hw,
how do we get to this case?  If we have TX status then nullfunc_failed must be
false which means the NullData frame was ACK'd which means sta_tx_notify would
not have q'd the work item

[Paul Stewart, 2010-12-08 22:02:45]

LGTM modulo resolution of the issues in mlme.c Sam highlighted