- 12 May, 2020 40 commits
-
-
Lorenzo Bianconi authored
Remove key dependency from mt7615_mac_wtbl_update_key and export mt7615_mac_wtbl_update_key, mt7615_mac_wtbl_update_pk and mt7615_mac_wtbl_update_cipher in order to reuse them in usb code. Move mt7615_mac_get_cipher in mac.h Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
Lorenzo Bianconi authored
Rely on the mt7622 endpoint definitions for mt7663u Signed-off-by:
-
Lorenzo Bianconi authored
Move mt7615_mac_wtbl_addr in mac.h and add inline qualifier in order to be reused adding usb support to mt7615 driver Signed-off-by:
-
Lorenzo Bianconi authored
Introduce __mt7663_load_firmware routine to load firmware for usb devices. Signed-off-by:
-
Lorenzo Bianconi authored
Move register configuration out of mt7615_mac_set_rates since usb driver can't access device register in interrupt context. Introduce mt7615_mac_update_rate_desc routine to report rate info to mt7615_mac_set_rates Co-developed-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
-
Lorenzo Bianconi authored
Extend mt7615_write_txwi routine to support usb txwi configuration Co-developed-by:
-
Lorenzo Bianconi authored
Introduce headroom and tailroom to mt76_mcu_ops data structure in order to unify the routine used for mcu message allocation. This is a preliminary patch to add mt7663u support Signed-off-by:
-
Sean Wang authored
Remove mt76_wr(dev, MT_CSR(0x010), 0x8208) that would cause MT_PCIE_IRQ_ENABLE to be disabled; MT_PCIE_IRQ_ENABLE should always keep on enabled when the driver is running. 0x44064 is a not existing address Signed-off-by:
-
Lorenzo Bianconi authored
Introduce rlm tlv header in bss_info mcu command in order to inform the mcu about operating channel. Rlm header is necessary only if the mcu is running low power functionalities (e.g offloaded scan) Co-developed-by:
-
Sean Wang authored
Introduce BSS absence event that is reported when the fw is leaving or entering current operational channel. Signed-off-by:
-
Lorenzo Bianconi authored
Introduce scheduled scan support for mt7663e devices Co-developed-by:
-
Lorenzo Bianconi authored
Introduce hw scan support to mt7663e driver Co-developed-by:
-
Sean Wang authored
Keep Rx filters default value if the firmware supports offload and low power features. Signed-off-by:
-
Lorenzo Bianconi authored
Introduce mt7615_mcu_set_channel_domain routines in order to instruct the mcu about supported band/channels. This is a preliminary patch to add hw scan support to mt7663e driver Co-developed-by:
-
Lorenzo Bianconi authored
Report n9 firmware version using ethtool Signed-off-by:
-
Lorenzo Bianconi authored
Disable dfs RDD mcu commands for mt7663 driver since they are not currently supported by the 7663 firmware Co-developed-by:
-
Lorenzo Bianconi authored
Make scs configurable per phy since most of the chipsets do not support dbdc Signed-off-by:
-
Lorenzo Bianconi authored
Enable Noise floor estimation for mt7663 driver Co-developed-by:
-
Lorenzo Bianconi authored
Fix PHYMUX_5 register definition for mt7663 in mt7615_mac_cca_stats_reset routine Fixes: f40ac0f3 ("mt76: mt7615: introduce mt7663e support") Signed-off-by:
-
Ryder Lee authored
Add ba_miss_cnt and ampdu_per in mib_stats. Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
-
Ryder Lee authored
Simplify mib macros and use proper type for related counters. Signed-off-by:
-
Ryder Lee authored
Use bottom half of aggr_stats for second phy. Signed-off-by:
-
Ryder Lee authored
This is a preliminary patch to add more Tx counters. Signed-off-by:
-
Pawel Dembicki authored
Add mt7610 PCI id found on D-Link DWR-960 to pci_device_id table. Run-tested on D-Link DWR-960 with no-name half-size mPCIE card with mt7610e. Signed-off-by:
Pawel Dembicki <paweldembicki@gmail.com> Signed-off-by:
-
Lorenzo Bianconi authored
Introduce Mercury UD13 dual-band dongle support to mt76x2u driver Signed-off-by:
-
Matthew Garrett authored
The current version has a new USB ID and reports as an 0x7632 device. Adding the IDs results in it working out of the box. Signed-off-by:
Matthew Garrett <mjg59@google.com> Signed-off-by:
-
Felix Fietkau authored
If a MCU timeout occurs before a hw restart completes, another hw restart is scheduled, and the station state gets corrupted. To speed up dealing with that, do not issue any MCU commands after the first timeout, and defer handling timeouts until the reset has completed. Also ignore errors in MCU commands during start/config to avoid making user space fail on this condition. If it happens, another restart is scheduled quickly, and that usually recovers the hardware properly. Signed-off-by: -
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:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200508195139.20078-1-pali@kernel.org
-
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:
Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-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:
Hulk Robot <hulkci@huawei.com> Signed-off-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:
-
