- 12 May, 2020 32 commits
-
-
Lorenzo Bianconi authored
Introduce scheduled scan support for mt7663e devices Co-developed-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
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:
-
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 8 commits
-
-
Eric Dumazet authored
Now sch_fq has horizon feature, we want to allow QUIC/UDP applications to use EDT model so that pacing can be offloaded to the kernel (sch_fq) or the NIC. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Acked-by:
Willem de Bruijn <willemb@google.com> Acked-by:
Vinicius Costa Gomes <vinicius.gomes@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Eric Dumazet says: ==================== bonding: report transmit status to callers First patches cleanup netpoll, and make sure it provides tx status to its users. Last patch changes bonding to not pretend packets were sent without error. By providing more accurate status, TCP stack can avoid adding more packets if the slave qdisc is already full. This came while testing latest horizon feature in sch_fq, with very low pacing rate flows, but should benefit hosts under stress. ==================== Signed-off-by: -
Eric Dumazet authored
Currently, bonding always returns NETDEV_TX_OK to its caller. It is worth trying to be more accurate : TCP for instance can have different recovery strategies if it can have more precise status, if packet was dropped by slave qdisc. This is especially important when host is under stress. Signed-off-by:
-
Eric Dumazet authored
netpoll_send_skb() callers seem to leak skb if the np pointer is NULL. While this should not happen, we can make the code more robust. Signed-off-by:
-
Eric Dumazet authored
Some callers want to know if the packet has been sent or dropped, to inform upper stacks. Signed-off-by:
-
Eric Dumazet authored
There is no need to inline this helper, as we intend to add more code in this function. Signed-off-by:
-
Eric Dumazet authored
netpoll_send_skb_on_dev() can get the device pointer directly from np->dev Rename it to __netpoll_send_skb() Following patch will move netpoll_send_skb() out-of-line. Signed-off-by:
-
Colin Ian King authored
The unsigned variable val is being checked for an error by checking if it is less than zero. This can never occur because val is unsigned. Fix this by making val a plain int. Addresses-Coverity: ("Unsigned compared against zero") Fixes: bdbdac76 ("ethtool: provide UAPI for PHY master/slave configuration.") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
