summaryrefslogtreecommitdiff
path: root/net/mac80211/rate.h
AgeCommit message (Collapse)AuthorFilesLines
2012-02-15mac80211: do not call rate control .tx_status before .rate_initFelix Fietkau1-1/+1
Most rate control implementations assume .get_rate and .tx_status are only called once the per-station data has been fully initialized. minstrel_ht crashes if this assumption is violated. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Tested-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-02-15mac80211: call rate control only after initJohannes Berg1-0/+1
There are situations where we don't have the necessary rate control information yet for station entries, e.g. when associating. This currently doesn't really happen due to the dummy station handling; explicitly disabling rate control when it's not initialised will allow us to remove dummy stations. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-06-02mac80211: add the minstrel_ht rate control algorithmFelix Fietkau1-0/+13
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-03-03mac80211: Fix HT rate control configurationSujith1-2/+3
Handling HT configuration changes involved setting the channel with the new HT parameters and then issuing a rate_update() notification to the driver. This behavior changed after the off-channel changes. Now, the channel is not updated with the new HT params in enable_ht() - instead, it is now done when the scan work terminates. This results in the driver depending on stale information, defaulting to non-HT mode always. Fix this by passing the new channel type to the driver. Cc: stable@kernel.org Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-02-08mac80211: make rate_control_alloc staticAndres Salomon1-5/+2
rate_control_alloc is not used by anything outside of ieee80211_init_rate_ctrl_alg. Both are in rate.c; there's no reason to make rate_control_alloc visible outside of it. Signed-off-by: Andres Salomon <dilinger@collabora.co.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-02-01mac80211: Don't call rate control when HW handles itVasanthakumar1-0/+4
Rate control should not be called to update the tx status when HW does the RC. Signed-off-by: Vasanthakumar <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-12cfg80211/mac80211: Use more generic bitrate mask for rate controlJouni Malinen1-4/+1
Extend struct cfg80211_bitrate_mask to actually use a bitfield mask instead of just a single fixed or maximum rate index. This change itself does not modify the behavior (except for debugfs files), but it prepares cfg80211 and mac80211 for a new nl80211 command for setting which rates can be used in TX rate control. Since frames are now going through the rate control algorithm unconditionally, the internal IEEE80211_TX_INTFL_RCALGO flag can now be removed. The RC implementations can use the rate_idx_mask value to optimize their behavior if only a single rate is enabled. The old max_rate_idx in struct ieee80211_tx_rate_control is maintained (but commented as deprecated) for backwards compatibility with existing RC implementations. Once these implementations have been updated to use the more generic rate_idx_mask, the max_rate_idx value can be removed. Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-11-18mac80211: make software rate control optionalJohannes Berg1-3/+6
Some devices implement the entire rate control in firmware in some way, like wl1271 or like iwlwifi which does some things in software but not a lot. Therefore generic software rate control is rather useless for them and just adds avoidable overhead to the transmit path. It's fairly simple to let drivers indicate that they do not need rate control, but they need to fulfil a number of conditions that we encode in WARN_ONs. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-03-27mac80211: rate control status only for controlled packetsJohannes Berg1-1/+3
This patch changes mac80211 to not notify the rate control algorithm's tx_status() method when reporting status for a packet that didn't go through the rate control algorithm's get_rate() method. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-02-27mac80211: Extend the rate control API with an update callbackSujith1-0/+12
The AP can switch dynamically between 20/40 Mhz channel width, in which case we switch the local operating channel, but the rate control algorithm is not notified. This patch adds a new callback to indicate such changes to the RC algorithm. Currently, HT channel width change is notified, but this callback can be used to indicate any new requirements that might come up later on. Signed-off-by: Sujith <Sujith.Manoharan@atheros.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31mac80211: remove rate_control_clearJohannes Berg1-6/+0
"Clearing" the rate control algorithm is pointless, none of the algorithms actually uses this operation and it's not even invoked properly for all channel switching. Also, there's no need to since rate control algorithms work per station. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-31mac80211/drivers: rewrite the rate control APIJohannes Berg1-3/+2
So after the previous changes we were still unhappy with how convoluted the API is and decided to make things simpler for everybody. This completely changes the rate control API, now taking into account 802.11n with MCS rates and more control, most drivers don't support that though. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-10-06mac80211: add the 'minstrel' rate control algorithmFelix Fietkau1-0/+14
Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-24mac80211: clean up rate control APIJohannes Berg1-76/+26
Long awaited, hard work. This patch totally cleans up the rate control API to remove the requirement to include internal headers outside of net/mac80211/. There's one internal use in the PID algorithm left for mesh networking, we'll have to figure out a way to clean that one up and decide how to do the peer link evaluation, possibly independent of the rate control algorithm or via new API. Additionally, ath9k is left using the cross-inclusion hack for now, we will add new API where necessary to make this work properly, but right now I'm not expert enough to do it. It's still off better than before. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-09-15mac80211: share sta->supp_ratesJohannes Berg1-1/+1
As more preparation for a saner rate control algorithm API, share the supported rates bitmap in the public API. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-06-30build algorithms into the mac80211 moduleAdrian Bunk1-3/+1
The old infrastructure was: - the default algorithm is built into mac80211 - other algorithms get into their own modules The implementation of this complicated scheme was horrible (just look at net/mac80211/Makefile), and anyone adding a new algorithm would most likely not get it right at his first attempt. This patch therefore builds all enabled algorithms into the mac80211 module. The user interface for the rate control algorithms changes as follows: - first the user can choose which algorithms to enable (currently only MAC80211_RC_PID is available) - if more than one algorithm is enabled (currently not possible since only one algorithm is present) the user then chooses the default one Note: - MAC80211_RC_PID is always enables for CONFIG_EMBEDDED=n Technical changes: - all selected algorithms get into the mac80211 module - net/mac80211/Makefile can now become much less complicated - support for rc80211_pid_algo.c being modular is no longer required - this includes unexporting mesh_plink_broken Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-21mac80211: move TX info into skb->cbJohannes Berg1-5/+3
This patch converts mac80211 and all drivers to have transmit information and status in skb->cb rather than allocating extra memory for it and copying all the data around. To make it fit, a union is used where only data that is necessary for all steps is kept outside of the union. A number of fixes were done by Ivo, as well as the rt2x00 part of this patch. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-05-21mac80211: use rate index in TX controlJohannes Berg1-16/+9
This patch modifies struct ieee80211_tx_control to give band info and the rate index (instead of rate pointers) to drivers. This mostly serves to reduce the TX control structure size to make it fit into skb->cb so that the fragmentation code can put it there and we can think about passing it to drivers that way in the future. The rt2x00 driver update was done by Ivo, thanks. Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-04-08mac80211: rename filesJohannes Berg1-0/+189
This patch renames all mac80211 files (except ieee80211_i.h) to get rid of the useless ieee80211_ prefix. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>