6 GHz introduces various power modes of operation. Currently, based
on the power mode, channel's Power Spectral Density (PSD) value,
Regulatory power value, as well as channel disabled flag can change.
For single interface, current implementation works just fine. But for
multi-interfaces, for example AP-STA concurrency, two different channel
context needs to be maintained. This is because, STA power mode also
depends on the AP's power mode it is going to associate with. Hence,
PSD value, regulatory power value and channel disabled flag might vary.
In this case, same channel context cannot be used for both AP and STA.
Therefore, to support multiple channel space for each power mode, the
6 GHz channels needs a separate storage space in data structure
ieee80211_supported_band. Because of this, the existing APIs to get the
channel/frequency from frequency/channel will not work for 6 GHz band.
Add support to store all possible 6 GHz channel pools according to the
power mode as well as add API support for getting channel/frequency info
from the new struct ieee80211_6ghz_channel.
Why different channel pools and not array of varying member in the same channel?:
--------------------------------------------------------------------------------
Let (A) be the implementation of having separate channel
pools based on power mode:
[...]
struct ieee80211_6ghz_channel {
struct ieee80211_channel *channels;
int num_channels;
};
struct ieee80211_supported_band {
/* Other members */
struct ieee80211_6ghz_channel[MAX_POWER_MODE];
/* Other members */
}
[...]
After updating the regulatory rules, in case of (A), all the channels
stored in the struct ieee80211_6ghz_channel will have its desired
value based on the power mode.
Let the alternate implementation be (B) which maintains array of such variables
which can vary based on power mode:
[...]
struct ieee80211_channel {
/* Other members*/
u32 flags[MAX_POWER_MODE];
int max_reg_power[MAX_POWER_MODE];
s8 psd[MAX_POWER_MODE];
/* Other members*/
}
[...]
After updating the regulatory rules in case of (B), for 6 GHz sband channels,
all the values based on the power mode are stored in array for each channel.
During 6 GHz interface bring up, power mode will be known and in
method (A), accordingly the corresponding ieee80211_channel will
be selected from the pool. With this, all its members are having
the desired value stored in them just like any other ieee80211_channel.
For method B, ieee80211_channel will be selected, but its members are
having array of possible values. Even though configured power mode is
known, still, the members dont have the exact required value.
Now, as per the code flow, a pointer for the configured channel
is stored in chandef and thats parsed to extract the required information
like flags, power, frequency information, etc.
If current implementation (A) is followed then the subsequent functions
using the set ieee80211_channel will need not be modified since the exact
required values based on the power mode is applied to its members
already and everything will fall in its place.
But if method (B) is used, then in all subsequent functions using the
configured ieee80211_channel, condition check on power mode and then
accordingly using the appropriate values from the array needs to be
implemented at each single place.
Hence, method (B) would require code changes at a lot of places leading to
more possiblity of errors to come in.
Also, currently only flags, power and PSD value is changing based on
power mode. If later on any new member or exisiting member is varyed
then with method (A), less code changes will be required since altering
the ieee80211_channel struct would do. But if method (B) is used then
apart from altering ieee80211_channel struct, all functions using
ieee80211_channels needs to be modified accordingly to fecth this new varying
member from correct power mode index.
Aditya Kumar Singh (8):
wifi: mac80211: rework on 6 GHz power type definition
wifi: mac80211: add combined power type definition for 6 GHz
wifi: cfg80211: add NL command to set 6 GHz power mode
wifi: mac80211: add support for 6 GHz channels and regulatory
wifi: cfg80211: rework nl80211_parse_chandef for 6 GHz
wifi: cfg80211: save 6 GHz power mode of the regulatory rules
wifi: cfg80211: fix chandef identical logic for 6 GHz chandefs
wifi: mac80211: use proper API to fetch 6 GHz channel
Wen Gong (1):
wifi: cfg80211: save Power Spectral Density (PSD) of the regulatory
rule
---
v3: - resolved sta mode association issue and AP-STA concurrency bring up
* added patch 8 to handle concurrent AP-STA bring up on 6 GHz
* added patch 9 to handle bss assoc in 6 GHz
- no other changes in patches 1-7 from v2.
v2: addressed v1 review comments.
* moved variables to link specific w.r.t MLO
* rebased on latest ToT
* added "wifi:" tag in commit title.
---
include/linux/ieee80211.h | 33 +++---
include/net/cfg80211.h | 111 ++++++++++++++++++--
include/net/regulatory.h | 2 +
include/uapi/linux/nl80211.h | 61 +++++++++++
net/mac80211/cfg.c | 41 ++++++++
net/mac80211/ieee80211_i.h | 3 +
net/mac80211/mlme.c | 14 ++-
net/mac80211/scan.c | 15 ++-
net/mac80211/util.c | 40 ++++++-
net/wireless/ap.c | 2 +
net/wireless/nl80211.c | 196 ++++++++++++++++++++++++++++++-----
net/wireless/nl80211.h | 3 +-
net/wireless/pmsr.c | 8 +-
net/wireless/rdev-ops.h | 21 ++++
net/wireless/reg.c | 61 +++++++++--
net/wireless/sme.c | 2 +
net/wireless/trace.h | 34 ++++++
net/wireless/util.c | 87 ++++++++++++++++
18 files changed, 671 insertions(+), 63 deletions(-)
base-commit: 4eca8cbf7ba83c3291b5841905ce64584036b1ff
--
2.17.1
