[ath9k-devel] [RFC/RFT] ath9k: support for multiple beacon intervals

[Adrian Chadd <adrian@freebsd.org>]

I say NACK (but like the idea), and here's why:

On 29 June 2011 06:12, Steve Brown <sbrown@cortland.com> wrote:
> This patch maintains a beacon interval for each beacon. The SWBA interrupts
> are based on the shortest interval of the active beacons.

It also includes changes to the beacon logic for Mesh, eg:

        * Can not configure station vif's beacon config
        * while on AP opmode
        */
       if ((sc->sc_ah->opmode == NL80211_IFTYPE_AP) &&
-           (vif->type != NL80211_IFTYPE_AP)) {
+           !(vif->type == NL80211_IFTYPE_AP ||
+             vif->type == NL80211_IFTYPE_MESH_POINT)) {
               ath_dbg(common, ATH_DBG_CONFIG,

there's a couple more sections like this.

So you've not only modified the driver to support >1 beacon interval,
but you've also changed how things are handled for IFTYPE_MESHPOINT.
Please split the patch up into (at least) two chunks so they can be
separately reviewed.

> This has been tested as a mesh access point with both AP and MESH
> on one interface.

Is mesh+ap on the same interface currently supported?

I like the idea, but as i've been knee-deep in the beacon handling
code recently, I can't help but wonder if there's corner cases that
need to be taken into account.
(Eg, if there's multiple STA interfaces with beacon miss interrupts
being generated, are you handling that case correctly so you don't
trigger bmiss incorrectly for STAs?)

Also, FreeBSD's 802.11s mesh mode support is implemented using hostap
mode in the NIC, versus adhoc mode (I only found this out yesterday.
:-) So your mode change may have unintended consequences.

It's not a bad idea though; I'd like it properly investigated and
tested though before a change like this makes it into the public tree.


Adrian