linux-stable.git/drivers/net/wireless/realtek, branch linux-5.7.y

rtw88: pci: disable aspm for platform inter-op with module parameter

2020-08-21T11:07:34+00:00

[ Upstream commit 68aa716b7dd36f55e080da9e27bc594346334c41 ]

Some platforms cannot read the DBI register successfully for the
ASPM settings. After the read failed, the bus could be unstable,
and the device just became unavailable [1]. For those platforms,
the ASPM should be disabled. But as the ASPM can help the driver
to save the power consumption in power save mode, the ASPM is still
needed. So, add a module parameter for them to disable it, then
the device can still work, while others can benefit from the less
power consumption that brings by ASPM enabled.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=206411
[2] Note that my lenovo T430 is the same.

Fixes: 3dff7c6e3749 ("rtw88: allows to enable/disable HCI link PS mechanism")
Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200605074703.32726-1-yhchuang@realtek.com
Signed-off-by: Sasha Levin

rtw88: coex: only skip coex triggered by BT info

2020-08-19T06:24:05+00:00

[ Upstream commit 3f194bd4ca1cd9b8eef34d37d562279dbeb80319 ]

The coex mechanism used to skip upon the freeze flag is raised.
That will cause the coex mechanism being skipped unexpectedly.
Coex only wanted to keep the TDMA table from being changed by
BT side.

So, check the freeze and reason, if the coex reason is coming
from BT info, skip it, to make sure the coex triggered by Wifi
itself can work.

This is required for the AP mode, while the control flow is
different with STA mode. When starting an AP mode, the AP mode
needs to start working immedaitely after leaving IPS, and the
freeze flag could be raised. If the coex info is skipped, then
the AP mode will not set the antenna owner, leads to TX stuck.

Fixes: 4136214f7c46 ("rtw88: add BT co-existence support")
Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200717064937.27966-5-yhchuang@realtek.com
Signed-off-by: Sasha Levin

rtw88: fix short GI capability based on current bandwidth

2020-08-19T06:24:05+00:00

[ Upstream commit 4dd86b901d1373ef8446ecb50a7ca009f3475211 ]

Fix the transmission is not sent with short GI under
some conditions even if the receiver supports short GI.
If VHT capability IE exists in the beacon, the original
code uses the short GI for 80M field as driver's short GI
setting for transmission, even the current bandwidth is
not 80MHz.

Short GI supported fields for 20M/40M are informed in HT
capability information element, and short GI supported
field for 80M is informed in VHT capability information
element.

These three fields may be set to different values.
Driver needs to record each short GI support field for
each bandwidth, and send correct info depends on current
bandwidth to the WiFi firmware.

Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Tsang-Shian Lin 
Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200717064937.27966-3-yhchuang@realtek.com
Signed-off-by: Sasha Levin

rtw88: fix LDPC field for RA info

2020-08-19T06:24:05+00:00

[ Upstream commit ae44fa993e8e6c1a1d22e5ca03d9eadd53b2745b ]

Convert the type of LDPC field to boolen because
LDPC field of RA info H2C command to firmware
is only one bit.

Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver")
Signed-off-by: Tsang-Shian Lin 
Signed-off-by: Yan-Hsuan Chuang 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200717064937.27966-2-yhchuang@realtek.com
Signed-off-by: Sasha Levin

rtlwifi: Fix a double free in _rtl_usb_tx_urb_setup()

2020-06-22T07:32:45+00:00

[ Upstream commit beb12813bc75d4a23de43b85ad1c7cb28d27631e ]

Seven years ago we tried to fix a leak but actually introduced a double
free instead.  It was an understandable mistake because the code was a
bit confusing and the free was done in the wrong place.  The "skb"
pointer is freed in both _rtl_usb_tx_urb_setup() and _rtl_usb_transmit().
The free belongs _rtl_usb_transmit() instead of _rtl_usb_tx_urb_setup()
and I've cleaned the code up a bit to hopefully make it more clear.

Fixes: 36ef0b473fbf ("rtlwifi: usb: add missing freeing of skbuff")
Signed-off-by: Dan Carpenter 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200513093951.GD347693@mwanda
Signed-off-by: Sasha Levin

rtw88: fix an issue about leak system resources

2020-06-22T07:32:20+00:00

[ Upstream commit 191f6b08bfef24e1a9641eaac96ed030a7be4599 ]

the related system resources were not released when pci_iomap() return
error in the rtw_pci_io_mapping() function. add pci_release_regions() to
fix it.

Fixes: e3037485c68ec1a ("rtw88: new Realtek 802.11ac driver")
Cc: Andy Shevchenko 
Signed-off-by: Dejin Zheng 
Acked-by: Yan-Hsuan Chuang 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200504083442.3033-1-zhengdejin5@gmail.com
Signed-off-by: Sasha Levin

mac80211: populate debugfs only after cfg80211 init

2020-04-24T09:30:13+00:00

When fixing the initialization race, we neglected to account for
the fact that debugfs is initialized in wiphy_register(), and
some debugfs things went missing (or rather were rerooted to the
global debugfs root).

Fix this by adding debugfs entries only after wiphy_register().
This requires some changes in the rate control code since it
currently adds debugfs at alloc time, which can no longer be
done after the reordering.

Reported-by: Jouni Malinen 
Reported-by: kernel test robot 
Reported-by: Hauke Mehrtens 
Reported-by: Felix Fietkau 
Cc: stable@vger.kernel.org
Fixes: 52e04b4ce5d0 ("mac80211: fix race in ieee80211_register_hw()")
Signed-off-by: Johannes Berg 
Acked-by: Sumit Garg 
Link: https://lore.kernel.org/r/20200423111344.0e00d3346f12.Iadc76a03a55093d94391fc672e996a458702875d@changeid
Signed-off-by: Johannes Berg

rtw88: avoid unused function warnings

2020-04-14T12:45:36+00:00

The rtw88 driver defines emtpy functions with multiple indirections
but gets one of these wrong:

drivers/net/wireless/realtek/rtw88/pci.c:1347:12: error: 'rtw_pci_resume' defined but not used [-Werror=unused-function]
 1347 | static int rtw_pci_resume(struct device *dev)
      |            ^~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw88/pci.c:1342:12: error: 'rtw_pci_suspend' defined but not used [-Werror=unused-function]
 1342 | static int rtw_pci_suspend(struct device *dev)

Better simplify it to rely on the conditional reference in
SIMPLE_DEV_PM_OPS(), and mark the functions as __maybe_unused to avoid
warning about it.

I'm not sure if these are needed at all given that the functions
don't do anything, but they were only recently added.

Fixes: 44bc17f7f5b3 ("rtw88: support wowlan feature for 8822c")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200408185413.218643-1-arnd@arndb.de

Merge tag 'wireless-drivers-next-2020-03-27' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next

2020-03-27T22:40:24+00:00

Kalle Valo says:

====================
wireless-drivers-next patches for v5.7

Third set of patches for v5.7. Nothing really special this time,
business as usual.

When pulling this to net-next there's again a conflict in:

drivers/net/wireless/intel/iwlwifi/pcie/drv.c

To solve this drop these three lines from the conflict (the first hunk
from "HEAD") as the whole AX200 block was moved above in the same
file:

	IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name),
	IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name),
	IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name),

And keep all the __IWL_DEV_INFO() entries (the second hunk). In other
words, take everything from wireless-drivers-next. When running 'git
diff' after the resolution the output should be empty.

Major changes:

brcmfmac

* add USB autosuspend support

ath11k

* handle RX fragments

* enable PN offload

* add support for HE BSS color

iwlwifi

* support new FW API version

* support for EDCA measurements

* new scan API features

* enable new firmware debugging code
====================

Kalle gave me directions on how to resolve the iwlwifi conflict
as follows:

====================
When pulling this to net-next there's again a conflict in:

drivers/net/wireless/intel/iwlwifi/pcie/drv.c

To solve this drop these three lines from the conflict (the first hunk
from "HEAD") as the whole AX200 block was moved above in the same
file:

	IWL_DEV_INFO(0x2723, 0x1653, iwl_ax200_cfg_cc, iwl_ax200_killer_1650w_name),
	IWL_DEV_INFO(0x2723, 0x1654, iwl_ax200_cfg_cc, iwl_ax200_killer_1650x_name),
	IWL_DEV_INFO(0x2723, IWL_CFG_ANY, iwl_ax200_cfg_cc, iwl_ax200_name),

And keep all the __IWL_DEV_INFO() entries (the second hunk). In other
words, take everything from wireless-drivers-next. When running 'git
diff' after the resolution the output should be empty.
====================

Signed-off-by: David S. Miller

rtw88: fix non-increase management packet sequence number

2020-03-26T19:21:43+00:00

In previous setting, management packets' sequence numbers will
not increase and always stay at 0. Add hw sequence number support
for mgmt packets.
The table below shows different sequence number setting in the
tx descriptor.

seq num ctrl      | EN_HWSEQ | DISQSELSEL | HW_SSN_SEL
------------------------------------------------------
sw ctrl           |    0     |    N/A     |    N/A
hw ctrl per MACID |    1     |     0      |    N/A
hw ctrl per HWREG |    1     |     1      |HWREG(0/1/2/3)

Signed-off-by: Tzu-En Huang 
Signed-off-by: Yan-Hsuan Chuang 
Reviewed-by: Brian Norris 
Tested-by: Brian Norris 
Signed-off-by: Kalle Valo 
Link: https://lore.kernel.org/r/20200326020408.25218-1-yhchuang@realtek.com