diff options
author | Johannes Berg <johannes@sipsolutions.net> | 2009-01-07 18:28:20 +0100 |
---|---|---|
committer | John W. Linville <linville@tuxdriver.com> | 2009-01-29 15:59:58 -0500 |
commit | 4be8c3873e0b88397866d3ede578503e188f9ad2 (patch) | |
tree | 1ccf8a0c204bb01aca08d90c2d8c37b5e0439bd3 /include/net/mac80211.h | |
parent | acbaf32e94cb70218792cac68e5149e482e77441 (diff) | |
download | linux-4be8c3873e0b88397866d3ede578503e188f9ad2.tar.bz2 |
mac80211: extend/document powersave API
This modifies hardware flags for powersave to support three different
flags:
* IEEE80211_HW_SUPPORTS_PS - indicates general PS support
* IEEE80211_HW_PS_NULLFUNC_STACK - indicates nullfunc sending in software
* IEEE80211_HW_SUPPORTS_DYNAMIC_PS - indicates dynamic PS on the device
It also adds documentation for all this which explains how to set the
various flags.
Additionally, it fixes a few things:
* a spot where && was used to test flags
* enable CONF_PS only when associated again
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Diffstat (limited to 'include/net/mac80211.h')
-rw-r--r-- | include/net/mac80211.h | 53 |
1 files changed, 48 insertions, 5 deletions
diff --git a/include/net/mac80211.h b/include/net/mac80211.h index 83ee8a212296..8a305bfdb87b 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -850,10 +850,15 @@ enum ieee80211_tkip_key_type { * @IEEE80211_HW_AMPDU_AGGREGATION: * Hardware supports 11n A-MPDU aggregation. * - * @IEEE80211_HW_NO_STACK_DYNAMIC_PS: - * Hardware which has dynamic power save support, meaning - * that power save is enabled in idle periods, and don't need support - * from stack. + * @IEEE80211_HW_SUPPORTS_PS: + * Hardware has power save support (i.e. can go to sleep). + * + * @IEEE80211_HW_PS_NULLFUNC_STACK: + * Hardware requires nullfunc frame handling in stack, implies + * stack support for dynamic PS. + * + * @IEEE80211_HW_SUPPORTS_DYNAMIC_PS: + * Hardware has support for dynamic PS. */ enum ieee80211_hw_flags { IEEE80211_HW_RX_INCLUDES_FCS = 1<<1, @@ -866,7 +871,9 @@ enum ieee80211_hw_flags { IEEE80211_HW_NOISE_DBM = 1<<8, IEEE80211_HW_SPECTRUM_MGMT = 1<<9, IEEE80211_HW_AMPDU_AGGREGATION = 1<<10, - IEEE80211_HW_NO_STACK_DYNAMIC_PS = 1<<11, + IEEE80211_HW_SUPPORTS_PS = 1<<11, + IEEE80211_HW_PS_NULLFUNC_STACK = 1<<12, + IEEE80211_HW_SUPPORTS_DYNAMIC_PS = 1<<13, }; /** @@ -1053,6 +1060,42 @@ ieee80211_get_alt_retry_rate(const struct ieee80211_hw *hw, */ /** + * DOC: Powersave support + * + * mac80211 has support for various powersave implementations. + * + * First, it can support hardware that handles all powersaving by + * itself, such hardware should simply set the %IEEE80211_HW_SUPPORTS_PS + * hardware flag. In that case, it will be told about the desired + * powersave mode depending on the association status, and the driver + * must take care of sending nullfunc frames when necessary, i.e. when + * entering and leaving powersave mode. The driver is required to look at + * the AID in beacons and signal to the AP that it woke up when it finds + * traffic directed to it. This mode supports dynamic PS by simply + * enabling/disabling PS. + * + * Additionally, such hardware may set the %IEEE80211_HW_SUPPORTS_DYNAMIC_PS + * flag to indicate that it can support dynamic PS mode itself (see below). + * + * Other hardware designs cannot send nullfunc frames by themselves and also + * need software support for parsing the TIM bitmap. This is also supported + * by mac80211 by combining the %IEEE80211_HW_SUPPORTS_PS and + * %IEEE80211_HW_PS_NULLFUNC_STACK flags. The hardware is of course still + * required to pass up beacons. Additionally, in this case, mac80211 will + * wake up the hardware when multicast traffic is announced in the beacon. + * + * FIXME: I don't think we can be fast enough in software when we want to + * receive multicast traffic? + * + * Dynamic powersave mode is an extension to normal powersave mode in which + * the hardware stays awake for a user-specified period of time after sending + * a frame so that reply frames need not be buffered and therefore delayed + * to the next wakeup. This can either be supported by hardware, in which case + * the driver needs to look at the @dynamic_ps_timeout hardware configuration + * value, or by the stack if all nullfunc handling is in the stack. + */ + +/** * DOC: Frame filtering * * mac80211 requires to see many management frames for proper |