Am 26.02.2013 22:31, schrieb Thomas Pedersen:
Hi Marco,
On Mon, Feb 25, 2013 at 8:00 AM, Marco Porsch<marco@xxxxxxxxxxx> wrote:
Move the beacon handler into mesh_neighbour_update where the STA
pointer is already available. This avoids additional overhead
and simplifies the handler.
The repositioning will also benefit mesh PS which uses T_r and
the updated T_offset value.
Check frame type before calling the handler. Rename it to better
reflect its purpose.
Signed-off-by: Marco Porsch<marco@xxxxxxxxxxx>
---
v3:
check frame type before rx_bcn handler (Johannes)
net/mac80211/ieee80211_i.h | 9 ++++-----
net/mac80211/mesh.c | 7 +------
net/mac80211/mesh.h | 4 +++-
net/mac80211/mesh_plink.c | 38 ++++++++++++++++++++++++++++-------
net/mac80211/mesh_sync.c | 47 +++++++++-----------------------------------
5 files changed, 48 insertions(+), 57 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 388580a..631760f 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -529,11 +529,10 @@ struct ieee80211_if_ibss {
*/
struct ieee802_11_elems;
struct ieee80211_mesh_sync_ops {
- void (*rx_bcn_presp)(struct ieee80211_sub_if_data *sdata,
- u16 stype,
- struct ieee80211_mgmt *mgmt,
- struct ieee802_11_elems *elems,
- struct ieee80211_rx_status *rx_status);
+ void (*rx_bcn)(struct sta_info *sta,
+ struct ieee80211_mgmt *mgmt,
+ struct ieee802_11_elems *elems,
+ u64 t_r);
Why not continue to sync against probe responses?
mesh_neighbour_update() gets these as well.
Because there was a comment about the standard mentioning only beacon
frames. Fooled me here =/
Now I see that the standard explicitly mentions probe responses as well.
Is the sync code currently ready to handle probe responses? I am not
perfectly sure about the sta->t_offset_setpoint stuff.
--Marco
--
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
