- 13 May, 2020 13 commits
-
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2020-05-08' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next Second set of iwlwifi patches intended for v5.8 * Support new FW APIs; * Remove some old and unused features; * HW configuration rework continues; * Some queues rework by Johannes; * Enable A-AMSDU in low latency; * Some debugging fixes; * Some other small fixes and clean-ups; # gpg: Signature made Fri 08 May 2020 10:08:58 AM EEST using RSA key ID 1A3CC5FA # gpg: Good signature from "Luciano Roth Coelho (Luca) <luca@coelho.fi>" # gpg: aka "Luciano Roth Coelho (Intel) <luciano.coelho@intel.com>"
-
ChenTao authored
Fix the following warning: drivers/net/wireless/realtek/rtl818x/rtl8187/rtl8225.c:609:17: warning: ‘rtl8225z2_tx_power_ofdm’ defined but not used static const u8 rtl8225z2_tx_power_ofdm[] = { Acked-by:Hin-Tak Leung <htl10@users.sourceforge.net> Acked-by:
Larry Finger <Larry.Finger@lwfinger.net> Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
ChenTao <chentao107@huawei.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200513011754.28432-1-chentao107@huawei.com
-
Yan-Hsuan Chuang authored
sparse warnings: (new ones prefixed by >>) >> drivers/net/wireless/realtek/rtw88/rtw8723d.c:1899:6: sparse: sparse: symbol 'rtw8723d_pwr_track' was not declared. Should it be static? Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
Since 8723D code is ready, we can build it. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
8723D adds some experimental features to word 0x06 of cam entry, so fill zeros to initialize them to off state. For existing chips, these two words are reserved and always zeros, so this change is harmless for them. Signed-off-by:
-
Ping-Ke Shih authored
8723D is a Wifi+BT combo card. To make them work properly, we need coex mechanism to avoid interference, such as TX simultaneously. Basically, coex.c provide main algorithm to deal with many use cases, and this commit adds some parameters and ops differ from other chips, because coex hardware and WiFi generation are changed. Signed-off-by:
-
Ping-Ke Shih authored
Since 8723D use different address of ltecoex register, this commit add a new field in chip_info and fill proper address. Then, ltecoex_read_reg() and ltecoex_reg_write() can use them to access ltecoex according to chip. Signed-off-by:
-
Ping-Ke Shih authored
Flush queue is used to check if queue is empty, before doing something else. Since 8723D uses different registers and page number of availabl/reserved occupy 8 bits instead of 16 bits, so use a 'wsize' field to discriminate which rtw_read{8,16} is adopted. Signed-off-by: -
Ping-Ke Shih authored
Without this patch, wifi card can't initialize properly due to BT in USB suspend state. So, we disable BT USB suspend (wakeup) in shutdown callback that is the moment before rebooting. To save BT USB power, we can't do this in 'remove' callback. Signed-off-by:
-
Ping-Ke Shih authored
When chip's temperature is changed, RF characters are changed. To keep the characters to be consistent, 8723d uses thermal meter to assist in calibrating LCK, IQK, crystal and TX power. A base thermal value is programmed in efuse, all calibration data in MP process is based on this thermal value. So we calucate the delta of thermal value between the base value, and use this delta to reference XTAL and TX power offset tables to know how much we need to adjust. For IQK and LCK, driver checks if delta of thermal value is over 8, then they are triggered. For crystal adjustment, when delta of thermal value is changed, we check XTAL tables to get offset of XTAL value. If thermal value is larger than base value, positive table (_p as suffix) is used. Otherwise, we use negative table (_n as suffix). Then, we add offset to XTAL default value programmed in efuse, and write sum value to register. To compensate TX power, there are two hierarchical tables. First level use delta of thermal value to access eight tables to yield delta of TX power index. Then, plus base TX power index to get index of BB swing table (second level tables) where register value is induced. BB swing table can't deal with all cases, if index of BB swing table is over the size of the table. In this case, TX AGC is used to compensate the remnant part. Assume 'upper' is the upper bound of BB swing table, and 'target' is the desired index. Then, we can illustrate them as compensation method BB swing TX AGC ------------------- -------- -------------- target > upper upper target - upper target < 0 0 target otherwise target 0 For debug purpose, add a column 'rem' to tx_pwr_tbl entry, and it looks like path rate pwr base (byr lmt ) rem A CCK_1M 32(0x20) 34 -2 ( 0 -2) 0 Signed-off-by: -
Ping-Ke Shih authored
IQ calibration is used to calibrate RF characteristic to yield expected performance. Basically, we do calibration twice and compare the similarity to determine calibration is good or not, if not we do the third calibration, and then compare with the results of first and second calibration. If it still not similar, IQK is failed. Before doing calibration, we need to backup registers that will be modified in calibration procedure, and restore these registers after calibration is done. A calibration procedure can divided into four sub-procedures that are S1-TX, S1-RX, S0-TX and S0-RX. Where, S1 and S0 represent to path A and B respectively. Each sub-procedure configure proper registers, and then rigger one-shot calibration and poll until completion. For RX calibration, it needs to do twice one-shot calibration, first one is to yield parameter used by second one. The result of TX part is stored for TX power tracking that adjusts TX AGC to output expected power. Signed-off-by:
-
Ping-Ke Shih authored
LC calibration is done by hardware circuit. Driver sets the LCK bit to kick start, and then poll the bit to check if it's done. Signed-off-by:
-
Chung-Hsien Hsu authored
An incorrect value of use_fwsup is set for 4-way handshake offload for WPA//WPA2-PSK, caused by commit 3b1e0a7b ("brcmfmac: add support for SAE authentication offload"). It results in missing bit BRCMF_VIF_STATUS_EAP_SUCCESS set in brcmf_is_linkup() and causes the failure. This patch correct the value for the case. Also setting bit BRCMF_VIF_STATUS_EAP_SUCCESS for SAE offload case in brcmf_is_linkup() to fix SAE offload failure. Fixes: 3b1e0a7b ("brcmfmac: add support for SAE authentication offload") Signed-off-by:
Chung-Hsien Hsu <stanley.hsu@cypress.com> Signed-off-by:
Chi-Hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by:
-
- 12 May, 2020 15 commits
-
-
Pali Rohár authored
Correct name of constant is CLOCK_BOOTTIME and not CLOCK_BOOTIME. Signed-off-by:
Pali Rohár <pali@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Signed-off-by:
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
caps_buf is always of size sizeof(*caps) because sizeof(caps->auth_encr_pair) * 16 is always zero. Notice that when using zero-length arrays, sizeof evaluates to zero[1]. So, the code introduced by commit 0308383f ("rndis_wlan: get max_num_pmkids from device") is logically dead, hence is never executed and can be removed. As a consequence, the rest of the related code can be refactored a bit. Notice that this code has been out there since March 2010. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.htmlSigned-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:1785:5-8: WARNING: Comparison to bool Signed-off-by:
Jason Yan <yanaijie@huawei.com> Reviewed-by:
-
Chen Zhou authored
Fix sparse warning: drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c:2206:5: warning: symbol 'brcmf_p2p_get_conn_idx' was not declared. Should it be static? Reported-by:
Chen Zhou <chenzhou10@huawei.com> Reviewed-by:
Wright Feng <wright.feng@cypress.com> Signed-off-by:
-
Soontak Lee authored
When plumbing rxiv for (GTK) keys, current code does not use seq/seq_len when present nor set iv_initialized for iovar wsec_key. This could result in missing broadcast traffic after GTK rekey. The fix is setting iv_initialized and using seq/seq_len for iovar wsec_key. Signed-off-by:
Soontak Lee <soontak.lee@cypress.com> Signed-off-by:
-
Ryohei Kondo authored
The driver sends an action frame down and waits for dwell time to be completed or aborted before sending out the next action frame. Driver issues "scan abort" to cancel the current time slot, but this doesn't have any effect because, we are not using scan engine for sending action frame. Fix is to use "actframe_abort" to cancels the current action frame. Signed-off-by:
Ryohei Kondo <ryohei.kondo@cypress.com> Signed-off-by:
-
Jia-Shyr Chuang authored
Host driver parses and sets security params into FW passed by supplicant. This has to be done after reiniting interface in the firmware. Signed-off-by:
Jia-Shyr Chuang <joseph.chuang@cypress.com> Signed-off-by:
-
Pramod Prakash authored
802.1d defines 0,3 for BE and 1,2 for BK. In pcie dongles, 0 & 3 are mapped to 0 and 1,2 are mapped to 1. This change corrects this mapping, so that BE & BK are given access precedence accordingly by pcie dongles. Signed-off-by:
Pramod Prakash <pramod.prakash@cypress.com> Signed-off-by:
-
Saravanan Shanmugham authored
In WLAN, priority among various access categories of traffic is always set by the AP using WMM parameters and this may not always follow the standard 802.1d priority. In this change, priority is adjusted based on the AP WMM params received as part of the Assoc Response and the same is later used to map the priority of all incoming traffic. In a specific scenario where EDCA parameters are configured to be same for all ACs, use the default FW priority definition to avoid queuing packets of all ACs to the same priority queue. This change fixes the following 802.11 certification tests: * 11n - 5.2.31 ACM Bit Conformance test * 11n - 5.2.32 AC Parameter Modification test * 11ac - 5.2.33 TXOP Limit test Signed-off-by:
Saravanan Shanmugham <saravanan.shanmugham@cypress.com> Signed-off-by:
Justin Li <justin.li@cypress.com> Signed-off-by:
Madhan Mohan R <madhanmohan.r@cypress.com> Signed-off-by:
-
- 08 May, 2020 12 commits
-
-
Liad Kaufman authored
There are several "flavors" of HW that have the same HW type, but can be told apart after reading a certain perph register. This is easy to do in runtime, but more complicated to do when looking at the logs offline. To make it easier to tell apart these "flavors" when looking at the dumped dbg info, add these bits to the HW type, allowing simple differentiation. Signed-off-by:
Liad Kaufman <liad.kaufman@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200425130140.330ea11d17ae.Ie59b25430a308090b15112ac6deedf4fbf487ff1@changeid
-
Johannes Berg authored
We don't really expect fragmented RBs, and don't seem to be seeing them in practice since that would've caused a crash. Nevertheless, we should be expecting the hardware to send them. Parse the flag indicating a fragmented buffer, but then discard it and any fragments thereof, at least for now. We need to do more work in the higher layers to properly deal with this, since we may not get "normal" firmware notifications that are fragmented, only RX, and then we need to put it back together and add the necessary API to report a chain of things to the higher layers, this doesn't fit into the struct iwl_rx_cmd_buffer today. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
Remove the outdated copyright, don't print it, and update the module author to actually be Intel, not Intel's copyright. Signed-off-by:
-
Johannes Berg authored
We can currently end up transmitting on an unallocated queue, if the allocation fails. Stop doing that, by simply not transmitting. We don't have any better strategy here, unfortunately, but the previous commits make that much less likely. Signed-off-by:
-
Mordechay Goodstein authored
Tests have shown that we can meet low latency KPIs with A-MSDU enabled so enable it to achieve max TPT. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by:
-
Johannes Berg authored
When we have 256 block-ack support, we may need to be very fast to provide a lot of frames to the hardware to transmit, but that cannot be guaranteed. Use a longer queue size to have more time, and the next possible queue size is 1024 since it must be a power of two. Signed-off-by:
-
Johannes Berg authored
Since the recent patch in this area, we no longer allocate 64k for a single queue, but only 1k, which still means a full page. Use a DMA pool to reduce this further, since we will have a lot of queues in a typical system that can share pages. Signed-off-by:
-
Johannes Berg authored
We can never get into this code with a gen2/3 device, and therefore don't need to allocate the byte count tables in a single contiguous DMA region. Just WARN and bail out if something is misconfigured. Signed-off-by:
-
Johannes Berg authored
If CONFIG_IWLWIFI_DEBUGFS is not set, the variable is assigned but not checked, resulting in a compiler warning. Suppress it, we need the variable for the debugfs-enabled case. Signed-off-by:
-
Johannes Berg authored
We currently attempt to allocate queues that are 512 entries long, but that requires 32 KiB memory, which may not be available, at least not contiguously. If we fail to allocate, attempt to use a smaller queue all the way down to 16 entries (which fit into a single page). Signed-off-by:
-
Johannes Berg authored
The hardware needs a byte-count table with the size of each frame on the queue to build A-MPDUs, but: * newer generation no longer have the duplicated space at the end, they can deal with the wrap properly - and we don't even fill the dup anyway * we have a maximum queue size of 512 right now and don't use the theoretical hardware maximum of 65536. Together, this reduces the byte count table DMA allocation from 64KiB (65536*2 + 64*2 rounded up) to 1 KiB (though that might be rounded up to a full 4 KiB page by the allocator, not sure it can share the allocations.) Signed-off-by:
-
Mordechay Goodstein authored
Used for debugging what FW API we are using to understand misalignment with API changes. The output looks like this as a yaml format fw_api_ver: 0x0001: name: MVM_ALIVE cmd_ver: 99 notif_ver: 4 0x0108: name: PHY_CONTEXT_CMD cmd_ver: 2 notif_ver: 0 ... Signed-off-by:
-
