On Sat, Mar 14, 2009 at 10:14 AM, Kalle Valo <kalle.valo@xxxxxxxxx> wrote:
> Add IEEE80211_HW_BEACON_FILTERING flag so that driver inform that it supports
> beacon filtering. Drivers need to call the new function
> ieee80211_beacon_loss() to notify about beacon loss.
>
> Signed-off-by: Kalle Valo <kalle.valo@xxxxxxxxx>
> ---
>
> include/net/mac80211.h | 18 ++++++++++++++++++
> net/mac80211/ieee80211_i.h | 2 ++
> net/mac80211/iface.c | 3 +++
> net/mac80211/mlme.c | 39 ++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 61 insertions(+), 1 deletions(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 9ef131d..1262b83 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -888,6 +888,13 @@ enum ieee80211_tkip_key_type {
> *
> * @IEEE80211_HW_MFP_CAPABLE:
> * Hardware supports management frame protection (MFP, IEEE 802.11w).
> + *
> + * @IEEE80211_HW_BEACON_FILTER: Hardware can drop similar beacon frames to
> + * avoid waking up cpu. Enabling this flag disables the beacon check
> + * in mac80211 when in power save mode and the hardware must have an
> + * event to notify that beacons are lost. Use ieee80211_beacon_loss()
> + * to notify the event to the stack. The filtering must be enabled
> + * only when IEEE80211_CONF_PS is set.
> */
Lets add to the documentation a little detail explaining how beacon filtering
is expected to work, and elaborate on what we expect from the driver, if
anything all.
I'd like to review this just once more.
Last we reviewed this it seemed we were set on only allowing this for
hardware which supports beacon filtering with support for checksumming
of the beacons. Reason checksumming is important is for considerations
of DFS with the channel switch announcements, HT with with channel width
changes. In fact I'm curious why checksumming would be required for 2.4 GHz
single band devices. Kalle, do you happen to know?
Considering that power saving features are important I think its worth
to revisit
this position in detail.
An alternative to this above position is that if the devices do not
support checksumming
of the beacons to let the driver figure when this should be enabled
dynamically. For example
if devices do not support checksumming but are single 2.4 GHz band
non-HT capable
devices we should let drivers enable this feature.
Other devices which do not support checksumming should only enable this only
when associating to an AP on non-DFS channels and when not using HT.
In practice this would mean allowing both ath5k and ath9k to take advantage
of this feature.
Technically we could move the conditional logic check when this should
be enabled
to mac80211 as well. When we reviewed this it was seen as unnecessary
complexity,
I actually don't see it as too complex and think the the advantage is
worth to consider.
Thoughts?
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
