Yan-Hsuan Chuang [Wed, 18 Mar 2020 09:52:24 +0000 (17:52 +0800)]
rtw88: 8822c: config RF table path B before path A
After MAC switched power, the hardware's RF registers will have
its default value, but the default value for path B is incorrect.
So, load RF path B first, to decrease the period between MAC on
and RF path B config.
By test, if we load path A first, then there's ~300ms that the
path B is incorrect, it could lead to BT coex's A2DP glitch.
But if we configure path B first, there will only have ~3ms,
significantly lower possibility to have A2DP sound glitch.
Yan-Hsuan Chuang [Thu, 12 Mar 2020 08:08:52 +0000 (16:08 +0800)]
rtw88: kick off TX packets once for higher efficiency
Driver used to kick off every TX packets, that will waste some
time while we can do better to kick off the TX packets once after
they are all prepared to be transmitted.
For PCI, it uses DMA engine to transfer the SKBs to the device,
and the transition of the state of the DMA engine could be a cost.
Driver can save some time to kick off multiple SKBs once so that
the DMA engine will have only one transition.
So, split rtw_hci_ops::tx() to rtw_hci_ops::tx_write() and
rtw_hci_ops::tx_kick_off() to explicitly kick the SKBs off after
they are written to the prepared buffer. For packets come from
ieee80211_ops::tx(), write one and then kick it off immediately.
For packets queued in TX queue, which come from
ieee80211_ops::wake_tx_queue(), we can dequeue them, write them
to the buffer, and then kick them off together.
Yan-Hsuan Chuang [Thu, 12 Mar 2020 08:08:51 +0000 (16:08 +0800)]
rtw88: pci: define a mask for TX/RX BD indexes
Add a macro TRX_BD_IDX_MASK for access the TX/RX BD indexes.
The hardware has only 12 bits for TX/RX BD indexes, we should not
initialize a TX/RX ring or access the TX/RX BD index with a length
that is larger than TRX_BD_IDX_MASK.
Yan-Hsuan Chuang [Thu, 12 Mar 2020 08:08:50 +0000 (16:08 +0800)]
rtw88: associate reserved pages with each vif
Each device has only one reserved page shared with all of the
vifs, so it seems not reasonable to pass vif as one of the
arguments to rtw_fw_download_rsvd_page(). If driver is going
to run more than one vif, the content of reserved page could
not be built for all of the vifs.
To fix it, let each vif maintain its own reserved page list,
and build the final reserved page to download to the firmware
from all of the vifs. Hence driver should add reserved pages
to each vif according to the vif->type when adding the vif.
For station mode, add reserved page with rtw_add_rsvd_page_sta().
If the station mode is going to suspend in PNO (net-detect)
mode, remove the reserved pages used for normal mode, and add
new one for wowlan mode with rtw_add_rsvd_page_pno().
For beacon mode, only beacon is required to be added using
rtw_add_rsvd_page_bcn().
This would make the code flow simpler as we don't need to
add reserved pages when vif is running, just add/remove them
when ieee80211_ops::[add|remove]_interface.
When driver is going to download the reserved page, it will
collect pages from all of the vifs, this list is maintained
by rtwdev, with build_list as the pages' member. That way, we
can still build a list of reserved pages to be downloaded.
Also we can get the location of the pages from the list that
is maintained by rtwdev.
The biggest problem is that the first page should always be
beacon, if other type of reserved page is put in the first
page, the tx descriptor and offset could be wrong.
But station mode vif does not add beacon into its list, so
we need to add a dummy page in front of the list, to make
sure other pages will not be put in the first page. As the
dummy page is allocated when building the list, we must free
it before building a new list of reserved pages to firmware.
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().
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'.
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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: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.
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.
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.
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.
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.
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: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>
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: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>
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: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]
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.
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
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:
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>
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>
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>
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>
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>
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>
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>
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>
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:
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>
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>
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>
projects / mirror_ubuntu-hirsute-kernel.git / log