- 29 3月, 2018 1 次提交
-
-
由 tamizhr@codeaurora.org 提交于
SMPS_MODE change value notified via nl80211 contains mac80211 specific value(ieee80211_smps_mode) and user space application will not know those values. This patch add support to map the mac80211 enum value to nl80211_smps_mode which will be understood by the userspace application. Signed-off-by: NTamizh chelvam <tamizhr@codeaurora.org> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 11 12月, 2017 2 次提交
-
-
由 Gustavo A. R. Silva 提交于
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Notice that in some cases I replaced "fall through on else" and "otherwise fall through" comments with just a "fall through" comment, which is what GCC is expecting to find. Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Due to overlap between commit 12811037 ("mac80211: Simplify locking in ieee80211_sta_tear_down_BA_sessions()") and the way that Luca modified commit 72e2c343 ("mac80211: tear down RX aggregations first") when sending it upstream from Intel's internal tree, we get the following warning: WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315 ___ieee80211_stop_tx_ba_session+0x158/0x1f0 since there's no appropriate locking around the call to ___ieee80211_stop_tx_ba_session; Sara's original just had a call to the locked __ieee80211_stop_tx_ba_session (one less underscore) but it looks like Luca modified both of the calls when fixing it up for upstream, leading to the problem at hand. Move the locking appropriately to fix this problem. Reported-by: NKalle Valo <kvalo@codeaurora.org> Reported-by: NPavel Machek <pavel@ucw.cz> Tested-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 27 11月, 2017 1 次提交
-
-
由 Sara Sharon 提交于
When doing HW restart we tear down aggregations. Since at this point we are not TX'ing any aggregation, while the peer is still sending RX aggregation over the air, it will make sense to tear down the RX aggregations first. Signed-off-by: NSara Sharon <sara.sharon@intel.com> Signed-off-by: NLuca Coelho <luciano.coelho@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 21 9月, 2017 1 次提交
-
-
由 Ilan peer 提交于
Simplify the locking in ieee80211_sta_tear_down_BA_sessions() and lock sta->ampdu_mlme.mtx over the entire function instead of locking/unlocking it for each TID etc. Signed-off-by: NIlan Peer <ilan.peer@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 06 9月, 2017 2 次提交
-
-
由 Johannes Berg 提交于
When an RX BA session is started by the driver, and it has to tell mac80211 about it, the corresponding bit in tid_rx_manage_offl gets set and the BA session work is scheduled. Upon testing this bit, it will call __ieee80211_start_rx_ba_session(), thus deadlocking as it already holds the ampdu_mlme.mtx, which that acquires again. Fix this by adding ___ieee80211_start_rx_ba_session(), a version of the function that requires the mutex already held. Cc: stable@vger.kernel.org Fixes: 699cb58c ("mac80211: manage RX BA session offload without SKB queue") Reported-by: NMatteo Croce <mcroce@redhat.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Ilan peer 提交于
Commit 7a7c0a64 ("mac80211: fix TX aggregation start/stop callback race") added a cancellation of the ampdu work after the loop that stopped the Tx and Rx BA sessions. However, in some cases, e.g., during HW reconfig, the low level driver might call mac80211 APIs to complete the stopping of the BA sessions, which would queue the ampdu work to handle the actual completion. This work needs to be performed as otherwise mac80211 data structures would not be properly synced. Fix this by checking if BA session STOP_CB bit is set after the BA session cancellation and properly clean the session. Signed-off-by: NIlan Peer <ilan.peer@intel.com> [Johannes: the work isn't flushed because that could do other things we don't want, and the locking situation isn't clear] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 6月, 2017 2 次提交
-
-
由 Johannes Berg 提交于
It seems like a historic accident that these return unsigned char *, and in many places that means casts are required, more often than not. Make these functions (skb_put, __skb_put and pskb_put) return void * and remove all the casts across the tree, adding a (u8 *) cast only where the unsigned char pointer was used directly, all done with the following spatch: @@ expression SKB, LEN; typedef u8; identifier fn = { skb_put, __skb_put }; @@ - *(fn(SKB, LEN)) + *(u8 *)fn(SKB, LEN) @@ expression E, SKB, LEN; identifier fn = { skb_put, __skb_put }; type T; @@ - E = ((T *)(fn(SKB, LEN))) + E = fn(SKB, LEN) which actually doesn't cover pskb_put since there are only three users overall. A handful of stragglers were converted manually, notably a macro in drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many instances in net/bluetooth/hci_sock.c. In the former file, I also had to fix one whitespace problem spatch introduced. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Johannes Berg 提交于
There were many places that my previous spatch didn't find, as pointed out by yuan linyu in various patches. The following spatch found many more and also removes the now unnecessary casts: @@ identifier p, p2; expression len; expression skb; type t, t2; @@ ( -p = skb_put(skb, len); +p = skb_put_zero(skb, len); | -p = (t)skb_put(skb, len); +p = skb_put_zero(skb, len); ) ... when != p ( p2 = (t2)p; -memset(p2, 0, len); | -memset(p, 0, len); ) @@ type t, t2; identifier p, p2; expression skb; @@ t *p; ... ( -p = skb_put(skb, sizeof(t)); +p = skb_put_zero(skb, sizeof(t)); | -p = (t *)skb_put(skb, sizeof(t)); +p = skb_put_zero(skb, sizeof(t)); ) ... when != p ( p2 = (t2)p; -memset(p2, 0, sizeof(*p)); | -memset(p, 0, sizeof(*p)); ) @@ expression skb, len; @@ -memset(skb_put(skb, len), 0, len); +skb_put_zero(skb, len); Apply it to the tree (with one manual fixup to keep the comment in vxlan.c, which spatch removed.) Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 6月, 2017 1 次提交
-
-
由 Johannes Berg 提交于
Instead of using the SKB queue with the fake pkt_type for the offloaded RX BA session management, also handle this with the normal aggregation state machine worker. This also makes the use of this more reliable since it gets rid of the allocation of the fake skb. Combined with the previous patch, this finally allows us to get rid of the pkt_type hack entirely, so do that as well. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 30 5月, 2017 1 次提交
-
-
由 Johannes Berg 提交于
When starting or stopping an aggregation session, one of the steps is that the driver calls back to mac80211 that the start/stop can proceed. This is handled by queueing up a fake SKB and processing it from the normal iface/sdata work. Since this isn't flushed when disassociating, the following race is possible: * associate * start aggregation session * driver callback * disassociate * associate again to the same AP * callback processing runs, leading to a WARN_ON() that the TID hadn't requested aggregation If the second association isn't to the same AP, there would only be a message printed ("Could not find station: <addr>"), but the same race could happen. Fix this by not going the whole detour with a fake SKB etc. but simply looking up the aggregation session in the driver callback, marking it with a START_CB/STOP_CB bit and then scheduling the regular aggregation work that will now process these bits as well. This also simplifies the code and gets rid of the whole problem with allocation failures of said skb, which could have left the session in limbo. Reported-by: NJouni Malinen <j@w1.fi> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 24 2月, 2016 1 次提交
-
-
由 Emmanuel Grumbach 提交于
In VHT, the specification allows to limit the number of MSDUs in an A-MSDU in the Extended Capabilities IE. There is also a limitation on the byte size in the VHT IE. In HT, the only limitation is on the byte size. Parse the capabilities from the peer and make them available to the driver. In HT, there is another limitation when a BA agreement is active: the byte size can't be greater than 4095. This is not enforced here. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 30 3月, 2015 1 次提交
-
-
Add VHT support for IBSS. Drivers could activate this feature by setting NL80211_EXT_FEATURE_VHT_IBSS flag. Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 21 7月, 2014 2 次提交
-
-
由 Arik Nemtsov 提交于
Set for completeness mostly, currently unused in the code. Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Arik Nemtsov 提交于
Add the HT capabilities and HT operation information elements to TDLS setup packets where appropriate. Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com> Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 22 4月, 2014 1 次提交
-
-
由 Jouni Malinen 提交于
This can be useful for testing purposes to confirm valid AP behavior on HT 20/40 co-existence functionality. Signed-off-by: NJouni Malinen <jouni@qca.qualcomm.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 09 4月, 2014 1 次提交
-
-
由 Pawel Kulakowski 提交于
This allows user-space (wpa_supplicant) to disable LDPC coding. Signed-off-by: NPawel Kulakowski <pawel.kulakowski@tieto.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 21 2月, 2014 1 次提交
-
-
由 Luciano Coelho 提交于
Previously we were warning and using automatic when a driver sent an update request with SMPS off. This patch makes it possible for drivers to disable SMPS at runtime, for whatever reason. Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 06 2月, 2014 1 次提交
-
-
由 Emmanuel Grumbach 提交于
sdata->u.ap.request_smps_work can’t be flushed synchronously under wdev_lock(wdev) since ieee80211_request_smps_ap_work itself locks the same lock. While at it, reset the driver_smps_mode when the ap is stopped to its default: OFF. This solves: ====================================================== [ INFO: possible circular locking dependency detected ] 3.12.0-ipeer+ #2 Tainted: G O ------------------------------------------------------- rmmod/2867 is trying to acquire lock: ((&sdata->u.ap.request_smps_work)){+.+...}, at: [<c105b8d0>] flush_work+0x0/0x90 but task is already holding lock: (&wdev->mtx){+.+.+.}, at: [<f9b32626>] cfg80211_stop_ap+0x26/0x230 [cfg80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&wdev->mtx){+.+.+.}: [<c10aefa9>] lock_acquire+0x79/0xe0 [<c1607a1a>] mutex_lock_nested+0x4a/0x360 [<fb06288b>] ieee80211_request_smps_ap_work+0x2b/0x50 [mac80211] [<c105cdd8>] process_one_work+0x198/0x450 [<c105d469>] worker_thread+0xf9/0x320 [<c10669ff>] kthread+0x9f/0xb0 [<c1613397>] ret_from_kernel_thread+0x1b/0x28 -> #0 ((&sdata->u.ap.request_smps_work)){+.+...}: [<c10ae9df>] __lock_acquire+0x183f/0x1910 [<c10aefa9>] lock_acquire+0x79/0xe0 [<c105b917>] flush_work+0x47/0x90 [<c105d867>] __cancel_work_timer+0x67/0xe0 [<c105d90f>] cancel_work_sync+0xf/0x20 [<fb0765cc>] ieee80211_stop_ap+0x8c/0x340 [mac80211] [<f9b3268c>] cfg80211_stop_ap+0x8c/0x230 [cfg80211] [<f9b0d8f9>] cfg80211_leave+0x79/0x100 [cfg80211] [<f9b0da72>] cfg80211_netdev_notifier_call+0xf2/0x4f0 [cfg80211] [<c160f2c9>] notifier_call_chain+0x59/0x130 [<c106c6de>] __raw_notifier_call_chain+0x1e/0x30 [<c106c70f>] raw_notifier_call_chain+0x1f/0x30 [<c14f8213>] call_netdevice_notifiers_info+0x33/0x70 [<c14f8263>] call_netdevice_notifiers+0x13/0x20 [<c14f82a4>] __dev_close_many+0x34/0xb0 [<c14f83fe>] dev_close_many+0x6e/0xc0 [<c14f9c77>] rollback_registered_many+0xa7/0x1f0 [<c14f9dd4>] unregister_netdevice_many+0x14/0x60 [<fb06f4d9>] ieee80211_remove_interfaces+0xe9/0x170 [mac80211] [<fb055116>] ieee80211_unregister_hw+0x56/0x110 [mac80211] [<fa3e9396>] iwl_op_mode_mvm_stop+0x26/0xe0 [iwlmvm] [<f9b9d8ca>] _iwl_op_mode_stop+0x3a/0x70 [iwlwifi] [<f9b9d96f>] iwl_opmode_deregister+0x6f/0x90 [iwlwifi] [<fa405179>] __exit_compat+0xd/0x19 [iwlmvm] [<c10b8bf9>] SyS_delete_module+0x179/0x2b0 [<c1613421>] sysenter_do_call+0x12/0x32 Fixes: 687da132 ("mac80211: implement SMPS for AP") Cc: <stable@vger.kernel.org> [3.13] Reported-by: NIlan Peer <ilan.peer@intel.com> Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 05 2月, 2014 1 次提交
-
-
由 Karl Beldan 提交于
ATM, {ADD,DEL}BA and BAR frames are sent on the AC matching the TID of the BA parameters. In the discussion [1] about this patch, Johannes recalled that it fixed some races with the DELBA and indeed this behavior was introduced in [2]. While [2] is right for the BARs, the part queueing the {ADD,DEL}BAs on their BA params TID AC violates the spec and is more a workaround for some drivers. Helmut expressed some concerns wrt such drivers, in particular DELBAs in rt2x00. ATM, DELBAs are sent after a driver has called (hence "purposely") ieee80211_start_tx_ba_cb_irqsafe and Johannes and Emmanuel gave some details wrt intentions behind the split of the IEEE80211_AMPDU_TX_STOP_* given to the driver ampdu_action supposed to call this function, which could prove handy to people trying to do the right thing in faulty drivers (if their fw/hw don't get in their way). [1] http://mid.gmane.org/1390391564-18481-1-git-send-email-karl.beldan@gmail.com [2] Commit: cf6bb79a ("mac80211: Use appropriate TID for sending BAR, ADDBA and DELBA frames") Signed-off-by: NKarl Beldan <karl.beldan@rivierawaves.com> Cc: Helmut Schaa <helmut.schaa@googlemail.com> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 07 1月, 2014 1 次提交
-
-
由 Emmanuel Grumbach 提交于
In managed mode, we should not ask for OFF mode because the power settings may still require DYNAMIC. In AP mode, this should be allowed since the default settings is OFF and AUTOMATIC is not allowed. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 28 10月, 2013 1 次提交
-
-
由 Emmanuel Grumbach 提交于
When the driver requests to move to STATIC or DYNAMIC SMPS, we send an action frame to each associated station and reconfigure the channel context / driver. Of course, non-MIMO stations are ignored. The beacon isn't updated. The association response will include the original capabilities. Stations that associate while in non-OFF SMPS mode will get an action frame right after association to inform them about our current state. Note that we wait until the end of the EAPOL. Sending an action frame before the EAPOL is finished can be an issue for a few clients. Clients aren't likely to send EAPOL frames in MIMO anyway. When the SMPS configuration gets more permissive (e.g. STATIC -> OFF), we don't wake up stations that are asleep We remember that they don't know about the change and send the action frame when they wake up. When the SMPS configuration gets more restrictive (e.g. OFF -> STATIC), we set the TIM bit for every sleeping STA. uAPSD stations might send MIMO until they poll the action frame, but this is for a short period of time. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> [fix vht streams loop, initialisation] Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 7月, 2013 1 次提交
-
-
由 Simon Wunderlich 提交于
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
-
- 13 6月, 2013 1 次提交
-
-
由 Ben Greear 提交于
All accesses of the tid_start_tx lock should be protected by sta->lock if there is any chance that another thread could still be accessing the sta object. Signed-off-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 25 5月, 2013 1 次提交
-
-
由 Johannes Berg 提交于
Using separate locks in cfg80211 and mac80211 has always caused issues, for example having to unlock in places in mac80211 to call cfg80211, which even needed a framework to make cfg80211 calls after some functions returned etc. Additionally, I suspect some issues people have reported with the cfg80211 state getting confused could be due to such issues, when cfg80211 is asking mac80211 to change state but mac80211 is in the process of telling cfg80211 that the state changed (in another way.) Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 06 3月, 2013 2 次提交
-
-
由 Johannes Berg 提交于
HT capabilites are asymmetric -- e.g. beamforming is both an RX and TX capability. If, for example, we support RX but not TX, the RX capability of the AP station is masked out (if it supports it). This works correctly if it's really the driver capability. If, on the other hand, the reason for not supporting TX BF is that it was removed by HT capability overrides then the wrong thing happens: the AP's TX capability will be removed rather than its RX capability, because the override function works on own capabilities, not remote ones, and doesn't take the asymmetry into account. To fix this make a copy of our own capabilities, apply the overrides to them (where needed) and then use that to set up the peer's capabilities. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The HT overrides are intended only for the connection to the AP, not for any other purpose. Therefore, don't apply them to TDLS peers that are also stations added to a managed station interface. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 15 2月, 2013 4 次提交
-
-
由 Johannes Berg 提交于
Instead of modifying the HT SMPS capability field for stations, track the SMPS mode explicitly in a new field in the station struct and use it in the drivers that care about it. This simplifies the code using it. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Make all the parsed IE pointers const, and propagate the change to all the users etc. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
Handle the operating mode notification action frame. When the supported streams or the bandwidth change let the driver and rate control algorithm know. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
For VHT, many more bandwidth changes are possible. As a first step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag in the HT capabilities and instead introduce a bandwidth field indicating the currently usable bandwidth to transmit to the station. Of course, make all drivers use it. To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get the station as an argument, rather than the new capabilities, so it can set up the new bandwidth field. If the station is a VHT station and VHT bandwidth is in use, also set the bandwidth accordingly. Doing this allows us to get rid of the supports_40mhz flag as the HT capabilities now reflect the true capability instead of the current setting. While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not ignore HT cap overrides when MCS TX isn't supported (not that it really happens...) Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 12 2月, 2013 1 次提交
-
-
由 Emmanuel Grumbach 提交于
Bail out if no update is made to the SMPS state. This allows the driver to avoid duplicating the state. Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 03 1月, 2013 3 次提交
-
-
由 Johannes Berg 提交于
When an interface is configured to a 20 MHz channel and the device as well as the peer are 40 MHz capable the HT capabilities of the peer are not restricted to 20 MHz, even though they're supposed to be restricted to the currently possible capabilities. Unset the 40 MHz HT capability bits in this case. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Johannes Berg 提交于
The initiator/tx doesn't really identify why an aggregation session is stopped, give a reason for stopping that more clearly identifies what's going on. This will help tell the driver clearly what is expected of it. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
由 Ben Greear 提交于
This allows user-space (wpa_supplicant) to disable short guard interval (SGI) for 20Mhz. The SGI-40 disable option is already handled. Signed-off-by: NBen Greear <greearb@candelatech.com> Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 19 11月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
Introduce IEEE80211_NUM_TIDS in the generic 802.11 header file and use it in place of STA_TID_NUM and NUM_RX_DATA_QUEUES which are both really the number of TIDs. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 24 6月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
There are a few things that make the logging and debugging in mac80211 less useful than it should be right now: * a lot of messages should be pr_info, not pr_debug * wholesale use of pr_debug makes it require *both* Kconfig and dynamic configuration * there are still a lot of ifdefs * the style is very inconsistent, sometimes the sdata->name is printed in front Clean up everything, introducing new macros and separating out the station MLME debugging into a new Kconfig symbol. Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
-
- 16 5月, 2012 1 次提交
-
-
由 Joe Perches 提交于
Standardize the net core ratelimited logging functions. Coalesce formats, align arguments. Change a printk then vprintk sequence to use printf extension %pV. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 11 4月, 2012 1 次提交
-
-
由 Johannes Berg 提交于
Changing the channel type during operation is confusing to some drivers and will be hard to handle in multi-channel scenarios. Instead of changing the channel, set it to the right HT channel before authenticating/associating and don't change it -- just update the 20/40 MHz restrictions in rate control as needed when changed by the AP. This also fixes a problem that Paul missed in his fix for the "regulatory makes us deaf" issue -- when we couldn't use 40 MHz we still associated saying we were using 40 MHz, which could in similarly broken APs make us never even connect successfully. Signed-off-by: NJohannes Berg <johannes.berg@intel.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-
- 16 12月, 2011 1 次提交
-
-
由 Helmut Schaa 提交于
Currently BAR, ADDBA and DELBA frames are always sent using AC_VO. If the TID for which a BA session is established is assigned to a different queue BAR, ADDBA and DELBA frames can "overtake" frames of the according BA session. Hence, always put BA session related frames into the same queue as the BA sessions data frames. Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
-