1. Update (or) Add the following country mapping to regdomain for 6 GHz.
i) Update 6 GHz_MKK1_VLP power to 1dBm/MHz (PSD) and 14dBm (Total)
ii) Update 6 GHz RD Defs "6g_APL5_VLP" to support only 5925-6425 (UNII-5)
band.
iii) Create 6g_APL5_CLIENT_LPI_DEFAULT (Hex code : 0x31) and 6g_APL5_AP_LPI
(Hex code : 0x32).
iv) Create Full 6 GHz reg domain Hex code 0x13 and mapped to CHILE.
v) Map full 6 GHz reg domain HEX CODE 03 to UNITED KINGDOM territory
countries: FALKLAND_ISLANDS, GIBRALTAR, GUERNSEY, ISLE_OF_MAN, JERSEY,
MONTSERRAT, VIRGIN_ISLANDS_BRITISH.
vi) Map full 6 GHz reg domain Hex code 02 to countries: GEORGIA, HOLY_SEE,
ITALY, TURKEY, GREECE, LATVIA, LUXEMBOURG, POLAND, SAN MARINO, SLOVAKIA,
SLOVENIA, SRI_LANKA.
vii) Create 6g_FCC3_VLP (Hex code : 0x06).
viii) Create Full 6 GHz reg domain Hex code 0x14 and mapped to
DOMINICAN_REPUBLIC.
ix) Update 6 GHz subdomain name from "6g_FCC2_SP" to "6g_FCC2_AP_SP"
x) Create 6g_FCC2_CLIENT_SP (Hex code : 0x07) and add to full 6 GHz
regdomain hex code 0x10.
xi) Map Full 6 GHz Reg domain Hex code 01 to GRENADA
2. Add or update the following regulatory database (2.4/5 GHz) for all.
i) Create new 5 GHz regdomain FCC20 (Hex 0x0B75) and Full 2 & 5 GHz
regdomain FCC20_FCCA (0xEF).
ii) Update CHILE from FCC13_WORLD to FCC20_FCCA
iii) Remove indoor flag from ETSI13 UNII-1.
iv) Remove indoor flag from ETSI18 UNII-1.
v) Create new 5 GHz Regdomain ETSI20 (Hex 0x0E46) and full 2 & 5 GHz
regdomain ETSI20_WORLD (0x7C).
vi) Update APL14 CTL map to CHINA CTL.
vii) Update APL9 CTL map to KOREA CTL.
viii) Create new 5 GHz regdomain APL29 (Hex 0x1234) and Full 2 & 5 GHz
regdomain APL29_ETSIC (0x77).
ix) Update GUATEMALA from APL19_ETSIC to APL29_ETSIC.
3. Update or Add the following regulatory database(2.4/5 GHz) only for WIN
i) Map from ETSI13_WORLD to ETSI20_WORLD to countries: BOTSWANA, BURUNDI,
CONGO_DEMOCRATIC_REPUBLIC, KENYA, LAO_PEOPLES_DEMOCRATIC_REPUBLIC,
RWANDA, SAUDI_ARABIA, SOUTH_AFRICA, UAE, ZAMBIA.
ii) Map CHINA from APL14_WORLD to APL14_CHNA.
iii) Map KOREA_ROC from APL9_MKKC to APL9_KRRA
4. Update or Add the following regulatory database(2.4/5 GHz) only for
Linux Android
i) Map from ETSI13_WORLD to ETSI18_WORLD to the following countries:
FALKLAND_ISLANDS, GUERNSEY, ISLE_OF_MAN, JERSEY, MONTSERRAT,
SAINT_HELENA_ASCENSION_AND_TRISTAN_DA_CUNHA, VIRGIN_ISLANDS_BRITISH.
ii) Map GIBRALTAR county from ETSI1_WORLD to ETSI18_WORLD.
iii) Map from ETSI13_WORLD to ETSI20_WORLD to the following countries:
ALBANIA, BOSNIA_AND_HERZEGOWINA, BOTSWANA, BURUNDI,
CONGO_DEMOCRATIC_REPUBLIC, KENYA, LAO_PEOPLES_DEMOCRATIC_REPUBLIC,
MACEDONIA, MAURITIUS, MOLDOVA, -MONACO-, MONTENEGRO, RWANDA, SAUDI_ARABIA,
SERBIA, SOUTH_AFRICA, TURKEY, UAE, ZAMBIA.
iv) Map CHINA from APL14_WORLD to APL14_CHNA.
v) Map KOREA_ROC from APL9_MKKC to APL9_KRRA.
5. Update or Add the following regulatory database(2.4/5 GHz) only for DSRC
i) Map ETSI20_WORLD to the following countries: ALBANIA,
BOSNIA_AND_HERZEGOWINA, BOTSWANA, BURUNDI, CONGO_DEMOCRACTIC_REPUBLIC,
KENYA, LAO_PEOPLES_DEMOCRATIC_REPUBLIC, MACEDONIA, MAURITIUS, MOLDOVA,
RWANDA, SAUDI ARABIA, SERBIA, SOUTH_AFRICA, TURKEY, UAE, ZAMBIA.
ii) Map CHINA from APL14_WORLD to APL14_CHNA.
iii) Map KOREA ROC from APL9_MKKC to APL9_KRRA.
6. Update or Add the following regulatory database(2.4/5 GHz) only for Auto
i) Create new 5 GHz Regdomain MKK18 (Hex 0x1660) and Full 2 & 5 GHz
regdomain MKK18_MKKC (0xEE).
ii) Update Japan from MKK17_MKKC to MKK18_MKKC.
iii) Create new 5 GHz Regdomain FCC21 (Hex 0x0B76) and Full 2 & 5 GHz
regdomain FCC21_ETSIC (0xD2).
iv) Update BRAZIL from FCC18_ETSIC to FCC21_ETSIC.
v) Create new 5 GHz Regdomain ETSI21 (Hex 0x0E47) and Full 2 & 5 GHz
regdomain ETSI21_WORLD (0x7D).
vi) Map ETSI21_WORLD to the following countries: ALAND_ISLANDS, ANDORRA,
AUSTRIA, BELGIUM, BULGARIA, CROATIA, CYPRUS, CZECH, DENMARK,
ESTONIA, FALKLAND_ISLANDS, FAROE_ISLANDS, FINLAND, FRANCE, FRENCH_GUIANA,
FRENCH_POLYNESIA, FRENCH, SOUTHERN_TERRITORIES, GERMANY, GREECE, GUERNSEY,
HOLY_SEE, HUNGARY, ICELAND, IRELAND, ISLE_OF_MAN, ITALY, JERSEY, LATVIA,
LIECHTENSTEIN, LITHUANIA, LUXEMBOURG, MALTA, MARTINIQUE, MAYOTTE,
MONTSERRAT, NETHERLANDS, NETHERLANDS-ANTILLES, NEW_CALEDONIA, NORWAY,
POLAND, PORTUGAL, REUNION, ROMANIA,
SAINT_HELENA_ASCENSION_AND_TRISTAN_DA_CUNHA, SAINT_PIERRE_AND_MIQUELON,
SAN_MARINO, SINT_MAARTEN, SLOVAKIA, SLOVENIA, SPAIN,
SVALBARD_AND_JAN_MAYEN, SWEDEN, SWITZERLAND, UNITED_KINGDOM,
VIRGIN_ISLANDS_BRITISH.
vii) Map from ETSI13_WORLD to ETSI20_WORLD to the following countries:
ALBANIA, BOSNIA_AND_HERZEGOWINA, BOTSWANA, BURUNDI,
CONGO_DEMOCRACTIC_REPUBLIC, KENYA, LAO_PEOPLES_DEMOCRATIC_REPUBLIC,
MACEDONIA, MAURITIUS, MOLDOVA, -MONACO-, MONTENEGRO, RWANDA, SAUDI_ARABIA,
SERBIA, SOUTH_AFRICA, TURKEY, UAE, ZAMBIA.
viii) Map CHINA from APL14_WORLD to APL14_CHNA.
ix) Map KOREA_ROC from APL9_MKKC to APL9_KRRA.
Change-Id: I77c4da2f48005619b888281c034e49f28bb584e4
CRs-Fixed: 3421200
Add a new cfg item to drop connection request if
AP is operating in 6 GHz SP mode and STA doesn't
support SP mode but supports VLP mode.
Change-Id: Icbe109abecdd73ceedee8ecec45ae82cd47464e0
CRs-Fixed: 3470599
Find the best 6 GHz power type for connection
according to following regulatory policy:
1) SP power type is selected only if AP advertises
SP and client supports SP.
2) LPI power type is selected only if AP advertises
LPI and client supports LPI.
3) VLP power type is selected for the below cases,
a) AP advertises VLP and client supports VLP
b) AP advertises SP but client doesn't support
SP but supports VLP.
c) AP advertises LPI but client doesn't support
LPI but supports VLP.
Change-Id: I6e3b9fc4bf7445c58681ef0ea8e45b434851a5b6
CRs-Fixed: 3456182
Currently host only fills LPI rules in pdev_priv_obj. If
country supports VLP, SP then host doesn't fill these
reg rules and advertises the same to kernel. This results
in zero 6 GHz channels in scan list shared by kernel.
To address this issue, fill LPI rules or VLP rules or
SP rules as per availability.
Change-Id: I4c00009d6124a1cd1371c7ac537186e79e51beb6
CRs-Fixed: 3470612
Correct reg rules for CC GB.
a. Change CHAN_5250_5330_16 to CHAN_5250_5330_12 to mark
radar frequency range.
b. Change CHAN_5735_5875_7 to CHAN_5735_5875_4 and to remove
radar marking.
Change-Id: Ie82e64fa444b6bcca3a6a31cb419179081e1c669
CRs-Fixed: 3447292
Below code changes are made
1. Correct 5 GHz reg rules for APL 26/27 RDs.
i. APL26 changes
a. CHAN_5170_5330_3 is split into CHAN_5170_5250_8 and
CHAN_5250_5330_12 To mark missing radar frequency range.
b. CHAN_5490_5730_3 changed to CHAN_5490_5730_5 to mark the
frequency range as radar indication range.
ii. APL27 changes
a. CHAN_5250_5330_10 and CHAN_5490_5730_4 are changed to
CHAN_5250_5330_7 and CHAN_5490_5730_1 respectively to mark the
frequency range as radar indication range.
2. Remove duplicate entry CHAN_5735_5835_8 (duplicate of CHAN_5735_5835_1)
Change-Id: Ib9d0e7455d489451da8beb71175e9a9b4ff6d3ca
CRs-Fixed: 3447101
Correct 5 GHz channels reg rule for CC PK.
a. Split CHAN_5170_5330_3 into CHAN_5170_5250_8 and CHAN_5250_5330_12
to mark missing radar frequency range mark.
b. Change CHAN_5735_5875_8 to CHAN_5735_5875_3 to change regulatory
power value to 30.
Change-Id: I48027de034a0cf39fe8135ffdb180b8b3fcf133e
CRs-Fixed: 3459453
Correct wrong frequency mapping for APL25 RD.
a. CHAN_5170_5330_3 is split into CHAN_5170_5250_8
and CHAN_5250_5330_12 to mark missing radar frequency
range.
b. CHAN_5490_5730_9 is split into CHAN_5490_5590_4 and
CHAN_5650_5730_4 to mark the frequency range as radar
indication range.
c. Remove unused reg rule CHAN_5490_5570_1
Change-Id: Iabeba570c1c0edde9221db9bc38beac59de6e179
CRs-Fixed: 3447198
In the AFC Enterprise mode, the AFC response-payload may need to be
reset from host. The payload reset is done by sending
WMI_SERVICE_AFC_RESET_SUPPORT subtype in the WMI_AFC_CMD to the target.
In response, the target sends the WMI_AFC_EVENT_TIMER_EXPIRY event with
WMI_AFC_EXPIRY_EVENT_SWITCH_TO_LOW_POWER_MODE (in indoor deployment) or
WMI_EXPIRY_EVENT WMI_AFC_EXPIRY_EVENT_STOP_TX (in outdoor deployment)
event subtype to the host.
Earlier, the WMI_AFC_EVENT_TIMER_EXPIRY event was sent only in
non-enterprise mode. Now, since it can be sent for both enterprise and
non-enterprise mode, we need to take care of 'afc_reg no action",
which is mandatory in case of enterprise mode.
Therefore, implement the following changes:
1) Call trigger_acs_for_afc only if afc_reg_no_action is not set.
2) Send the AFC payload reset event during SWITCH_TO_LPI and STOP_TX
event, and free the AFC payload received from the target.
3) Add APIs to register a callback to send the AFC payload reset event.
Change-Id: Ib5b3a6f51bbdf2061460fd957ca3c0ba66f23fa9
CRs-Fixed: 3462953
Export the wlan_reg_freq_width_to_chan_op_class() API.
API will be used by Change Id I69106463a587bf0717dbce3067b69bb7272ca976.
Change-Id: I3c751ccd6499bc0de48bdbb6086cf3ec7c8e9b88
CRs-Fixed: 3443845
When we receive a negative EIRP value from AFC APP with UINT, we treat it
as a positive value. See the following reasons why EIRP power value
was changed when we received it as a UINT.
1. In the reg_find_eirp_in_afc_eirp_obj function, the afc 'eirp_power'
(16-bit) value is in units of 0.01, and it is an unsigned integer. For
example, if the negative value is "-1400" then it becomes "64136". With
this value, when we try to get the original EIRP value using division
(eirp_obj->eirp_power / EIRP_PWR_SCALE(100)), it returns "641", but the
expected EIRP value is -14.
2. In the reg_get_sp_eirp function, both the variables 'afc_eirp_pwr'
(8-bit) and 'reg_sp_eirp_pwr'(16-bit) are declared as unsigned integers.
For example, when "-14," is assigned to "afc_eirp_pwr", it becomes "242".
And assuming 'reg_sp_eirp_pwr' is "36", the minimum of the two variables,
using QDF_MIN(afc_eirp_pwr, reg_sp_eirp_pwr), becomes "36", but the
expected minimum is "-14 or 242".
Process the positive or negative EIRP values that are received from AFC
application. Receive it as an int instead of an unint and typecast it to
int when we check for minimum value from afc power and standard power.
Change-Id: I255225e1f68ab897d36f3d4fbd5e5815a862460b
CRs-Fixed: 3398501
Export wlan_reg_get_freq_range() and wlan_reg_get_freq_range() APIs
to be invoked by other modules.
Change-Id: I2de7acf395011bdcc20100fc5980ab69f2b9fbeb
CRs-Fixed: 3459316
reg_set_ap_pwr_type() API is invoked per pdev and the default ap power type
is set for all bands of the pdev (2.4 GHz / 5 GHz/ 6 GHz). Hence, the
user space command g_ap_power_type retrieves SP Power mode for 2.4 GHz
and 5 GHz pdev in outdoor deployment mode.
Since power type is valid only for a 6 GHz pdev, check if the chip
supports 6 GHz channel range and set the power type.
CRs-Fixed: 3459316
Change-Id: Ib5038d5d019ab9ffaa6a607916e5187ecdbd4e2b
Correct 5 GHz channels reg rule for CC PK.
a. Split CHAN_5170_5330_3 into CHAN_5170_5250_8 and CHAN_5250_5330_12
to mark missing radar frequency range mark.
b. Change CHAN_5735_5875_8 to CHAN_5735_5875_3 to change regulatory
power value to 30.
Change-Id: I977273e1dfff9d95ad3ca2580a283594ddf7e9b5
CRs-Fixed: 3459453
Correct wrong frequency mapping for APL25 RD.
a. CHAN_5170_5330_3 is split into CHAN_5170_5250_8
and CHAN_5250_5330_12 to mark missing radar frequency
range.
b. CHAN_5490_5730_9 is split into CHAN_5490_5590_4 and
CHAN_5650_5730_4 to mark the frequency range as radar
indication range.
c. Remove unused reg rule CHAN_5490_5570_1
Change-Id: Ib0a754987246329a09cd8779de03859167b80f66
CRs-Fixed: 3447198
Correct reg rules for CC GB.
a. Change CHAN_5250_5330_16 to CHAN_5250_5330_12 to mark
radar frequency range.
b. Change CHAN_5735_5875_7 to CHAN_5735_5875_4 and to remove
radar marking.
Change-Id: Ie3bf1e6102da1cf8df7b3408c46a6f559abb5743
CRs-Fixed: 3447292
Below code changes are made
1. Correct 5 GHz reg rules for APL 26/27 RDs.
i. APL26 changes
a. CHAN_5170_5330_3 is split into CHAN_5170_5250_8 and
CHAN_5250_5330_12 To mark missing radar frequency range.
b. CHAN_5490_5730_3 changed to CHAN_5490_5730_5 to mark the
frequency range as radar indication range.
ii. APL27 changes
a. CHAN_5250_5330_10 and CHAN_5490_5730_4 are changed to
CHAN_5250_5330_7 and CHAN_5490_5730_1 respectively to mark the
frequency range as radar indication range.
2. Remove duplicate entry CHAN_5735_5835_8 (duplicate of CHAN_5735_5835_1)
Change-Id: I7daa70ae992a87de73721bcfab170894af3358ca
CRs-Fixed: 3447101
Currently many pev related API's are not present in
wlan_regulatory_pdev_obj_created_notification. As a result many info
is not saved to pdev.
To address this issue invoke reg_propagate_mas_chan_list_to_pdev
from wlan_regulatory_pdev_obj_created_notification.
Change-Id: I47b7c09006c93828db32710d1fa882eb1f9b8ba5
CRs-Fixed: 3461593
In the change-id Ied56965c2e8d700a2fc14a5a2b79beed95ac7818,
the call of reg_propagate_mas_chan_list_to_pdev in pdev_obj_creation,
leads to a fatal assert.
Within reg_propagate_mas_chan_list_to_pdev,
ol_ath_fill_umac_legacy_chanlist is called, and internally
within ol_ath_fill_umac_legacy_chanlist, the cookie for the event
ic->ic_wait_for_init_cc_response is set, before the
ic->ic_wait_for_init_cc_response is created in the function
wlan_pdev_update_feature_ptr. This leads to a crash.
To fix this issue, separate fill_umac_legacy_chanlist from the function
reg_propagate_mas_chan_list_to_pdev and call fill_umac_legacy_chanlist
only when WMI_REG_CHAN_LIST_CC_EVENTID or
WMI_REG_CHAN_LIST_CC_EXT_EVENTID is received.
Change-Id: I5fcf85eed32d3ab2cd4fd88ad117fcf22c5875b2
CRs-Fixed: 3427982
Currently host isn't validating the reg rules received from
fw. Host saves these reg rules locally and updates the same
info to kernel.
To address this issue add logic to validate reg rules in host.
Change-Id: I7369126e83ab210720cb5b2db2e11d3aa7491b4a
CRs-Fixed: 3376632
In outdoor deployment, when the target sends STOP_TX event, the 6 GHz
AP continues to beacon in the SP power mode, without bringing down the VAP.
In mlme_check_curchan_and_set_ap_pwr_type, since the
afc_power_event_received flag is cleared and set to false during STOP_TX,
the API wlan_reg_get_best_pwr_mode returns LPI as the best power mode.
When LPI is given as input to wlan_reg_set_ap_pwr_and_update_chan_list,
it returns an error as LPI rules are absent in the pdev
(outdoor deployment). But the error status is not handled. Current channel
list also is not updated with the AFC_NOT_FLAG. When the channel list is
sent to the hostapd, NO_IR flag is set based on the presence of the
AFC_NOT_DONE flag in the current channel list. As a result NO_IR flag is
not sent to the hostapd, and the VAP remains in the up state.
To fix this issue, in reg_get_best_pwr_mode_from_eirp_list, skip the
unsupported modes (in this case LPI and VLP), from best power mode
computation. Also, in reg_get_sp_eirp, return the SP EIRP when no rules
other than SP are available.
Also, rename reg_get_eirp_for_non_sp to reg_get_eirp_from_mas_chan_list.
Modify reg_get_sp_eirp to call reg_get_eirp_from_mas_chan_list when
CONFIG_AFC_SUPPORT is not defined.
Change-Id: I1b11bf0580ec6af09ee8f9827bc85fae7930e414
CRs-Fixed: 3436245
wlan_reg_recompute_current_chan_list() is defined for MCC only.
Make this wlan_reg_recompute_current_chan_list() common for both WIN
and MCC.
CRs-Fixed: 3451996
Change-Id: Ifcead79a68d0ed04ac1e4b78063f36b91e4d6fd8
During initial AFC development it was assumed that AFC object would travel
till an application endpoint outside the driver, presumably till an
application of a different machine anything in the internet and therefore,
a packed and well formatted structure was propped for the AFC object.
However, when the AFC object leaves the driver, it is converted to an
object that has NL80211 TLVs to represent it. Therefore, the packed
AFC-request object is no longer a necessity. Moreover, since an unpacked
structure (or structures) is speed/time optimized, modify the packed
structures into unpacked structures.
Change-Id: I08db1911a355b6eebffa0e13def547c98ddf38d3
CRs-Fixed: 3431997
In case of a split-phy 6 GHz radio, there are 6 GHz opclasses and cfis
that do not intersect with the chip range for a given pdev.
The current algorithm appends such opclasses with "num_cfis as 0" to
the AFC request buffer and the buffer with empty cfis are
sent to the AFC server.
This change ensures that the chip unsupported opclasses/cfis are not sent
to the AFC server.
Also, if the reg rule frequency range is not supported by the chip range,
reg_intersect_ranges() is expected to set the out_range as
{low_freq = 0,high_freq = 0}. However, it only sets the low_freq to 0.
Since high_freq is a non-zero value, the chip un-supported range is
considered as a valid range with frequency_low as 0.
This causes the following error from the AFC server:
"error": "The frequency range indicated in the Available Spectrum
Inquiry Request is at least partially outside of the frequency band
under the management of the AFC System (e.g. 5.925-6.425 GHz and
6.525-6.875 GHz bands in US).
To fix this issue, assign high_freq also to 0 if the
reg rule frequency range is not supported by the chip range.
CRs-Fixed: 3442719
Change-Id: I5504376ac31203045b32e23f54a9ab6a41e63a3f
Add support for WMI_CSA_IE_RECEIVED_EVENTID as:
1. Register the handler
2. Handler to extract the event
Change-Id: I9f476c7fbc51d9686d05fbdb5f46dec3bcd3c29e
CRs-Fixed: 3431363
Currently for client SP, super channel list is disabled
even if the corresponding reg rules are sent by the target.
To address this issue, add two definitions for
reg_is_sp_pwr_mode_allowed_in_supchan, to check
if the given mode is SP mode in the super channel list.
Change-Id: Idb1fc22e3ba4a61a07e03302f92fd8e2a6a9bc85
CRs-Fixed: 3426498
At continuous physical address limited telematics platform,
in order to avoid occasional memory alloc failure with big
kzalloc size, it's better to use virtual memory allocation
API instead. And below items will be refined to replace malloc
with valloc when CONFIG_ENABLE_VALLOC_REPLACE_MALLOC=y.
1 x 66384 = 66384B @
wlan_regulatory_psoc_obj_created_notification:106
wlan_objmgr_psoc_obj_create+0x104/0x240 [qca6698]
1 x 44936 = 44936B @
wlan_regulatory_pdev_obj_created_notification:324
wlan_objmgr_pdev_obj_create+0x17c/0x284 [qca6698]
Change-Id: Ia2f1b0d3f6f0149c3a88ee776ee4b11493943227
CRs-Fixed: 3426809
When the CLI command wifitool athX disable_opclass_chans is executed
with a valid 20 MHz operating class, the command throws an error,
"Opclass should only be 20 MHz opclass" on the console.
The opclass passed as an argument to reg_enable_disable_opclass_chans,
which is greater than 20 MHz in value, makes the API reg_is_20mhz_opclass,
always return false.
To fix the issue, pass channel spacing (in MHz units) as an argument to
the 'reg_is_20mhz_opclass'. Also rename 'reg_is_20mhz_opclass' to
'reg_is_chanspacing_20mhz' as we are verifying if the channel spacing
of an opclass is close to 20 MHz; not verifying the opclass itself.
Change-Id: I198b4d90c68613210377b96f6836c5b8c810dc7f
CRs-Fixed: 3410934
The kernel-doc script identified some documentation issues in
the doc of reg_get_min_max_bw_on_cur_chan_list, so fix those
issues.
Change-Id: I5f720706b8c744f39d4ad6f6dbd6e722c3d53096
CRs-Fixed: 3409405
When the target indicates a non-success status in the fw_status_code
as part of the AFC power event, the control is exited from
reg_process_afc_power_event without updating the super_chan_list,
and sending the AFC power update complete event.
Therefore, send AFC power update complete event during AFC power
event failure.
Change-Id: Iab3a73955cf6df8d999122f1ef36bf249e86d3bb
CRs-Fixed: 3298839
Replace all callers of reg_set_channel_params_for_freq
with new api reg_set_chan_params_for_pwrmode
Change-Id: Ifefb8e0a2e9dc2dde5360f90b6c129573dfaddc1
CRs-Fixed: 3144601
To mark a 20 MHz standard power channel (chan X) as AFC done, we check
if X's range is a subset of a AFC frequency object payload (say Y).
If X is not a subset of Y, chan X is marked as "AFC not done" and is
disabled in the regulatory's AFC channel list.
However, it is possible that channel X's range is split across various
frequency objects of the AFC payload. The current algorithm does not
coalesce the adjacent frequency object payload so that X becomes a
subset. This change aims to coalesce the AFC payload as and when needed.
If the frequency ranges of the AFC payload are sliced and the
PSD power of a 20 MHz channel is split across multiple frequency ranges
in the AFC payload, coalesce the frequency ranges to form a single
range that can fit channel X so that the PSD power can be fetched.
The coalesced PSD power will be minimum PSD power of the frequency
ranges where coalescing is done.
If coalescing is not required, pick the PSD power from AFC payload
directly.
CRs-Fixed: 3387610
Change-Id: Ib358028a6842cb6644eaae2964738d391a5dd763
Currently, CHAN_5925_6425_6 is defined in
regulatory_rule_ext but enum value corrosponding
to CHAN_5925_6425_6 in reg_rules_6g is missing
which may cause compilation issues when COMPILE_REGDB_6G
is enabled.
To fix compilation issue declare CHAN_5925_6425_6
in reg_rules_6g.
Change-Id: Ifcf751ab543b13d4eb99cc64280ef116ac931b09
CRs-Fixed: 3418240
Do not mark REGULATORY_CHAN_NO_IR channel flag for
the 5 GHz indoor channels if p2p go support is enabled
on indoor channels.
Change-Id: I7fbae71766260513aa9946446b7e8bf8507df53b
CRs-Fixed: 3411708
Add API reg_process_r2p_table_update_response to handle the event received
from target in response to rate2power table update cmd. Make a call to
end_r2p_table_update_wait from this API to end the wait timer triggered
for the update cmd. Add end_r2p_table_update_wait to
wlan_lmac_if_reg_tx_ops. Add a dispatcher
tgt_reg_process_r2p_table_update_response for this API and register it as
a rx_ops.
Add register and unregister APIs of rate2power table update response
handler to wlan_lmac_if_reg_tx_ops. Call the register API in
regulatory_psoc_open and unregister in regulatory_psoc_close. Define
struct r2p_table_update_status_obj and its members to receive the
response of rate2power table update cmd from target.
Change-Id: I6909e37620b94dc7fdcd3c7c0915a3fad8fa1cda
CRs-Fixed: 3405417
