Wiphy is attached to pdev after pdev has been created, but before pdev
is opened. So maintain the state of wiphy in pdev open and close
callbacks. While calling regulatory callbacks, check the wiphy init
state.
Change-Id: I51243017ac24bc4473abddbfd0506b9e3490de4a
CRs-Fixed: 2718363
In 11ax draft 6.1, the 6G starting frequency has been shifted by 10 MHz
to the right from 5940 to 5950. Make the following changes in various
variables and structures in the regulatory component:
1. Add a macro SIX_GHZ_NON_ORPHAN_START_FREQ.
2. Add an orphan channel frequency - 5935 MHz to the chan enum.
3. Shift every enum in channel_enum by 10 MHz to the right.
4. Shift MIN_CHANNEL_6GHZ and MAX_CHANNEL_6GHZ by 10 MHz on the right.
5. Shift every center frequeny by 10 MHz on the right in
bonded_chan_40mhz_list_freq, bonded_chan_80mhz_list_freq,
bonded_chan_160mhz_list_freq.
6. Shift every center frequeny by 10 MHz on the right in channel_map_us,
channel_map_eu, channel_map_japan, channel_map_global and
channel_map_china channel maps.
7. Change 6G starting frequency from 5940 to 5950 for operating class
131 to 135 in the global_op_class table.
table.
8. Add operating class 136 in the global_op_class table.
Change-Id: I3c82e2eb98cdaf0ff8754bd990529a1833276304
CRs-Fixed: 2704977
Make reg_is_disable_for_freq and reg_is_disable_ch common for both WIN
and MCC, by moving the definition from reg_utils.c to
reg_services_common.c and declaration from reg_utils.h to
reg_services_common.h.
Change-Id: I6425c99b403580836d1ee41839086f4df3971091
CRs-Fixed: 2718047
Based on the latest update in the regulatory, update
frequency range 5170-5250 to indoor only for APL9 reg domain.
Change-Id: I7c52fc76b5a8d6a47d515025d05b110332347246
CRs-Fixed: 2707525
Place wlan_reg_is_6ghz_supported under CONFIG_REG_CLIENT macro as it
is an MCC specific API.
Also, within reg_update_pdev_wireless_modes, return QDF_STATUS_E_INVAL
if pdev_priv_obj is NULL.
Change-Id: I1ec23b2f44aec037ba99a2fd71812c8287c9f4dc
CRs-Fixed: 2704712
Use channel flags to determine DFS channel. Channel state is
set to CHANNEL_STATE_DFS even for passive channel.
Change-Id: I5ff88f05d2967f9e93de028d59d91369b66303c5
CRs-Fixed: 2695162
For agile scan request in 80 + 80 MHz check whether the user given
agile frequency forms a valid 80+80 channel.
CRs-Fixed: 2690964
Change-Id: Ia374333118d4f06861a1cfe0a75db349bca9e879
In the current implementation, Korea is mapped to channel_map_eu.
Korea is mapped to 5G regdomain APL9 which supports 80MHz channels
upto 161. However, the Europe opclass supports 80 MHz channels only
upto 128. As a result, when the AP tries to switch to the 80 MHz channel
149, the opclass validation logic finds this invalid and fills wrong
channel and opclass number in the ECSA IE. This leads the STA to
disconnect.
Fix this by mapping Korea to channel_map_global for Tx, which will map
it to the Global Operating Class by the following logic:
US Op Class Table : Countries having FCC DFS Region Eg: USA , Canada
EU Op Class Table : Countries having ETSI DFS Region Eg: Denmark
CN Op Class Table : Countries having China DFS Region Eg : China
JP Op Class Table : Countries having MKK DFS Region Eg : Japan
Global Op Class Table : All other countries
Change-Id: I5c6ff14888b218bc4fce707335ba53f60f579e19
CRs-Fixed: 2692802
FW advertises the 11AX wireless modes in service ready ext2 event.
Add a regulatory API to update these modes in regulatory psoc
private object.
Change-Id: I51e781f6819dabf2b98e129a996213a7eecbf8b2
CRs-Fixed: 2650136
As per regulatory update database xls, FCC4 supports 4.9GHz channels,
as well as 5G channels. But currently only 4.9GHz support is present.
Therefore, add the 5G reg_rules in FCC4's definition to support 5GHz
channels.
Change-Id: Ib71c01635f5aef18c4597ee3f699b5b033087112
CRs-Fixed: 2689729
Add new enum in regulatory to hold all current phymodes.
Add a new API to get max allowed phymode which is not more than the
user provided phymode.
This change simplifies the phymode selection process when starting
or updating the parameters of a vdev.
Change-Id: I12c15e357b80faf2f5272800e55179f02755a263
CRs-fixed: 2658290
The following 3 countries will not support 802.11ax:
1) Belarus
2) Russia
3) Ukraine
This change updates the phymode bitmap for those countries.
Change-Id: I8cd293341d82446cfb5f99eb912a925f4f3398b3
CRs-fixed: 2658290
In the current implementation the max_5g_bw was hardcoded as 160 MHz
in reg_get_max_5g_bw_from_regdomain, as this information was not
available in regdomains_5g so far.
However, the regdomains_5g table has been updated to make the maximum
5G bandwidth supported by the regdomain available. Hence updating this
information.
Change-Id: I9b9aea9a81b6b0d6f590c266e49a6b4ca3a9e32c
When RD ETSI11 is configued, 5G HT40 channels are getting built for
low band channel frequencies. As per regulatory update #31,
this is not allowed.
To fix this issue, add a new field max_bw that indicates the maximum
supported bandwidth by a regdomain. Add max_bw values for all 2G and
5G regdomains definitions. Also pick bandwidth between reg-domain's
max_bw and country's max_bw.
Change-Id: Ie0e9f9c7d9ae21eea2bc534626ef7a13602577bb
CRs-Fixed: 2682424
In reg_set_5g_channel_params_for_freq if the input channel
bandwidth is 5MHz then while getting the next lower bandwidth
out of bound access occurs.
Fix out of bound access in getting next lower bandwidth value.
Change-Id: Ice394e68e01a5fb4c8e4098395897a8d5a1d24a9
CRs-Fixed: 2680938
Add an API wlan_reg_get_phybitmap, to retrieve the phybitmap from the
regulatory pdev_priv_obj->phybitmap.
Change-Id: Ie03ab69b2378f7243bbacc15c71007cdf0386ef6
CRs-Fixed: 2675030
Update regdb with QCA regulatory database version 31 with following
changes:
1) Map Andorra to ETSI1_WORLD for WIN and DSRC, and ETSI13_WORLD for MCC.
2) Map Armenia to APL4_WORLD for WIN, and ETSI4_WORLD for DSRC and MCC.
3) Enable 40, 80 and 160 MHz BW support for Armenia.
4) Enable 40, 80 and 160 MHz BW support for Bahrain.
5) Add Indoor flag in lower bands for APL15.
6) Map Bolivia to FCC8_WORLD for WIN and FCC3_WORLD for MCC.
7) Map Brunei to FCC8_WORLD for WIN and FCC3_WORLD for MCC.
8) Map Ecuador to FCC3_FCCA for WIN and MCC.
9) Enable 40, 80 and 160 MHz BW support for Ecuador.
10) Map El Salvador to FCC3_WORLD for WIN and MCC.
11) Enable 40, 80 and 160 MHz BW support for El Salvador.
12) Map Japan to MKK17_MKKC for MCC and DSRC.
13) Map Kuwait to ETSI1_WORLD for WIN and ETSI13_WORLD for MCC and DSRC.
14) Map Sri Lanka to FCC3_ETSIC for WIN, MCC and DSRC.
15) Enable 40, 80 and 160 MHz BW support for Sri Lanka.
16) Map Yemen to ETSI1_WORLD for WIN, MCC and DSRC.
17) Enable 40, 80 and 160 MHz BW support for Yemen.
18) Remove 40/80/160 MHz channels support in ETSI11.
Change-Id: Ieba86cb99f6963432777cd6aaa6ffb6b3e72b657
CRs-Fixed: 2662186
If the country code is present, from the country code get the country
index in g_all_countries. Then get the maximum 5G bandwidth supported
by the country. Otherwise, from the regdomain pair value, get the max
5G bandwidth that is supported by that regdomain.
One of the applications of the maximum 5Ghz bandwidth is the following:
Build the 80P80 channels only if 160 MHz bandwidth is supported by the
country
Change-Id: I9e09fdc3a9a276c75f3fc709ee041a47ec812516
CRs-Fixed: 2673083
Match the type of the first parameter of the function
definition with the type of the first argument of function call.
CRs-Fixed: 2670065
Change-Id: Ifd9bd138caf5b3e0a547bc9a8bd2da38f0f8f675
The range given/provided by the FW (low_5g, hi_5g), may contain both
5Ghz IEEE channels and 6Ghz IEEE channels.
Add an API wlan_reg_is_range_only6g to check if the input low and
high channel frequencies are only in the 6Ghz frequency range, and also,
place the API changes under a macro CONFIG_6G_FREQ_OVERLAP. First find
out if 5Ghz and/or 6Ghz range are available. Then, by applying the
method of exclusion find out if the range provided by the FW is only a
6G range.
Change-Id: I29675a6520a27257f3d1c7424b7f0c94797244cc
CRs-Fixed: 2676307
Export wlan_reg_freq_width_to_chan_op_class_auto symbol
to be used in qca_ol module for retrieving opclass.
Change-Id: I44d9c424d66caf168d443f3542361deb9b3de300
The function reg_freq_width_to_chan_op_class calculates the channel
number and opclass to be filled in the ECSA IE. In this function,
there is a check if (op_class_tbl->start_freq + FREQ_TO_CHAN_SCALE
*op_class_tbl->channels[i] == freq)
In case of channel 14 in Japan opclass, since the start_freq =2407,
FREQ_TO_CHAN_SCALE=5 and channels[i] =14, this condition evaluates
to false and chan_num and opclass are not filled.
Fix this by setting the start_freq as 2414 as is done for the
global_op_class table.
Change-Id: I31b3720e4a74a3790275eb3d14b412b0366cbeba
CRs-Fixed: 2673001
Add an API wlan_reg_update_pdev_wireless_modes to update the wireless
modes in regulatory pdev_priv_obj with the wireless modes given as
input to it.
Change-Id: I2388b26da0d4c485b1b73b3ffb8f4b30767c31ee
CRs-Fixed: 2661579
Whether the firmware supports 6ghz channels, needs to be known
before pdev is created. Therefore move the check for 6ghz wmi
service support to psoc..
Change-Id: Iad7717225c49f6c95988f5ac81c7ee405b7c2c9e
CRs-Fixed: 2658111
This mode is supported through hw_mode_id 7. A special mode for
IPQ8074 platform alone to bring up single pdev alone on 2G mode.
FW would advertise the mode 7 support through the WMI service
ready message and this mode will be the default mode for AP-HK10 alone.
Added new APIs in tgt_reg to get pdev_id from phy_id and vice versa.
Fixed all places where pdev_id is used to acces psoc regulatory params
and converted them into use phy_id
Change-Id: I14920627f5e4ddafcc37440fa3281150b65ff04f
CRs-fixed: 2653042
As per IEEE 802.11 2016 specification Annex E Table E-5, add a new
operating class table for China.
Change-Id: I60d610d637c64df497c7c363a893b8f7efdc8a6c
CRs-Fixed: 2656789
Add the macros BW_5_MHZ, BW_10_MHZ, BW_20_MHZ, BW_25_MHZ, BW_40_MHZ
to denote channel width and define them as 5, 10, 20, 25 and 40
respectively.
Also rename the API wlan_reg_country_opclass_freq_check to
wlan_reg_is_freq_in_country_opclass.
Change-Id: I6838bd87a9b8d0754909cea414ada4b09ed01643
CRs-Fixed: 2646416
reg_get_psoc_obj may return NULL.
Add check if regulatory psoc is NULL and return QDF_STATUS_FAILURE.
CR-Fixed:2648152
Change-Id: I9637fa367873cd62fa18d1f5ecd80f6fe454558b
Currently whenever host gets an indication for the cc event
list, it starts 11d machine and inside 11d state machine,
it decides that whether host needs to send start 11d scan
command to fw or stop 11d scan command to fw, based on that it
updates the enable_11d_supp variable of regulatory psoc private
object and posts the message to scheduler.
FW expects that host should not send back to back 11d start
scan command, there should be one 11d stop scan command before
next 11d start scan command is sent if already one 11d start
scan command is sent.
Host 11d state machine takes care of the above sequence
of 11d scan command by using enable_11d_supp. 11d state machine
sets enable_11d_supp whenever 11d scan start command needs to
be sent and resets enable_11d_supp whenever 11d scan stop
command needs to be sent and posts the message in the scheduler.
There is a case where if host receives the 11d cc event from FW
it sends the set country command to FW and at the same time if
user command comes to set the country, host again sends the set
country command to FW. FW processes both of these commands and
sends the cc list event to host. when host receives cc events
it starts the 11d machine. For the first cc event which is for
11d country which is processed as user country because of
incorrect logic in reg process master channel list where it is
assumed that at a time only one type of country set command can
be pending and first priority is given to the user country pending,
host resets enable_11d_supp and post the command to scheduler.
When host receives the cc list event for the user country it is
processed as 11d country and inside 11d state machine it sets
enable_11d_supp and posts the command to scheduler.
Now if scheduler schedules these commands it treats both the
commands as start 11d scan commands as enable_11d_supp is set
and sends start 11d scan command back to back.
To avoid above issue, add enable_11d_supp also as part of
the scheduler msg body pointer along with the psoc, in she
scheduler callback use this local variable to decide whether
11d start scan needs to be sent or 11d stop scan needs to be
sent.
Change-Id: I60150da1475251a1c22778a0f924bdfbe1bb1140
CRs-Fixed: 2641803
According to Annex E of 802.11 specification (Table E-1—Operating classes
in the United States) add opclass support for HT40 channel 140 and
144 in us_op_class map. Currently for HT40 channels 140 and 144,
us_op_class map does not have a valid entry and hence opclass is
fetched as 0.
CRs-Fixed: 2626714
Change-Id: I848d6266c829c363f353de9911359349c379126b
When the operating class 82 is given as an input to the function
reg_get_band_cap_from_op_class, it is not found due to an
incorrect conditional logic that checks the starting frequency of a
band.
To address this problem, add a function
reg_get_band_cap_from_chan_set and call it within the function
reg_get_band_cap_from_op_class, to check if a channel in the channel
set, is within the frequency range of the band.
Change-Id: I7cbd8decf3c19f80e60a3153529b622b144feac9
CRs-Fixed: 2636367
When regdb is non offload, it invokes ucfg_reg_program_default_cc
to initialize the default country code. Because the num_phy is not
initialized and the country code source cannot not initialize
properly in function reg_process_master_chan_list, 11d cannot be
triggered.
Solve the problem mentioned above by initializing num_phy in
reg_program_default_cc. Since it is non-offload, initialize
num_phy to 1.
CRs-Fixed: 2584347
Change-Id: Idaed2badc908c74bcbb9312368fed8cbb71ac69c
For 6G band, only valid opclass_table is the global_op_class
as per the current specification. Therefore, if the band is 6G
set the opclass to global_op_class instead of the default class.
Change-Id: I43d1be8266aa80b11c446d84bc3d027cde8bebea
If reg offload is disabled, then ignore the processing of
WMI_REG_CHAN_LIST_CC_EVENTID in regulatory module.
Change-Id: I5da0cdf2c80357d03199fa367137cc236f4c3307
CRs-Fixed: 2625784
Add the API wlan_reg_get_band_cap_from_op_class to get the supported
band capability from an list of operating class as input.
Change-Id: I58dc0bbe7c5436b889c12ac2d68bd769a3c702cf
CRs-fixed: 2617526
Add wlan regulatory API reg_country_chan_opclass_to_freq
to calculate channel frequency given country, opclass and channel
number. The API gets channel frequency from country's operating
class table by opclass and channel number pair. If the driver
can not find the pair, then try to find the frequency (MHz) by
channel number only.
Change-Id: I6a23a53e2e53e0b7c81b36f9f5c7794e9749c734
CRs-Fixed: 2605920
Auto BW computes new bandwidth for adjacent regulatory rules. But this
combined bandwidth can be more than the bandwidth allowed for a
particular reg-domain. So relax the check for combined BW for
adjacent regulatory rules.
Change-Id: I1486988c114f0348f7228b91aeadc5c027c6a510
CRs-Fixed: 2626165
Regulatory rules cannot have maximum bandwidth more than the
width of the rule. Fix this logic for six ghz regulatory rules.
Change-Id: Icbd4eb95d4de54acaef0aa635c293451ba4e1987
CRs-Fixed: 2620699
Fix compilation error in reg_country_opclass_freq_check
return false when HOST_OPCLASS is disabled.
Change-Id: Ib03e544311ae0a6c3496711f303ad17d490900ba
CRs-Fixed: 2624546
For the 6G band, the only valid opclass_table is the global_op_class
as per the current specification. Therefore, if the band is 6G set the
opclass to global_op_class instead of the default us_op_class.
As per specification for chan width 40 MHz, there is no behav limit
for both Low Primary and High Primary channels. Hence, set behav limit
as BIT(BEHAV_NONE) if channel width is 40 MHz.
Change-Id: I534f5b898e10cf21042a117aa71e824a85d73fb3
CRs-Fixed: 2608059
Currently the conversion APIs used doesn't take into account
the overloading of channel numbers between 6GHz, 5GHz and 2.4GHz
bands.
Add support to obtain the correct channel number (and auxiliary
information like band and frequency) through the new APIs that
support all three bands.
Change-Id: Ief417f14620bc2fc02d76fea3642b6fbb9615916
CRs-Fixed: 2610378
Given country from country IE and operating class, check
whether a channel frequency belongs to that pair.
Change-Id: I9bf711b2c52ad230a3066113a5aa7b8959219754
CRs-Fixed: 2620767
In a SON WFA testcase, the QCA AP advertises the channel set in
operating class 128 as individual IEEE channel number (for eg. 36, 40,
44, 48 etc.) instead of center channel (for eg. 42, 58, 106 etc.) to
the third party AP.
As a result, the third party AP creates Front Haul VAPs in High Band
radio when the QCA AP is configured to Low Band, due to incorrect
channel set advertised to it.
To fix this issue, add an API reg_get_chan_or_chan_center to
calculate the center channel number for a 80MHz, 80_80 MHz and 160
MHz bandwidth channel, and use it to calculate the center channel
number within the channel set for a particular operating class in the
operating class table.
Change-Id: Idf7df70c8d01ed79b43d0ba21db7b07189f3f710
CRs-Fixed: 2612258
