| Message ID | 20200831205600.21058-1-thomas@adapt-ip.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | add support for S1G association | expand |
On Mon, 2020-08-31 at 13:55 -0700, Thomas Pedersen wrote: > > Note the mac80211_hwsim S1G support introduces a regression in a few > hostap hwsim tests. This is because when processing the reported bands, > hostap assumes freq < 4000 is 11b, and the actual 11b/g band is > overwritten by the S1G band info. Though it does count as a userspace > regression, I'm not sure there is much to do about it besides apply a > small patch to hostapd which treats freq < 2000 as an unknown band. > > After the hostap workaround > (https://lists.infradead.org/pipermail/hostap/2020-August/038748.html), > these patches continue to pass the hwsim tests as well as HEAD. That sounds like we could "hack around" it by sending the S1G data first, and then the 2.4 GHz, so the latter overwrites it on broken versions? Not sure it's worth it though, I'd say it depends a bit on what real hardware plans are? I mean, if it's only hwsim for now ... who cares? And if it's going to be special hardware that only does S1G, then also meh, you need newer versions to support it, big deal. But if OTOH a commonly used chipset like e.g. ath9k or ath10k will get S1G support, then that'd be more relevant? johannes
On 2020-09-06 09:04, Johannes Berg wrote: > On Mon, 2020-08-31 at 13:55 -0700, Thomas Pedersen wrote: >> >> Note the mac80211_hwsim S1G support introduces a regression in a few >> hostap hwsim tests. This is because when processing the reported >> bands, >> hostap assumes freq < 4000 is 11b, and the actual 11b/g band is >> overwritten by the S1G band info. Though it does count as a userspace >> regression, I'm not sure there is much to do about it besides apply a >> small patch to hostapd which treats freq < 2000 as an unknown band. >> >> After the hostap workaround >> (https://lists.infradead.org/pipermail/hostap/2020-August/038748.html), >> these patches continue to pass the hwsim tests as well as HEAD. > > > That sounds like we could "hack around" it by sending the S1G data > first, and then the 2.4 GHz, so the latter overwrites it on broken > versions? Yes that could work. > Not sure it's worth it though, I'd say it depends a bit on what real > hardware plans are? > > I mean, if it's only hwsim for now ... who cares? And if it's going to > be special hardware that only does S1G, then also meh, you need newer > versions to support it, big deal. AFAIK there are no multi-band S1G chips. The initial focus (from WFA) seems to be industrial IOT. > But if OTOH a commonly used chipset like e.g. ath9k or ath10k will get > S1G support, then that'd be more relevant?
This is the initial S1G patchset which adds support for: - defining the S1G 900MHz bands in a custom regulatory database - setting and receiving S1G beacons (sending short beacons will be supported in a future patch) - configuring S1G capabilities in Association Request (setting capabilities along with NL80211_CMD_SET_STATION will be added later). - scanning on S1G bands - handling S1G Association Response format - correctly encoding Listen Interval for S1G - associating in mac80211 - testing S1G in mac80211_hwsim Rate control is still TBD, this patchset simply lops off the rate control hooks for S1G so eg. missing sband->bitrates and S1G Basic Rate set can't do too much damage. Note the mac80211_hwsim S1G support introduces a regression in a few hostap hwsim tests. This is because when processing the reported bands, hostap assumes freq < 4000 is 11b, and the actual 11b/g band is overwritten by the S1G band info. Though it does count as a userspace regression, I'm not sure there is much to do about it besides apply a small patch to hostapd which treats freq < 2000 as an unknown band. After the hostap workaround (https://lists.infradead.org/pipermail/hostap/2020-August/038748.html), these patches continue to pass the hwsim tests as well as HEAD. Thomas Pedersen (22): ieee80211: redefine S1G bits with GENMASK nl80211: advertise supported channel width in S1G cfg80211: regulatory: handle S1G channels nl80211: correctly validate S1G beacon head nl80211: support setting S1G channels {cfg,mac}80211: get correct default channel width for S1G mac80211: s1g: choose scanning width based on frequency nl80211: support S1G capabilities mac80211: support S1G STA capabilities cfg80211: convert S1G beacon to scan results cfg80211: parse S1G Operation element for BSS channel mac80211: convert S1G beacon to scan results cfg80211: handle Association Response from S1G STA mac80211: encode listen interval for S1G mac80211: don't calculate duration for S1G mac80211: handle S1G low rates mac80211: avoid rate init for S1G band mac80211: receive and process S1G beacons mac80211: support S1G association nl80211: include frequency offset in survey info mac80211_hwsim: indicate support for S1G mac80211_hwsim: fix TSF timestamp write to S1G beacon drivers/net/wireless/mac80211_hwsim.c | 92 +++++++++-- include/linux/ieee80211.h | 223 +++++++++++++++++--------- include/net/cfg80211.h | 28 ++++ include/net/mac80211.h | 3 + include/uapi/linux/nl80211.h | 26 +++ net/mac80211/cfg.c | 2 + net/mac80211/chan.c | 9 +- net/mac80211/ibss.c | 3 +- net/mac80211/ieee80211_i.h | 20 +++ net/mac80211/iface.c | 5 + net/mac80211/mlme.c | 184 +++++++++++++++++---- net/mac80211/rate.c | 39 ++++- net/mac80211/rx.c | 87 +++++----- net/mac80211/scan.c | 37 ++++- net/mac80211/tx.c | 4 + net/mac80211/util.c | 200 +++++++++++++++++++++++ net/wireless/chan.c | 140 ++++++++++------ net/wireless/mlme.c | 20 +++ net/wireless/nl80211.c | 52 +++++- net/wireless/reg.c | 70 ++++++-- net/wireless/scan.c | 80 +++++++-- net/wireless/util.c | 32 ++++ 22 files changed, 1090 insertions(+), 266 deletions(-)