Yan-Hsuan Chuang [Thu, 12 Mar 2020 08:08:49 +0000 (16:08 +0800)]
rtw88: extract alloc rsvd_page and h2c skb routines
Extract skb allocation routines for rsvd_page and h2c.
These routines should also be used by USB and SDIO.
This should not change the logic at all.
memset() for pkt_info is unnecessary, just declare as {0}.
Also skb_put()/memcpy() can be replaced by skb_put_data().
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-3-yhchuang@realtek.com
Brian Norris [Thu, 12 Mar 2020 08:08:48 +0000 (16:08 +0800)]
rtw88: don't hold all IRQs disabled for PS operations
This driver generally only needs to ensure that
(a) it doesn't try to process TX interrupts at the same time as
power-save operations (and similar)
(b) the device interrupt gets disabled while we're still handling the
last set of interrupts
For (a), all the operations (e.g., PS transitions, packet handling)
happens in non-atomic contexts (e.g., threaded IRQ).
For (b), we only need mutual exclusion for brief sections (i.e., while
we're actually manipulating the interrupt mask/status).
So, we can introduce a separate lock for handling (b), disabling IRQs
while we do it. For (a), we can demote the locking to BH only, now that
(b) (the only steps done in atomic context) and that has its own lock.
This helps reduce the amount of time this driver spends with IRQs off.
Notably, transitioning out of power-save modes can take >3 milliseconds,
and this transition is done under the protection of 'irq_lock'.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200312080852.16684-2-yhchuang@realtek.com
Gustavo A. R. Silva [Thu, 19 Mar 2020 23:06:17 +0000 (18:06 -0500)]
wl3501_cs: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200319230617.GA15035@embeddedor.com
Gustavo A. R. Silva [Thu, 19 Mar 2020 23:05:25 +0000 (18:05 -0500)]
ray_cs: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200319230525.GA14835@embeddedor.com
Gustavo A. R. Silva [Thu, 19 Mar 2020 22:51:33 +0000 (17:51 -0500)]
atmel: at76c50x: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200319225133.GA29672@embeddedor.com
Gustavo A. R. Silva [Thu, 19 Mar 2020 22:50:02 +0000 (17:50 -0500)]
adm80211: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200319225002.GA28673@embeddedor.com
Gustavo A. R. Silva [Thu, 5 Mar 2020 11:14:01 +0000 (05:14 -0600)]
cw1200: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200305111401.GA25126@embeddedor
Gustavo A. R. Silva [Thu, 5 Mar 2020 11:12:16 +0000 (05:12 -0600)]
zd1211rw: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200305111216.GA24982@embeddedor
Gustavo A. R. Silva [Tue, 25 Feb 2020 02:08:04 +0000 (20:08 -0600)]
brcmfmac: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200225020804.GA9428@embeddedor
Gustavo A. R. Silva [Tue, 25 Feb 2020 02:04:13 +0000 (20:04 -0600)]
wireless: marvell: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200225020413.GA8057@embeddedor
Gustavo A. R. Silva [Tue, 25 Feb 2020 01:18:46 +0000 (19:18 -0600)]
p54: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200225011846.GA2773@embeddedor
Gustavo A. R. Silva [Tue, 25 Feb 2020 01:17:09 +0000 (19:17 -0600)]
libertas: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200225011709.GA601@embeddedor
Gustavo A. R. Silva [Tue, 25 Feb 2020 01:14:15 +0000 (19:14 -0600)]
orinoco: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200225011415.GA31868@embeddedor
Gustavo A. R. Silva [Tue, 25 Feb 2020 01:11:51 +0000 (19:11 -0600)]
hostap: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200225011151.GA30675@embeddedor
Gustavo A. R. Silva [Tue, 25 Feb 2020 00:34:08 +0000 (18:34 -0600)]
wireless: ti: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200225003408.GA28675@embeddedor
Gustavo A. R. Silva [Tue, 25 Feb 2020 00:27:46 +0000 (18:27 -0600)]
wireless: realtek: Replace zero-length array with flexible-array member
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]
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
76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200225002746.GA26789@embeddedor
Kalle Valo [Wed, 18 Mar 2020 12:05:09 +0000 (14:05 +0200)]
Merge tag 'iwlwifi-next-for-kalle-2020-03-17' of git://git./linux/kernel/git/iwlwifi/iwlwifi-next
First set of iwlwifi patches intended for v5.7
* Refactoring of the device selection algorithms;
Kalle Valo [Wed, 18 Mar 2020 12:01:24 +0000 (14:01 +0200)]
Merge tag 'mt76-for-kvalo-2020-03-17' of https://github.com/nbd168/wireless
mt76 patches for 5.7
* MT7663 support for the MT7615 driver
* USB fixes
* DBDC fixes for MT7615
* MT76x02 watchdog fixes
* Injection fix for MT7615
* Sensitivity fix for MT7615
* MCU support code cleanup
Luca Coelho [Mon, 9 Mar 2020 07:16:19 +0000 (09:16 +0200)]
iwlwifi: move AX200 devices to the new table
Move the AX200 devices to the new table and add the appropriate cfg
struct and strings.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.fdfa5f31b8b1.Idfd28829d9f3820de06d3bba8fa66048b8d0d0b0@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:18 +0000 (09:16 +0200)]
iwlwifi: remove trans entries from COMMON 9260 macro
These entries are decided at runtime using the new parameters now, so
they are not needed in the macro that is reused in the configs.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.3387a6c8fdbe.I98284457f26c5695754964b28f0257a7dc7c6b1c@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:17 +0000 (09:16 +0200)]
iwlwifi: move shared clock entries to new table
These devices can now also be fully differentiated by using the new
parameters. Move them all to the new table format.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.11c65d195677.I8faf50b325282df4892520a3b21fbdedabbb64f0@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:16 +0000 (09:16 +0200)]
iwlwifi: move pu devices to new table
All the pu devices can now be differentiated using the new
parameters, so move them all to the new tables accordingly.
This also includes removal of a few deprecated IDs and redundant cfg
structs.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.e7dc61e665f3.I44dcf9195bb8cc9e8c8e3e87182e9185c819a99d@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:15 +0000 (09:16 +0200)]
iwlwifi: remove 9260 devices with 0x1010 and 0x1210 subsytem IDs
These devices don't exist anymore, so remove them from the tables.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.fef62aa45887.I302e32b7cfff7da0d920547fae60ad9f2296e052@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:14 +0000 (09:16 +0200)]
iwlwifi: convert the 9260-1x1 device to use the new parameters
The 9260-1x1 device can be differentiated using the PCI device ID.
There is a single occurrence of this device, so continue relying on
the device and subsystem device IDs.
The name of this device was incorrect, so add a new string
specifically for it.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.4d74e1be7cac.Id27bd9c878b73cb771691cbe6082fd40e079b44d@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:13 +0000 (09:16 +0200)]
iwlwifi: move TH1 devices to the new table
TH1 devices can now be fully differentiated by using the device
parameters we have (particularly the RF_TYPE). Start using these
parameters instead of hardcoding to specific subsystem device IDs.
This also fixes the name of one of the TH1 devices that was
erroneously using the 9260 struct and renames 9160 to 9162.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.18d4304b5454.Ib168d186da88393e9ec46f0fca523edb48d9138e@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:12 +0000 (09:16 +0200)]
iwlwifi: map 9461 and 9462 using RF type and RF ID
These devices can be differentiated depending on the RF type and RF
ID. Change them to use these instead of relying on the subsystem
device IDs.
This also fixes some names that were not including 160MHz (as they
should).
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.345de1efb3ec.Ib9221027a955188ea7c1ffca8a45bccd6c1e6a13@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:11 +0000 (09:16 +0200)]
iwlwifi: add Pu/PnJ/Th device values to differentiate them
Pu, PnJ and Th devices have different combinations of PCI ID, MAC ID
and RF IDs. Use these to differentiate them and choose the correct
configuration.
This also includes a change from using soc cfg's for 0x2526
devices (PnJ/Th), which was incorrect.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.602bb33528cf.I3acacb07c69ed063c7f1ca78f2dce9b7b4ef3946@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:10 +0000 (09:16 +0200)]
iwlwifi: add GNSS differentiation to the device tables
Devices that also include a GNSS module have different names, so add a
new device option to differentiate them, according to the values we
have in the modules section of the subsystem device ID.
Additionally, convert the two applicable devices to use this value
instead of hardcoded subsystem IDs.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.1f958e558d05.I45492bb57cbbeb4cc0ec84313bade4def7377a27@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:09 +0000 (09:16 +0200)]
iwlwifi: add mac/rf types and 160MHz to the device tables
Add MAC ID, RF ID and the bit that tells us whether the device can
handle 160MHz bandwidth to the device struct.
This allows us to chose the correct structure and string depending on
these parameters. Do so for all the 0x2526 devices we already moved
to the new table.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.a6bef6ee8fe1.I01f7a6f49aa60d2d61633a8a8b859015681eac5b@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:08 +0000 (09:16 +0200)]
iwlwifi: combine 9260 cfgs that only change names
All the 0x2526 devices are now in the new table, so we can start
reusing configurations and adding the strings independently to all of
them, reusing them when possible.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.88e3d47c42a8.I1bd37ae0d0f9f79732f03badf84d7d063993b73e@changeid
Luca Coelho [Mon, 9 Mar 2020 07:16:07 +0000 (09:16 +0200)]
iwlwifi: move the remaining 0x2526 configs to the new table
Now that we have the strings separate from the rest, we can move the
remaining 0x2526 devices to the new table in preparation to reuse the
configs.
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200309091348.a7998f8d7507.I4be8776edb8c30416efc184c66f11add5eed06de@changeid
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:32 +0000 (17:41 +0100)]
mt76: mt7615: introduce mt7663e support
Introduce support for mt7663e 802.11ac 2x2:2 chipset to mt7615 driver.
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:31 +0000 (17:41 +0100)]
mt76: mt7615: get rid of sta_rec_wtbl data structure
Sobstitute sta_rec_wtbl data structure with tlv one
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:30 +0000 (17:41 +0100)]
mt76: mt7615: introduce set_ba uni command
Introduce mt7615_mcu_uni_set_ba routine in order to add support
for mt7663e driver
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Sean Wang [Tue, 17 Mar 2020 16:41:29 +0000 (17:41 +0100)]
mt76: mt7615: add more uni mcu commands
Introduce mt7615_mcu_uni_set_bss, mt7615_mcu_uni_set_dev and
mt7615_mcu_uni_set_beacon_offload uni mcu commands. This is a
preliminary patch to add mt7663e support
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:28 +0000 (17:41 +0100)]
mt76: mt7615: introduce set_bmc and st_sta for uni commands
Introduce mt7615_mcu_uni_set_bmc and mt7615_mcu_uni_set_sta routines for
mt7663e commands.
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-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 [Tue, 17 Mar 2020 16:41:27 +0000 (17:41 +0100)]
mt76: mt7615: introduce uni cmd command types
Introduce mcu uni command type. Uni commands rely on a stripped verions
of mt7615_mcu_txd data strutture. Split mt7615_mcu_txd_common and
mt7615_mcu_txd. Uni commands will be use by mt7663e driver
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-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 [Tue, 17 Mar 2020 16:41:26 +0000 (17:41 +0100)]
mt76: mt7615: introduce mt7615_init_mac_chain routine
Introduce mt7615_init_mac_chain routine to configure per band mac
register since new devices (e.g. mt7663e) do not support dbdc
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:25 +0000 (17:41 +0100)]
mt76: mt7615: introduce mt7615_eeprom_parse_hw_band_cap routine
Introduce mt7615_eeprom_parse_hw_band_cap routine in order to configure
supported band for mt7663e and mt7622 devices since they do not rely on
eeprom data to enable 2GHz/5GHz bands
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:24 +0000 (17:41 +0100)]
mt76: mt7615: add mt7663e support to mt7615_mcu_set_eeprom
Extend mt7615_mcu_set_eeprom routine in order to be reused
adding mt7663e support to mt7615 driver
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:23 +0000 (17:41 +0100)]
mt76: mt7615: add mt7663e support to mt7615_{driver,firmware}_own
Extend mt7615_driver_own and mt7615_firmware_own in order to reuse
them adding mt7663e support to mt7615 driver
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:22 +0000 (17:41 +0100)]
mt76: mt7615: add mt7663e support to mt7615_reg_map
Introduce mt7663e support to mt7615_reg_map routine in order to reuse it
adding support for mt7663e driver
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:21 +0000 (17:41 +0100)]
mt76: mt7615: introduce mt7615_register_map
In order to reuse mt7615 code adding support for mt7663e driver,
introduce mt7615e_reg_map since mt7663e and mt7615 rely on a
different base registers definitions.
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:20 +0000 (17:41 +0100)]
mt76: mt7615: introduce MCU_FW_PREFIX for fw mcu commands
Currently fw commands rely on negative cmds since they need different
mcu msg metadata. Extend this approach introducing MCU_FW_PREFIX.
This is a preliminary patch to support new mt7663e firmware commands
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:19 +0000 (17:41 +0100)]
mt76: mt7615: move more mcu commands in mt7615_mcu_ops data structure
Move mt7615_mcu_set_beacon_offload, mt7615_mcu_set_dev and
mt7615_mcu_set_bss routine in mt7615_mcu_ops data structure.
This is a preliminary patch to support mt7663 firmware
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:18 +0000 (17:41 +0100)]
mt76: mt7615: rework mt7615_mcu_set_bss_info using skb APIs
Simplify mt7615_mcu_set_bss_info relying on mcu tlv helpers
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:17 +0000 (17:41 +0100)]
mt76: mt7615: rely on skb API for mt7615_mcu_set_eeprom
Rely on skb API and avoid kmalloc the buffer in mt7615_mcu_set_eeprom
routine
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:16 +0000 (17:41 +0100)]
mt76: mt7615: move mt7615_mcu_set_sta in mt7615_mcu_ops
Move mt7615_mcu_set_sta for fw version 1 and version 2 in mt7615_mcu_ops
data structure. This is a preliminary patch to properly support mt7663e
firmware.
Rework utility routines to rely on skb APIs for msg parsing
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:15 +0000 (17:41 +0100)]
mt76: mt7615: move mt7615_mcu_set_bmc to mt7615_mcu_ops
Move mt7615_mcu_set_bmc for fw version 1 and version 2 in
mt7615_mcu_ops data structure. This is a preliminary patch
to properly support mt7663e firmware.
Rework utility routines to rely on skb APIs for msg parsing
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:14 +0000 (17:41 +0100)]
mt76: mt7615: add mt7615_mcu_ops data structure
Introduce mt7615_mcu_ops data structure in order to support multiple
mcu ops API.
Move mt7615_mcu_set_{tx,rx}_ba to mt7615_mcu_ops differentiating between
fw v1 and v2. This is a preliminary patch to properly support mt7663e
firmware.
Rework utility routines to rely on skb APIs for msg parsing
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:13 +0000 (17:41 +0100)]
mt76: mt7615: introduce mt7615_mcu_send_message routine
Introduce mt7615_mcu_send_message routine in order to allocate mcu skb
out of mcu sending routine. This approach is useful when the mcu
message is complicated and it is convenient to rely on skb buffer API
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:12 +0000 (17:41 +0100)]
mt76: always init to 0 mcu messages
Always initialize to 0 mcu messages since if they are not propely
configured they could hang the firmware.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:11 +0000 (17:41 +0100)]
mt76: mt7615: introduce mt7615_init_device routine
Add mt7615_init_device routine in order to be reused adding support for
mt7663 in mt7615 driver
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:10 +0000 (17:41 +0100)]
mt76: mt7615: cleanup fw queue just for mmio devices
In order to reuse mt7615_mcu_send_firmware routine adding support for
usb devices, clean fw hw queue just for mmio devices
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 17 Mar 2020 16:41:09 +0000 (17:41 +0100)]
mt76: mt7615: introduce mt7615_mcu_wait_response
Introduce mt7615_mcu_wait_response in order to be reused parsing mt7663u
mcu messages
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-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 [Tue, 17 Mar 2020 16:41:08 +0000 (17:41 +0100)]
mt76: mt7615: introduce mt7615_mcu_fill_msg
Introduce mt7615_mcu_fill_msg routine to initialize mcu messages.
mt7615_mcu_fill_msg will be reused adding mt7663u support
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Chen Wandun [Wed, 4 Mar 2020 12:34:11 +0000 (20:34 +0800)]
mt76: remove variable 'val' set but not used
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c: In function mt76x0_phy_rf_init:
drivers/net/wireless/mediatek/mt76/mt76x0/phy.c:1158:5: warning: variable val set but not used [-Wunused-but-set-variable]
Fixes:
10de7a8b4ab9 ("mt76x0: phy files")
Signed-off-by: Chen Wandun <chenwandun@huawei.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Dan Carpenter [Wed, 11 Mar 2020 13:52:27 +0000 (16:52 +0300)]
mt76: mt7615: remove a stray if statement
This if statement was supposed to be deleted, but it wasn't. It means
that we sometimes don't set the sensitivity correctly.
Fixes:
2cad515ece8a ("mt76: mt7615: add missing settings for simultaneous dual-band support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Tue, 10 Mar 2020 16:10:59 +0000 (17:10 +0100)]
mt76: mt76x02: reset MCU timeout counter earlier in watchdog reset
Ensure that MCU commands issued right after hardware reset are not dropped
and treated as failed.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Mon, 17 Feb 2020 16:46:33 +0000 (17:46 +0100)]
mt76: mt7615: fix monitor injection of beacon frames
When injecting beacon frames via monitor interface, they must not be sent to
the beacon hardware queue, because they don't follow normal hardware beacon tx
rules.
Fix sending them by adding a flag to mt7615_mac_write_txwi that selects the
beacon queue for tx, and use it only from mt7615_mcu_set_bcn.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Tue, 26 Feb 2019 14:15:28 +0000 (15:15 +0100)]
mt76: mt7603: make dynamic sensitivity adjustment configurable via debugfs
In some cases it may be useful for debugging to disable this feature
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Sat, 22 Feb 2020 09:02:21 +0000 (10:02 +0100)]
mt76: mt7603: add upper limit for dynamic sensitivity minimum receive power
If the minimum power is raised too much, it can make it impossible for weaker
clients to connect, and there are some scenarios where the false detects will
not go down no matter how much the sensitivity is adjusted.
Fixes connectivity issues in some rare cases
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Felix Fietkau [Tue, 25 Feb 2020 12:15:33 +0000 (13:15 +0100)]
mt76: mt7615: fix antenna mask initialization in DBDC mode
Update wiphy available antenna mask, and fix chainmask setting on 3x3 hardware
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Thu, 20 Feb 2020 13:31:51 +0000 (14:31 +0100)]
mt76: mt76u: rely only on data buffer for usb control messagges
Starting from commit '
a6bfb6d13f33 ("mt76: usb: use max packet length
for m76u_copy")' reg_val does not share memory with usb data buffer.
On non-coherent devices this approach can corrupt data pointer since data
and reg_val share the same cache-line, resulting in the following crash:
[ 371.544901] CPU 0 Unable to handle kernel paging request at virtual address
00000000, epc ==
8042fbb0
[ 371.558521] CPU: 0 PID: 11 Comm: kworker/u2:2 Not tainted 4.14.160 #0
[ 371.565204] Workqueue: mt76u mt76u_deinit [mt76_usb]
[ 371.570331] task:
83823ac0 task.stack:
8386c000
[ 371.575004] $ 0 :
00000000 80590000 00000000 00000000
[ 371.580407] $ 4 :
82edaad0 00000002 83823ac0 fffffff8
[ 371.585810] $ 8 :
fffffffd 0000fc00 8052da00 00000000
[ 371.591212] $12 :
000b2285 ae53a1a9 00108845 89da44c4
[ 371.596615] $16 :
82edaad0 82ed9d20 00001798 832edf00
[ 371.602019] $20 :
00000000 8386dda8 80530000 fffffffe
[ 371.607421] $24 :
8051d040 76274d1b
[ 371.612824] $28 :
8386c000 8386dd88 82edaad4 830d4d50
[ 371.618228] Hi :
000000f7
[ 371.621203] Lo :
33333371
[ 371.624196] epc :
8042fbb0 __mutex_lock.isra.2+0x134/0x378
[ 371.630043] ra :
830d4d50 mt76u_deinit+0x418/0xa6c [mt76_usb]
[ 371.636237] Status: 1000fc03KERNEL EXL IE
[ 371.640557] Cause :
0080000c (ExcCode 03)
[ 371.644696] BadVA :
00000000
[ 371.647671] PrId :
00019374 (MIPS 24Kc)
[ 371.726123] usbcore nls_base usb_common
[ 371.730180] Process kworker/u2:2 (pid: 11, threadinfo=
8386c000, task=
83823ac0, tls=
00000000)
[ 371.738884] Stack :
833d009c 83210b4c 82ed8bc0 8386ddac 000001ff 8008ac50 8386ddac 83b74b00
[ 371.747519]
82edaad4 00000000 83b74b48 83210c38 82edaad0 82ed9d20 00001798 832edf00
[ 371.756157]
00000000 00000000 80530000 fffffffe 80530000 830d4d50 00000040 8389d850
[ 371.764794]
8052d9d8 8389d850 8386de30 82ed9d20 8386de5f 831c27bc 833d48ec 8052d9d8
[ 371.773431]
83823ac0 83823af0 82edab00 82ed9d20 8386de5f 831c5c30 00000000 8052d9a8
[ 371.782069] ...
[ 371.784598] Call Trace:
[ 371.787130] [<
8042fbb0>] __mutex_lock.isra.2+0x134/0x378
[ 371.792622] [<
830d4d50>] mt76u_deinit+0x418/0xa6c [mt76_usb]
[ 371.808546]
[ 371.810920] ---[ end trace
c62f0601f6730eb0 ]---
[ 371.818101] Kernel panic - not syncing: Fatal exception
[ 371.824420] Rebooting in 3 seconds..
Fix the issue relying only on data buffer to send/receive usb control messages
Fixes:
a6bfb6d13f33 ("mt76: usb: use max packet length for m76u_copy")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Tue, 18 Feb 2020 18:17:12 +0000 (19:17 +0100)]
mt76: mt76u: fix a possible memory leak in mt76u_init
Remove usb workqueue if mt76u_set_endpoints fails.
Fixes:
284efb473ef5 ("mt76: mt76u: rely on a dedicated stats workqueue")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Sat, 15 Feb 2020 10:31:31 +0000 (11:31 +0100)]
mt76: mt76u: loop over all possible rx queues in mt76u_rx_tasklet
Loop over all possible hw rx queues in mt76u_rx_tasklet since new
devices will report mcu events through mcu hw queue
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Kalle Valo [Mon, 16 Mar 2020 05:29:55 +0000 (07:29 +0200)]
Merge ath-next from git://git./linux/kernel/git/kvalo/ath.git
ath.git patches for v5.7. Major changes:
ath10k
* support for getting btcoex settings from Device Tree
* support QCA9377 SDIO device
ath11k
* add HE rate accounting
* add thermal sensor and cooling devices
Takashi Iwai [Wed, 11 Mar 2020 09:17:39 +0000 (10:17 +0100)]
ssb: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Takashi Iwai [Wed, 11 Mar 2020 08:47:13 +0000 (09:47 +0100)]
prism54: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Cc: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Takashi Iwai [Wed, 11 Mar 2020 08:47:12 +0000 (09:47 +0100)]
ipw2x00: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Cc: Stanislav Yakovlev <stas.yakovlev@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Takashi Iwai [Wed, 11 Mar 2020 08:47:11 +0000 (09:47 +0100)]
b43legacy: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: b43-dev@lists.infradead.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Takashi Iwai [Wed, 11 Mar 2020 08:47:10 +0000 (09:47 +0100)]
b43: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Cc: b43-dev@lists.infradead.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Takashi Iwai [Wed, 11 Mar 2020 08:47:09 +0000 (09:47 +0100)]
carl9170: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Cc: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Sergiu Cuciurean [Thu, 27 Feb 2020 14:06:34 +0000 (16:06 +0200)]
libertas: Use new structure for SPI transfer delays
In a recent change to the SPI subsystem [1], a new `delay` struct was added
to replace the `delay_usecs`. This change replaces the current
`delay_usecs` with `delay` for this driver.
The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure
that both `delay_usecs` & `delay` are used (in this order to preserve
backwards compatibility).
[1] commit
bebcfd272df6 ("spi: introduce `delay` field for
`spi_transfer` + spi_transfer_delay_exec()")
Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Brian Norris [Thu, 27 Feb 2020 00:05:11 +0000 (16:05 -0800)]
mwifiex: set needed_headroom, not hard_header_len
hard_header_len provides limitations for things like AF_PACKET, such
that we don't allow transmitting packets smaller than this.
needed_headroom provides a suggested minimum headroom for SKBs, so that
we can trivally add our headers to the front.
The latter is the correct field to use in this case, while the former
mostly just prevents sending small AF_PACKET frames.
In any case, mwifiex already does its own bounce buffering [1] if we
don't have enough headroom, so hints (not hard limits) are all that are
needed.
This is the essentially the same bug (and fix) that brcmfmac had, fixed
in commit
cb39288fd6bb ("brcmfmac: use ndev->needed_headroom to reserve
additional header space").
[1] mwifiex_hard_start_xmit():
if (skb_headroom(skb) < MWIFIEX_MIN_DATA_HEADER_LEN) {
[...]
/* Insufficient skb headroom - allocate a new skb */
Fixes:
5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Acked-by: Ganapathi Bhat <ganapathi.gbhat@nxp.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Xu Wang [Fri, 21 Feb 2020 10:43:03 +0000 (18:43 +0800)]
iwlegacy: Remove unneeded variable ret
Remove unneeded variable ret used to store return value.
Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
chenqiwu [Wed, 19 Feb 2020 04:15:59 +0000 (12:15 +0800)]
b43legacy: replace simple_strtol() with kstrtoint()
The simple_strtol() function is deprecated since it does not
check for the range overflow. Use kstrtoint() instead.
Signed-off-by: chenqiwu <chenqiwu@xiaomi.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Kevin Lo [Fri, 14 Feb 2020 14:16:45 +0000 (22:16 +0800)]
rtw88: remove unused member of struct rtw_hal
Remove unused fab_version member from struct rtw_hal.
Some of the checks being made were nonsense.
Signed-off-by: Kevin Lo <kevlo@kevlo.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Dmitry Lebed [Thu, 13 Feb 2020 11:45:32 +0000 (11:45 +0000)]
qtnfmac: add interface combination check for repeater mode
Firmware supports only STA as primary interface in repeater mode.
Since the only meaningful usage of AP + STA interface combination
is repeater, reject such combination with AP as primary interface.
Signed-off-by: Dmitry Lebed <dlebed@quantenna.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Sergey Matyukevich [Thu, 13 Feb 2020 11:45:31 +0000 (11:45 +0000)]
qtnfmac: assign each wiphy to its own virtual platform device
Quantenna Pearl device exposes multiple (up to 3) radio interfaces under
single PCIe function. So far all the wiphy devices were attached to the
same pcie device. As a result, all different wireless network devices
were reported under the same sysfs directory for pcie device, e.g.:
$ ls /sys/class/net/wlan0/device/net/
wlan0 wlan1
It turns out that such behavior may confuse various users of wireless
subsystem. For instance, it turned out to be the case for:
- Linux init systems, e.g. for renaming based on parent device
- OpenWRT configuration scripts
Suggested solution is to add an intermediate virtual platform device
for each radio interface.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Sergey Matyukevich [Thu, 13 Feb 2020 11:45:30 +0000 (11:45 +0000)]
qtnfmac: set valid edmg in cfg80211_chan_def
Make sure that edmg field of cfg80211_chan_def structure is properly
initialized by zeros. Otherwise cfg80211_chandef_valid may return
false if edmg fields contain some garbage.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Sergey Matyukevich [Thu, 13 Feb 2020 11:45:29 +0000 (11:45 +0000)]
qtnfmac: support WPA3 OWE in AP mode
Enable WPA3 OWE support in AP mode. Driver currently supports cards that
offload OWE processing to userspace. This patch adds all the required
tools for such offloading. Firmware requests OWE processing sending new
UPDATE_OWE event to driver, which uses cfg80211_update_owe_info_event to
notify userspace software. After OWE processing is completed, userspace
sends calculated IEs to firmware using update_owe_info cfg80211 callback.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Sergey Matyukevich [Thu, 13 Feb 2020 11:45:28 +0000 (11:45 +0000)]
qtnfmac: support WPA3 SAE in AP mode
Enable WPA3 SAE support in AP mode. Driver currently supports cards
that offload SAE authentication to userspace. So allow userspace
software to subscribe and to send AUTH frames. Besides, enable
AP mode support in external_auth cfg80211 callback.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Takashi Iwai [Wed, 11 Mar 2020 08:47:08 +0000 (09:47 +0100)]
ath5k: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Cc: Jiri Slaby <jirislaby@gmail.com>
Cc: Nick Kossifidis <mickflemm@gmail.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Takashi Iwai [Wed, 11 Mar 2020 08:47:07 +0000 (09:47 +0100)]
ath11k: Use scnprintf() for avoiding potential buffer overflow
Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit. Fix it by replacing with scnprintf().
Cc: ath11k@lists.infradead.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yibo Zhao [Wed, 11 Mar 2020 17:23:29 +0000 (19:23 +0200)]
ath10k: allow qca988x family to support ack rssi of tx data packets.
Hardwares tested : QCA9887
Firmwares tested : 10.4-3.9.0.1-00036
Signed-off-by: Yibo Zhao <yiboz@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Alex Elder [Wed, 11 Mar 2020 21:47:00 +0000 (16:47 -0500)]
dt-bindings: soc: qcom: fix IPA binding
The definitions for the "qcom,smem-states" and "qcom,smem-state-names"
properties need to list their "$ref" under an "allOf" keyword.
In addition, fix two problems in the example at the end:
- Use #include for header files that define needed symbolic values
- Terminate the line that includes the "ipa-shared" register space
name with a comma rather than a semicolon
Finally, update some white space in the example for better alignment.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Davide Caratti [Wed, 11 Mar 2020 18:50:53 +0000 (19:50 +0100)]
net: mptcp: don't hang before sending 'MP capable with data'
the following packetdrill script
socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress)
> S 0:0(0) <mss 1460,sackOK,TS val 100 ecr 0,nop,wscale 8,mpcapable v1 flags[flag_h] nokey>
< S. 0:0(0) ack 1 win 65535 <mss 1460,sackOK,TS val 700 ecr 100,nop,wscale 8,mpcapable v1 flags[flag_h] key[skey=2]>
> . 1:1(0) ack 1 win 256 <nop, nop, TS val 100 ecr 700,mpcapable v1 flags[flag_h] key[ckey,skey]>
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
fcntl(3, F_SETFL, O_RDWR) = 0
write(3, ..., 1000) = 1000
doesn't transmit 1KB data packet after a successful three-way-handshake,
using mp_capable with data as required by protocol v1, and write() hangs
forever:
PID: 973 TASK:
ffff97dd399cae80 CPU: 1 COMMAND: "packetdrill"
#0 [
ffffa9b94062fb78] __schedule at
ffffffff9c90a000
#1 [
ffffa9b94062fc08] schedule at
ffffffff9c90a4a0
#2 [
ffffa9b94062fc18] schedule_timeout at
ffffffff9c90e00d
#3 [
ffffa9b94062fc90] wait_woken at
ffffffff9c120184
#4 [
ffffa9b94062fcb0] sk_stream_wait_connect at
ffffffff9c75b064
#5 [
ffffa9b94062fd20] mptcp_sendmsg at
ffffffff9c8e801c
#6 [
ffffa9b94062fdc0] sock_sendmsg at
ffffffff9c747324
#7 [
ffffa9b94062fdd8] sock_write_iter at
ffffffff9c7473c7
#8 [
ffffa9b94062fe48] new_sync_write at
ffffffff9c302976
#9 [
ffffa9b94062fed0] vfs_write at
ffffffff9c305685
#10 [
ffffa9b94062ff00] ksys_write at
ffffffff9c305985
#11 [
ffffa9b94062ff38] do_syscall_64 at
ffffffff9c004475
#12 [
ffffa9b94062ff50] entry_SYSCALL_64_after_hwframe at
ffffffff9ca0008c
RIP:
00007f959407eaf7 RSP:
00007ffe9e95a910 RFLAGS:
00000293
RAX:
ffffffffffffffda RBX:
0000000000000008 RCX:
00007f959407eaf7
RDX:
00000000000003e8 RSI:
0000000001785fe0 RDI:
0000000000000008
RBP:
0000000001785fe0 R8:
0000000000000000 R9:
0000000000000003
R10:
0000000000000007 R11:
0000000000000293 R12:
00000000000003e8
R13:
00007ffe9e95ae30 R14:
0000000000000000 R15:
0000000000000000
ORIG_RAX:
0000000000000001 CS: 0033 SS: 002b
Fix it ensuring that socket state is TCP_ESTABLISHED on reception of the
third ack.
Fixes:
1954b86016cf ("mptcp: Check connection state before attempting send")
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Colin Ian King [Wed, 11 Mar 2020 09:16:13 +0000 (09:16 +0000)]
soc: qcom: ipa: fix spelling mistake "cahces" -> "caches"
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Chen Zhou [Wed, 11 Mar 2020 06:54:11 +0000 (14:54 +0800)]
net: ibm: remove set but not used variables 'err'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/ibm/emac/core.c: In function __emac_mdio_write:
drivers/net/ethernet/ibm/emac/core.c:875:9: warning:
variable err set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jules Irenge [Wed, 11 Mar 2020 01:09:06 +0000 (01:09 +0000)]
net: Add missing annotation for *netlink_seq_start()
Sparse reports a warning at netlink_seq_start()
warning: context imbalance in netlink_seq_start() - wrong count at exit
The root cause is the missing annotation at netlink_seq_start()
Add the missing __acquires(RCU) annotation
Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jules Irenge [Wed, 11 Mar 2020 01:09:03 +0000 (01:09 +0000)]
tcp: Add missing annotation for tcp_child_process()
Sparse reports warning at tcp_child_process()
warning: context imbalance in tcp_child_process() - unexpected unlock
The root cause is the missing annotation at tcp_child_process()
Add the missing __releases(&((child)->sk_lock.slock)) annotation
Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jules Irenge [Wed, 11 Mar 2020 01:09:02 +0000 (01:09 +0000)]
raw: Add missing annotations to raw_seq_start() and raw_seq_stop()
Sparse reports warnings at raw_seq_start() and raw_seq_stop()
warning: context imbalance in raw_seq_start() - wrong count at exit
warning: context imbalance in raw_seq_stop() - unexpected unlock
The root cause is the missing annotations at raw_seq_start()
and raw_seq_stop()
Add the missing __acquires(&h->lock) annotation
Add the missing __releases(&h->lock) annotation
Signed-off-by: Jules Irenge <jbi.octave@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Julian Wiedmann [Tue, 10 Mar 2020 16:53:35 +0000 (17:53 +0100)]
net: sched: make newly activated qdiscs visible
In their .attach callback, mq[prio] only add the qdiscs of the currently
active TX queues to the device's qdisc hash list.
If a user later increases the number of active TX queues, their qdiscs
are not visible via eg. 'tc qdisc show'.
Add a hook to netif_set_real_num_tx_queues() that walks all active
TX queues and adds those which are missing to the hash list.
CC: Eric Dumazet <edumazet@google.com>
CC: Jamal Hadi Salim <jhs@mojatatu.com>
CC: Cong Wang <xiyou.wangcong@gmail.com>
CC: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pavel Machek [Mon, 9 Mar 2020 22:33:23 +0000 (23:33 +0100)]
net: slcan, slip -- no need for goto when if () will do
No need to play with gotos to jump over single statement.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jose Abreu [Mon, 9 Mar 2020 13:30:22 +0000 (14:30 +0100)]
net: stmmac: selftests: Fix L3/L4 Filtering test
Since commit
319a1d19471e, stmmac only support basic HW stats type for
action. Set this field in the L3/L4 Filtering test so that it correctly
setups the filter instead of returning EOPNOTSUPP.
Fixes:
319a1d19471e ("flow_offload: check for basic action hw stats type")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Bersenev [Thu, 5 Mar 2020 20:33:16 +0000 (01:33 +0500)]
cdc_ncm: Implement the 32-bit version of NCM Transfer Block
The NCM specification defines two formats of transfer blocks: with 16-bit
fields (NTB-16) and with 32-bit fields (NTB-32). Currently only NTB-16 is
implemented.
This patch adds the support of NTB-32. The motivation behind this is that
some devices such as E5785 or E5885 from the current generation of Huawei
LTE routers do not support NTB-16. The previous generations of Huawei
devices are also use NTB-32 by default.
Also this patch enables NTB-32 by default for Huawei devices.
During the 2019 ValdikSS made five attempts to contact Huawei to add the
NTB-16 support to their router firmware, but they were unsuccessful.
Signed-off-by: Alexander Bersenev <bay@hackerdom.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Martin Varghese [Thu, 12 Mar 2020 03:03:51 +0000 (08:33 +0530)]
bareudp: Fixed bareudp receive handling
Reverted commit "2baecda bareudp: remove unnecessary udp_encap_enable() in
bareudp_socket_create()"
An explicit call to udp_encap_enable is needed as the setup_udp_tunnel_sock
does not call udp_encap_enable if the if the socket is of type v6.
Bareudp device uses v6 socket to receive v4 & v6 traffic
CC: Taehee Yoo <ap420073@gmail.com>
Fixes:
2baecda37f4e ("bareudp: remove unnecessary udp_encap_enable() in bareudp_socket_create()")
Signed-off-by: Martin Varghese <martin.varghese@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
tangbin [Wed, 11 Mar 2020 02:05:37 +0000 (10:05 +0800)]
ftgmac100: Remove redundant judgement
In this function, ftgmac100_probe() can be triggered only
if the platform_device and platform_driver matches, so the
judgement at the beginning is redundant.
Signed-off-by: tangbin <tangbin@cmss.chinamobile.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remi Pommarel [Sat, 29 Feb 2020 16:13:47 +0000 (17:13 +0100)]
ath9k: Handle txpower changes even when TPC is disabled
When TPC is disabled IEEE80211_CONF_CHANGE_POWER event can be handled to
reconfigure HW's maximum txpower.
This fixes 0dBm txpower setting when user attaches to an interface for
the first time with the following scenario:
ieee80211_do_open()
ath9k_add_interface()
ath9k_set_txpower() /* Set TX power with not yet initialized
sc->hw->conf.power_level */
ieee80211_hw_config() /* Iniatilize sc->hw->conf.power_level and
raise IEEE80211_CONF_CHANGE_POWER */
ath9k_config() /* IEEE80211_CONF_CHANGE_POWER is ignored */
This issue can be reproduced with the following:
$ modprobe -r ath9k
$ modprobe ath9k
$ wpa_supplicant -i wlan0 -c /tmp/wpa.conf &
$ iw dev /* Here TX power is either 0 or 3 depending on RF chain */
$ killall wpa_supplicant
$ iw dev /* TX power goes back to calibrated value and subsequent
calls will be fine */
Fixes:
283dd11994cde ("ath9k: add per-vif TX power capability")
Cc: stable@vger.kernel.org
Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>