user/sven/linux.git/include/net/mac80211.h, branch stable/3.2.y

mac80211: introduce IEEE80211_HW_TEARDOWN_AGGR_ON_BAR_FAIL

2013-01-16T01:13:22Z

commit 5b632fe85ec82e5c43740b52e74c66df50a37db3 upstream. Commit f0425beda4d404a6e751439b562100b902ba9c98 "mac80211: retry sending failed BAR frames later instead of tearing down aggr" caused regression on rt2x00 hardware (connection hangs). This regression was fixed by commit be03d4a45c09ee5100d3aaaedd087f19bc20d01 "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails". But the latter commit caused yet another problem reported in https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22 After long discussion in this thread: http://mid.gmane.org/20121018075615.GA18212@redhat.com and testing various alternative solutions, which failed on one or other setup, we have no other good fix for the issues like just revert both mentioned earlier commits. To do not affect other hardware which benefit from commit f0425beda4d404a6e751439b562100b902ba9c98, instead of reverting it, introduce flag that when used will restore mac80211 behaviour before the commit. Signed-off-by: Stanislaw Gruszka [replaced link with mid.gmane.org that has message-id] Signed-off-by: Johannes Berg [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

mac80211: warn only once about not finding a rate

2011-11-04T17:38:06Z

The warning really shouldn't happen, but until we find the reason why it does don't spew it all the time, just once is enough to know we've hit it. Reported-by: Linus Torvalds Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

mac80211: Populate radiotap header with MCS info for TX frames

2011-10-14T18:48:14Z

mac80211 already filled in the MCS rate info for rx'ed frames but tx'ed frames that are sent to a monitor interface during the status callback lack this information. Add the radiotap fields for MCS info to ieee80211_tx_status_rtap_hdr and populate them when sending tx'ed frames to the monitors. The needed headroom is only extended by one byte since we don't include legacy rate information in the rtap header for HT frames. Signed-off-by: Helmut Schaa Signed-off-by: John W. Linville

mac80211: parse radiotap header earlier

2011-10-11T20:41:19Z

We can now move the radiotap header parsing into ieee80211_monitor_start_xmit(). This moves it out of the hotpath, and also helps the code since now the radiotap header will no longer be present in ieee80211_xmit() etc. which is easier to understand. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

mac80211: move fragment flag to info flag as dont-fragment

2011-10-11T20:41:19Z

The purpose of this is two-fold: 1) by moving it out of tx_data.flags, we can in another patch move the radiotap parsing so it no longer is in the hotpath 2) if a device implements fragmentation but can optionally skip it, the radiotap request for not doing fragmentation may be honoured Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

mac80211: pass vif param to conf_tx() callback

2011-10-03T19:22:41Z

tx params should be configured per interface. add ieee80211_vif param to the conf_tx callback, and change all the drivers that use this callback. The following spatch was used: @rule1@ struct ieee80211_ops ops; identifier conf_tx_op; @@ ops.conf_tx = conf_tx_op; @rule2@ identifier rule1.conf_tx_op; identifier hw, queue, params; @@ conf_tx_op ( - struct ieee80211_hw *hw, + struct ieee80211_hw *hw, struct ieee80211_vif *vif, u16 queue, const struct ieee80211_tx_queue_params *params) {...} Signed-off-by: Eliad Peller Signed-off-by: John W. Linville

mac80211: Send nullfunc frames at lower rate during connection monitor

2011-10-03T19:22:32Z

Recently mac80211 was changed to use nullfunc instead of probe request for connection monitoring for tx ack status reporting hardwares. Sometimes in congested network, STA got disconnected quickly after the association. It was observered that the rate control was not adopted to environment due to minimal transmission. As the nullfunc are used for monitoring purpose, these frames should not be sacrificed for rate control updation. So it is better to send the monitoring null func frames at minimum rate that could help to retain the connection. Signed-off-by: Rajkumar Manoharan Signed-off-by: John W. Linville

mac80211: document client powersave

2011-09-30T19:57:24Z

With the addition of uAPSD and driver buffering the powersave handling has gotten quite complex. Add a section to the documentation to explain it for anyone wanting to implement it. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

mac80211: allow out-of-band EOSP notification

2011-09-30T19:57:23Z

iwlwifi has a separate EOSP notification from the device, and to make use of that properly it needs to be passed to mac80211. To be able to mix with tx_status_irqsafe and rx_irqsafe it also needs to be an "_irqsafe" version in the sense that it goes through the tasklet, the actual flag clearing would be IRQ-safe but doing it directly would cause reordering issues. This is needed in the case of a P2P GO going into an absence period without transmitting any frames that should be driver-released as in this case there's no other way to inform mac80211 that the service period ended. Note that for drivers that don't use the _irqsafe functions another version of this function will be required. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville

mac80211: explicitly notify drivers of frame release

2011-09-30T19:57:21Z

iwlwifi needs to know the number of frames that are going to be sent to a station while it is asleep so it can properly handle the uCode blocking of that station. Before uAPSD, we got by by telling the device that a single frame was going to be released whenever we encountered IEEE80211_TX_CTL_POLL_RESPONSE. With uAPSD, however, that is no longer possible since there could be more than a single frame. To support this model, add a new callback to notify drivers when frames are going to be released. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville