In addition to this, we now need to know whether we need to send a short beacon or a long beacon. From the standard it states: 11.1.3.10.2: "The value for the dot11ShortBeaconPeriod shall be such that dot11BeaconPeriod = n * dot11ShortBeaconPeriod, where n is a positive integer. This defines a series of TSBTTs exactly dot11ShortBeaconPeriod TUs apart" the value for n here is what we are denoting as s1g_short_beacon_period (another deviation from the naming within the standard) which represents the number of short beacons between each long beacon. To keep track of the current state, we introduce a new parameter sb_count within the struct ps_data structure to track the current index into this period. This is what is used to determine whether we send a long or short beacon on beacon retrieval where a value of 0 indicates a long beacon (following the same cadence of decrementing the DTIM count). We have opted to place it in the struct ps_data since, fundamentally, it is a power save mechanism and is initialised using the same TSF value the DTIM count is initialised with as its very common for the short beacon DTIM period and short beacon period to be equal - so this ensures we initialise these values in sync. (4) Beacon retrieval There were essentially two options we could take with regards to retrieving the beacons: 1.implement it in the traditional beacon path via ieee80211_beacon_get_ap 2.Implement an S1G (or maybe extension frame?) specific path such as ieee80211_s1g_beacon_get_ap where the S1G specific handling can be done in its own function, leaving the regular beacon path untouched We have opted to take method (1) but this really comes down to maintainers preference. New conditionals will be introduced in the beacon path regardless and we feel this is the best approach but are open to feedback. (5) Testing This patchset has been tested on the following configurations: 1. Multi-sta setup with real Morse Micro hardware. 2. S1G hwsim configuration with a single AP and > 10 STAs 3. 2.4GHz hwsim configuration to test for regressions along the non-s1g path consisting of a single AP and STA. 4. hostapd hwsim tests were run to ensure no regression for regular 2.4/5/6 radios. (6) Other notes: 1. The update mechanism is not really that nice. Though that may stem from a misunderstanding with how FILS discovery and unsol bcast update mechanisms work. Since short beacons rely on a BSS to be configured we ensure that an update is only performed when this is the case, and when the BSS has not been configured we do not allow a set of parameters used for updating the beacon to be used when the BSS has not been initialised. Would like some feedback on our implementation here as Im not really convinved it's the right way, but it seems this is how we currently handle it. My understanding of an "update" is that we are updating an existing interface. When an interface is being initialised, we are not updating - we are setting... An option here is to just not even allow updates since this is how S1G is done now and this can be ammended in the future. 2. The power save patch (patch #3) is a bit ugly to split, so have kept as one as they are fundamentally related. Lachlan Hodges (5): wifi: cfg80211: support configuring an S1G short beaconing BSS wifi: mac80211: support initialising an S1G short beaconing BSS wifi: mac80211: configure power save for an S1G short beaconing BSS wifi: mac80211: support returning the S1G short beacon skb wifi: mac80211_hwsim: add S1G short beacon support drivers/net/wireless/virtual/mac80211_hwsim.c | 109 ++++++--- include/linux/ieee80211.h | 4 + include/net/cfg80211.h | 32 +++ include/net/mac80211.h | 17 ++ include/uapi/linux/nl80211.h | 32 +++ net/mac80211/cfg.c | 132 ++++++++++- net/mac80211/debugfs_netdev.c | 2 +- net/mac80211/ieee80211_i.h | 15 +- net/mac80211/mesh.c | 2 +- net/mac80211/tx.c | 115 ++++++++-- net/mac80211/util.c | 50 ++++- net/wireless/nl80211.c | 208 ++++++++++++++++++ 12 files changed, 661 insertions(+), 57 deletions(-) -- 2.43.0
