From: Marco Porsch Date: Thu, 31 Jan 2013 16:28:25 +0100 Subject: [ath9k-devel] [RFC 1/3] mac80211: move mesh sync beacon handler into neighbour_update In-Reply-To: <1359639780.8415.23.camel@jlt4.sipsolutions.net> References: <1358936360-7795-1-git-send-email-marco@cozybit.com> <1358936360-7795-2-git-send-email-marco@cozybit.com> (sfid-20130123_111931_474759_EEC1974B) <1359639780.8415.23.camel@jlt4.sipsolutions.net> Message-ID: <510A8D99.8050709@cozybit.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 01/31/2013 02:43 PM, Johannes Berg wrote: > On Wed, 2013-01-23 at 11:19 +0100, Marco Porsch 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 the >> T_offset value right after it has been updated. >> >> Rename the handler to better reflect its purpose. >> >> Signed-off-by: Marco Porsch >> --- >> net/mac80211/ieee80211_i.h | 10 +++++----- >> net/mac80211/mesh.c | 8 ++------ >> net/mac80211/mesh.h | 5 +++-- >> net/mac80211/mesh_plink.c | 16 ++++++++++++--- >> net/mac80211/mesh_sync.c | 47 +++++++++++++++----------------------------- >> 5 files changed, 39 insertions(+), 47 deletions(-) >> >> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h >> index d77d3f7..e08b4c0 100644 >> --- a/net/mac80211/ieee80211_i.h >> +++ b/net/mac80211/ieee80211_i.h >> @@ -560,11 +560,11 @@ 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, >> + struct ieee80211_rx_status *rx_status, >> + u64 tsf); > > Is anyone actually planning to add more sync ops? I'm tempted to just > remove the entire abstraction here, since there's only a single concrete > implementation. No plans to do so as of now. But since mesh networks are still a research topic, there may already be researchers somewhere, happy to have that extensible interface. Also the standard explicitly defines an "Extensible synchronization framework" in 13.13.2. --Marco