wlcore: user smaller sqn padding for GEM
On recovery, we increase the current seq num by WL1271_TX_SQN_POST_RECOVERY_PADDING in order to compensate for packets we might have missed during recovery. It seems that some GEM APs have issues when the gap is too big, so use a smaller padding in this case. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This commit is contained in:
parent
50d26aa338
commit
30a0035888
|
@ -374,6 +374,7 @@ void wl12xx_free_link(struct wl1271 *wl, struct wl12xx_vif *wlvif, u8 *hlid)
|
|||
|
||||
if (wlvif->bss_type == BSS_TYPE_AP_BSS &&
|
||||
*hlid == wlvif->ap.bcast_hlid) {
|
||||
u32 sqn_padding = WL1271_TX_SQN_POST_RECOVERY_PADDING;
|
||||
/*
|
||||
* save the total freed packets in the wlvif, in case this is
|
||||
* recovery or suspend
|
||||
|
@ -384,9 +385,11 @@ void wl12xx_free_link(struct wl1271 *wl, struct wl12xx_vif *wlvif, u8 *hlid)
|
|||
* increment the initial seq number on recovery to account for
|
||||
* transmitted packets that we haven't yet got in the FW status
|
||||
*/
|
||||
if (wlvif->encryption_type == KEY_GEM)
|
||||
sqn_padding = WL1271_TX_SQN_POST_RECOVERY_PADDING_GEM;
|
||||
|
||||
if (test_bit(WL1271_FLAG_RECOVERY_IN_PROGRESS, &wl->flags))
|
||||
wlvif->total_freed_pkts +=
|
||||
WL1271_TX_SQN_POST_RECOVERY_PADDING;
|
||||
wlvif->total_freed_pkts += sqn_padding;
|
||||
}
|
||||
|
||||
wl->links[*hlid].total_freed_pkts = 0;
|
||||
|
|
|
@ -902,6 +902,7 @@ static void wlcore_save_freed_pkts(struct wl1271 *wl, struct wl12xx_vif *wlvif,
|
|||
u8 hlid, struct ieee80211_sta *sta)
|
||||
{
|
||||
struct wl1271_station *wl_sta;
|
||||
u32 sqn_recovery_padding = WL1271_TX_SQN_POST_RECOVERY_PADDING;
|
||||
|
||||
wl_sta = (void *)sta->drv_priv;
|
||||
wl_sta->total_freed_pkts = wl->links[hlid].total_freed_pkts;
|
||||
|
@ -910,9 +911,11 @@ static void wlcore_save_freed_pkts(struct wl1271 *wl, struct wl12xx_vif *wlvif,
|
|||
* increment the initial seq number on recovery to account for
|
||||
* transmitted packets that we haven't yet got in the FW status
|
||||
*/
|
||||
if (wlvif->encryption_type == KEY_GEM)
|
||||
sqn_recovery_padding = WL1271_TX_SQN_POST_RECOVERY_PADDING_GEM;
|
||||
|
||||
if (test_bit(WL1271_FLAG_RECOVERY_IN_PROGRESS, &wl->flags))
|
||||
wl_sta->total_freed_pkts +=
|
||||
WL1271_TX_SQN_POST_RECOVERY_PADDING;
|
||||
wl_sta->total_freed_pkts += sqn_recovery_padding;
|
||||
}
|
||||
|
||||
static void wlcore_save_freed_pkts_addr(struct wl1271 *wl,
|
||||
|
|
|
@ -45,6 +45,9 @@
|
|||
#define WL1271_TX_SECURITY_LO16(s) ((u16)((s) & 0xffff))
|
||||
#define WL1271_TX_SECURITY_HI32(s) ((u32)(((s) >> 16) & 0xffffffff))
|
||||
#define WL1271_TX_SQN_POST_RECOVERY_PADDING 0xff
|
||||
/* Use smaller padding for GEM, as some APs have issues when it's too big */
|
||||
#define WL1271_TX_SQN_POST_RECOVERY_PADDING_GEM 0x20
|
||||
|
||||
|
||||
#define WL1271_CIPHER_SUITE_GEM 0x00147201
|
||||
|
||||
|
|
Loading…
Reference in New Issue