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
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
The following change fixed all of the documentation issues in the
umac/regulatory/core folder:
qcacmn: Fix umac/regulatory/core documentation
Change-Id Id666d5a92415158591e6379b619fb34c518aeca1
Unfortunately, before the patch was merged, the following change
introduced new errors in the documentation of function
reg_enable_disable_chan_in_mas_chan_list(), located in
umac/regulatory/core/src/reg_opclass.c:
qcacmn: Add an API to enable or disable channels based on opclass
Change-Id Ie9dbbadbe28e5b5fdc2ec9c60c284da9c9e2286f
Fix those errors.
Change-Id: I8396159a6af4ece0815f78355a0531aca5eff023
CRs-Fixed: 3408940
Currently 'wlan_reg_max_5ghz_ch_num'returns
INVALID_CHANNEL_NUM for countries other than US
as MAX_5 GHZ_CHANNEL maps to INVALID_CHANNEL_NUM
for other countries in their respective channel_map
structure.
To fix this issue of INVALID_CHANNEL_NUM for
MAX_5 GHZ_CHANNEL,instead of taking value from
channel_map[].chan_num, with fixed index of MAX_5 GHZ_CHANNEL,
check for channel_map[].cha_num with index starting from
MAX_5 GHZ_CHANNEL down to 5 GHz channels,
consider the first hit of chan_num which is not
INVALID_CHANNEL_NUM.
Change-Id: I364500f8e13cc42350103c5d236b12d71e28a4a6
CRs-Fixed: 3396340
The kernel-doc script identified some documentation issues in the
umac/regulatory/dispatcher folder, so fix them.
Change-Id: I2d38ec243bba2f48f522e2b80ac097eec0e06a3c
CRs-Fixed: 3402138
Add support to get min and max band width of provided
channel enum, so that configured bandwidth can be validated
whether it lies in the range of bandwidth or not.
Change-Id: I765b4e8013d021eaca41b37789d1ef3f1d57fa7d
CRs-Fixed: 3402928
In reg_is_chan_supported() API, the stack object chan_list is
uninitialized and is used by channel search API. The puncture pattern
inside the chan_list is set to a random value and it causes channel find
failure.
CRs-Fixed: 3402977
Change-Id: Icec8e5f207d3d8bfb5a01dafe8aa6adc5bc18a9d
The kernel-doc script identified some documentation issues in the
umac/regulatory/core folder, so fix them.
Change-Id: Id666d5a92415158591e6379b619fb34c518aeca1
CRs-Fixed: 3401870
Replace reg_is_afc_available() with reg_is_afc_power_event_received(),
return true when AFC enable and AFC updated power info.
After this update, if AFC available, SAP can set reg_cur_6g_ap_pwr_type
correct so that TPE in beacon can populate proper power value
to client.
Change-Id: I7564947bdeb13ac1e35c84cbe31ec1f428b3fae6
CRs-Fixed: 3391120
Add an API ucfg_reg_enable_disable_opclass_chans where given the
operating class, disable/enable the channels listed in the input
channel list.
The input channel list and operating class should be of 2 GHz or
5 GHz band.
Change-Id: Ie9dbbadbe28e5b5fdc2ec9c60c284da9c9e2286f
CRs-Fixed: 3301654
In the current implementation, the frequency range and maximum
bandwidth of the regulatory rule CHAN_5835_5895_1
are 60 MHz and 80 MHz respectively. Which means that maximum
bandwidth is greater than the frequency range for this rule. But the
kernel does not allow us to have such a rule.
If we change the maximum bandwidth to 40 MHz for this rule, the kernel
warning disappears. However, it introduces a new problem.
If the beginning frequency of rule CHAN_5835_5895_1 matches with the
end frequency of a previous rule, say CHAN_5735_5835_2, then the
function 'reg_do_auto_bw_correction' cannot stitch them (the rules)
properly as it simply adds the max bandwidths the two rules.
In this case, if the maximum bandwidth was reduced from 80 MHz to
40 MHz and previous rule's maximum bandwidth was 80 MHz and
the new stitched rule would have 120 MHz as the maximum bandwidth.
We should consider the frequency range of both the rules in order to
achieve the max bandwidth possible. Therefore, use the version of the
function 'reg_do_auto_bw_correction' that already does it.
Change-Id: Ib3cb1a31b6d376b9b02f3d4e6b56cd7b5e6fed3a
CRs-Fixed: 3381553
The current channel list alone is not enough to represent the
capability of the chip or device. Given a channel, in many
cases it may be required to know all the power modes that are
supported by this channel.
Update caller APIs to use super channel list. Remove
reg_fill_channel_list, reg_fill_pre320mhz_channel and
reg_fill_channel_list_for_320 to use the super channel list APIs.
Change-Id: I917eb3414b6339678f84eb7cf6e3547ed52b6335
CRs-Fixed: 3360452
1. Enable sub chan DFS type if QCA_DFS_BW_PUNCTURE defined, or all bonded
operation freq will be affected and disabled for nol, puncture can't work,
always need to switch freq.
2. Find nearest puncture pattern for a bitmap.
For example, SAP started with channel width 320 MHz, if only 20 MHz freq
affected by radar, 320 + 20 puncture pattern is invalid, but puncture
pattern 320 + 40 can be used.
3. Fix build issue when QCA_DFS_BW_PUNCTURE defined as following.
error: incompatible pointer types passing 'qdf_freq_t[16]' (aka
'unsigned int[16]') to parameter of type 'uint16_t *' (aka 'unsigned
short *')
Change-Id: I374ed76c6a13ef5fac1a78073f1b8974b0a9bb30
CRs-Fixed: 3386020
When calculating 6 GHz Opclasses and channels through API
reg_dmn_get_6g_opclasses_and_channels, memory allocation
is performed based on number of opclasses.
In some cases if the number of opclasses is zero, we
try to memory allocate for 0 bytes resulting in error
in console.
To avoid this issue, verify that the number of opclasses
is non-zero before performing the allocation.
Change-Id: Ieae85130eb77c9637153ae1505c9d9b578e0bf2e
CRs-Fixed: 3379534
The current channel list alone is not enough to represent the
capability of the chip or device. Given a channel, in many
cases it may be required to know all the power modes that are
supported by this channel.
Replace the references of "reg_get_5g_bonded_channel_for_freq"
with "reg_get_5g_bonded_channel_for_pwrmode".
Change-Id: I4c978c7f938b14d79d0eadf4251a86a9165f496e
CRs-Fixed: 3147900
The current channel list alone is not enough to represent the
capability of the chip or device. Given a channel, in many
cases it may be required to know all the power modes that are
supported by this channel.
Update API to use supper channel list.
Remove reg_get_5g_bonded_chan_array_for_freq API to use the
super channel API reg_get_5g_bonded_chan_array_for_pwrmode
Change-Id: I4714ae628add81de776bfaec07756df56f27094f
CRs-Fixed: 3143152
The regulatory API reg_get_bonded_chan_entry() does not print the input
parameter "cen320_freq" which indicates the 320 MHz center frequency and is
used in 11be regulatory calls.
Add the parameter "cen320_freq" in the existing regulatory debug print for
the API.
Change-Id: I9edec5855326e78b6898d3a443d96d938fbfe44f
CRs-Fixed: 3369874
The current channel list alone is not enough to represent the
capability of the chip or device. Given a channel, in many
cases it may be required to know all the power modes that are
supported by this channel.
Update callers of reg_is_chan_supported with super channel list.
reg_is_chan_supported to use the super channel list API
reg_is_chan_supported_for_pwrmode.
Change-Id: I5d33f7bb0bee6012c28d35e6138f5a03525c33ca
CRs-Fixed: 3357157
The current channel list alone is not enough to represent the
capability of the chip or device. Given a channel, in many
cases it may be required to know all the power modes that are
supported by this channel.
Update caller APIs to use super channel list. Removed
wlan_reg_get_bonded_channel_state_for_freq and
wlan_reg_get_5g_bonded_channel_and_state_for_freq to use the
super channel API wlan_reg_get_bonded_channel_state_for_pwrmode
and wlan_reg_get_5g_bonded_channel_and_state_for_pwrmode
respectively
Change-Id: If51bd130892cd712f5a218067a5d321e874e134a
CRs-Fixed: 3357153
The current channel list alone is not enough to represent the
capability of the chip or device. Given a channel, in many
cases it may be required to know all the power modes that are
supported by this channel.
Remove reg_get_5g_bonded_channel_state_for_freq,
wlan_reg_get_5g_bonded_channel_state_for_freq and
reg_update_5g_bonded_channel_state_punc_for_freq APIs to use the
super channel APIs reg_get_5g_bonded_channel_state_for_pwrmode,
wlan_reg_get_5g_bonded_channel_state_for_pwrmode and
reg_update_5g_bonded_channel_state_punc_for_pwrmode.
Change-Id: I895d70d3a07e239500f97b9ab7884d7723de5080
CRs-Fixed: 3144661
Reduce logging level to debug for certain error log prints
in regulatory APIs to decrease console logging.
Change-Id: I35d27fa08269c48b097f0a0811612e8191f723eb
CRs-Fixed: 3389491
Add API reg_set_power_event_received_flag to set
is_6g_afc_power_event_received flag with a given value.
Change-Id: I322c3724f23c611d1a0d65248b777501c742000e
CRs-Fixed: 3260971
Currently host uses LPI as default power type when STA and
AP country is same without checking if powertype advertised
by AP is valid for client or not.
To address this issue default to power type advertised by AP.
Change-Id: I59144b020bed5af49dea8fdaad0e59daa556fefe
CRs-Fixed: 3381295
Add dispatcher for function reg_get_num_rules_of_ap_pwr_type
to get the number of rules supported for given power mode
Change-Id: I084cc4e47ed16a71c1a8a7db4a6f046a0007a9d7
CRs-Fixed: 3378907
For a 320M bonded channel, if one of the subchannels is disabled due to
nol or static puncture, the return status becomes disabled. To correct
the status for the valid patterns, remember if at least one channel is DFS
and set the status to either DFS or enabled.
Change-Id: I4cac0afe29e6071e551c087b9d6e413b227eb18d
CRs-Fixed: 3369915
If country code for AP and STA are same and if STA does not
support VLP mode for a particular channel and if AP power
type is misconfigured to VLP mode, do not allow connection
to that AP as per regulatory guidelines.
Change-Id: Ie3bb980df25a15c4d9d7e566663e28950414f733
CRs-Fixed: 3362142
Enable channel 144 for JAPAN country by default. From regdomain
version 31, JAPAN is mapped to MKK17_MKKC instead of MKK5_MKKC. As per
the regdomain definition of MKK17, channel 144 must be enabled by
default. Only for MKK5 regdomain, channel 144 must be enabled based on
user config "setch144".
CRs-Fixed: 3375932
Change-Id: I48411f7f77ebbb9944dcf4988bb9ac22587e2074
The current channel list alone is not enough to represent the
capability of the chip or device. Given a channel, in many
cases it may be required to know all the power modes that are
supported by this channel.
Remove wlan_reg_fill_channel_list to use the super channel API
wlan_reg_fill_channel_list_for_pwrmode.
Change-Id: I9645caff236af786b6376608be2aa56a28fe689c
CRs-Fixed: 3357161
In reg_compute_indoor_list_on_cc_change(), vdev
release is not needed if the vdev is not found.
Therefore, proceed with the loop instead of release
of the vdev reference.
Change-Id: I92c909d0f7e6e262e64e5d1dc01481dc452da194
CRs-Fixed: 3363892
