linux-toradex.git/net/mac80211/rate.h, branch v3.2.56 Linux kernel for Apalis and Colibri modules mac80211: add the minstrel_ht rate control algorithm 2010-06-02T20:12:59+00:00 Felix Fietkau nbd@openwrt.org 2010-05-13T14:48:03+00:00 ec8aa669b8393b6789b1954d587c63264af7ff99 Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> 
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211: Fix HT rate control configuration 2010-03-03T20:39:21+00:00 Sujith Sujith.Manoharan@atheros.com 2010-03-01T09:12:57+00:00 4fa004373133ece3d9b1c0a7e243b0e53760b165 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> 
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>
mac80211: make rate_control_alloc static 2010-02-08T21:51:03+00:00 Andres Salomon dilinger@collabora.co.uk 2010-02-08T02:47:50+00:00 209c671db7a917740ab9873d442b10ae7e369937 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> 
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>
mac80211: Don't call rate control when HW handles it 2010-02-01T20:40:09+00:00 Vasanthakumar vasanth@atheros.com 2010-02-01T13:19:07+00:00 3c384053ce4cb1949f5575c28e30e6ceea8cb39b 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> 
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>
cfg80211/mac80211: Use more generic bitrate mask for rate control 2010-01-12T18:50:11+00:00 Jouni Malinen jouni.malinen@atheros.com 2010-01-06T11:09:08+00:00 37eb0b164cf9fa9f70c8500926f5cde7c652f48e 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> 
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>
mac80211: make software rate control optional 2009-11-18T22:09:24+00:00 Johannes Berg johannes@sipsolutions.net 2009-11-17T17:18:36+00:00 af65cd96dd4ea8ea5adc6ee850e61a407cd1067a 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> 
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>
mac80211: rate control status only for controlled packets 2009-03-28T00:13:15+00:00 Johannes Berg johannes@sipsolutions.net 2009-03-23T13:10:22+00:00 2b874e83c970b45c328ab12239b066a43505454c 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> 
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>
mac80211: Extend the rate control API with an update callback 2009-02-27T19:51:45+00:00 Sujith Sujith.Manoharan@atheros.com 2009-02-12T06:08:37+00:00 81cb7623ad3b408f871fa36b774fc20d8dfccac0 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> 
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>
mac80211: remove rate_control_clear 2008-10-31T23:00:37+00:00 Johannes Berg johannes@sipsolutions.net 2008-10-16T09:21:49+00:00 50fb2e4572141770380f5919793c6e575fa3474b "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> 
"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>
mac80211/drivers: rewrite the rate control API 2008-10-31T23:00:23+00:00 Johannes Berg johannes@sipsolutions.net 2008-10-21T10:40:02+00:00 e6a9854b05c1a6af1308fe2b8c68f35abf28a3ee 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> 
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>