- 14 Feb, 2020 19 commits
-
-
Felix Fietkau authored
Allows them to be used by a separately registered wiphy later Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Shayne Chen authored
Prevent the overwriting of max_tx_fragments if it has already been set in chip-specific init routine. Signed-off-by: Shayne Chen <shayne.chen@mediatek.com> Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
It is only used by the driver Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Will be used to determine the phy from within the driver Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Unlike the core phy, this will have extra allocated memory for a driver private struct. Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Will be used for per-phy driver private data Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Allow tracking clients of both wiphys separately Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Adds multiple wiphy support to mt76_get_txpower Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Nothing in the core uses it Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Nothing in the core uses it Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Allows keeping per-wiphy state separate Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Allows tracking tx scheduling separately per phy Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Add support for an extra wiphy in mt76_set_channel and mt76_get_survey This is preparation for supporting multiple wiphys per device to support the concurrent dual-band feature of MT7615D Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
This is preparation for supporting multiple wiphys per device to support the concurrent dual-band feature of MT7615D Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
This is preparation for supporting multiple wiphys per device to support the concurrent dual-band feature of MT7615D Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
This is preparation for supporting multiple wiphys per device to support the concurrent dual-band feature of MT7615D Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
This is preparation for supporting multiple wiphys per device to support the concurrent dual-band feature of MT7615D Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
This is preparation for supporting multiple wiphys per device to support the concurrent dual-band feature of MT7615D On the first wiphy, hw->priv will point to struct mt76_dev, which contains a struct mt76_phy at the start. For the secondary wiphy, hw->priv will point to a mt76_phy encapsulated in a driver specific struct To simplify access to struct mt76_phy members from drivers, the driver specific device struct is changed to add a union of struct mt76_dev and struct mt76_phy as the first element Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
Felix Fietkau authored
Reduces duplication and prepares for further rework Signed-off-by: Felix Fietkau <nbd@nbd.name>
-
- 13 Feb, 2020 1 commit
-
-
Tzu-En Huang authored
In associating and configuring beamformee, bfee->role is not correctly set before rtw_chip_ops::config_bfee(). Fix it by setting it correctly. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
- 12 Feb, 2020 20 commits
-
-
Joe Perches authored
Reduce the data size 2kb or 3kb by making tables const. Add const to pointer declarations to make compilation work too. (x86-64 defconfig) $ size drivers/net/wireless/realtek/rtw88/rtw8822?.o* text data bss dec hex filename 25054 672 8 25734 6486 drivers/net/wireless/realtek/rtw88/rtw8822b.o.new 23870 1872 8 25750 6496 drivers/net/wireless/realtek/rtw88/rtw8822b.o.old 53646 828 0 54474 d4ca drivers/net/wireless/realtek/rtw88/rtw8822c.o.new 52846 1652 0 54498 d4e2 drivers/net/wireless/realtek/rtw88/rtw8822c.o.old (x86-64 allyesconfig) $ size drivers/net/wireless/realtek/rtw88/rtw8822?.o* text data bss dec hex filename 45811 6280 128 52219 cbfb drivers/net/wireless/realtek/rtw88/rtw8822b.o.new 44211 7880 128 52219 cbfb drivers/net/wireless/realtek/rtw88/rtw8822b.o.old 100195 8128 0 108323 1a723 drivers/net/wireless/realtek/rtw88/rtw8822c.o.new 98947 9376 0 108323 1a723 drivers/net/wireless/realtek/rtw88/rtw8822c.o.old Signed-off-by: Joe Perches <joe@perches.com> Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
Some tests shows that using AMSDU to aggregate TCP ACKs to specific APs will degrade the throughput on 2.4G band in 20MHz bandwidth (< 10 Mbps, should be ~100 Mbps for 2x2). Also found that there's barely no negative impact if we disable TX AMSDU on 2.4G to connect to other APs. So it seems like we can just tell mac80211 to not to aggregate MSDUs when transmitting on 2.4G band. Note that we still can TX AMSDU on 5G band and benefit from it by having 50 ~ 70 Mbps throughput improvement. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Chien-Hsun Liao authored
According to some experiments, the original RF register protection setting of 8822c cannot perfectly make sure that there is no hardware PI write (direct) during direct write. Modify the setting so that the hardware block of PI would be turned off via rtw8822c_rstb_3wire() during the direct write, to avoid RF register racing. Note that 8822b uses SIPI write (indirect), so 8822b does not have such problem. Signed-off-by: Chien-Hsun Liao <ben.liao@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ping-Ke Shih authored
The hardware value of secondary channel offset isn't very intuitive. This commit adds enumeration, so we can easier to check the logic with the suffix of enumeration name, likes _UPPER or _LOWER. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Dan Carpenter authored
sk_buff structs need to be freed with kfree_skb(), not kfree(). Fixes: b6c12908 ("rtw88: Add wowlan net-detect support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Martin Kepplinger authored
Appearently the hw pointer can be NULL while the module is loaded and in that case rsi_shutdown() crashes due to the unconditional dereference. Signed-off-by: Martin Kepplinger <martin.kepplinger@puri.sm> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Tzu-En Huang authored
Fix switching xtal mode leads to BT USB error issue. Signed-off-by: Tzu-En Huang <tehuang@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ping-Ke Shih authored
Though hardware isn't implement CCMP-256, GCMP and GCMP-256, it's possible to fallback to use software de-/en-cryption implemented by mac80211. Without adding these chipers, kernel log will show something if we connect to a WPA3 enterprise AP, likes wlan0: failed to set key (1, ff:ff:ff:ff:ff:ff) to hardware (-524) Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
Driver could possibly be dead-locked while canceling works with *_sync() with mutex lock held. Those cancel_delayed_work_sync() functions will wait until the work is done, but if we hold the lock, they will never acquire the lock. To prevent this, simply release the lock and acquire again after the works have been canceled. And to avoid the works being queued again, check if the device is at RTW_FLAG_RUNNING state, otherwise just return and do nothing. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Ping-Ke Shih authored
When driver is coming up, mac80211 will set changed as ~0 (0xffffffff), and driver could enter IDLE state (power off) before switching channel or other config event. So move rtw_enter_ips() to the last, to make sure the driver completed the config events before going to IDLE state. So, moves leave/enter IPS config to be first/last one according to flag IEEE80211_CONF_IDLE. If there're more configureations we want to add in the future, they must locate between leave/enter IPS. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
Since RTL8822CE has enabled reference clock auto calibration, there is no need to add any clock delay for covering the timing gap of the reference clock. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
Both are missing but could be used sometimes. Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Yan-Hsuan Chuang authored
vif is not used, remove it Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com> Reviewed-by: Chris Chiu <chiu@endlessm.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Guenter Roeck authored
With commit 216b4400 ("brcmfmac: Fix use after free in brcmf_sdio_readframes()") applied, we see locking timeouts in brcmf_sdio_watchdog_thread(). brcmfmac: brcmf_escan_timeout: timer expired INFO: task brcmf_wdog/mmc1:621 blocked for more than 120 seconds. Not tainted 4.19.94-07984-g24ff99a0f713 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. brcmf_wdog/mmc1 D 0 621 2 0x00000000 last_sleep: 2440793077. last_runnable: 2440766827 [<c0aa1e60>] (__schedule) from [<c0aa2100>] (schedule+0x98/0xc4) [<c0aa2100>] (schedule) from [<c0853830>] (__mmc_claim_host+0x154/0x274) [<c0853830>] (__mmc_claim_host) from [<bf10c5b8>] (brcmf_sdio_watchdog_thread+0x1b0/0x1f8 [brcmfmac]) [<bf10c5b8>] (brcmf_sdio_watchdog_thread [brcmfmac]) from [<c02570b8>] (kthread+0x178/0x180) In addition to restarting or exiting the loop, it is also necessary to abort the command and to release the host. Fixes: 216b4400 ("brcmfmac: Fix use after free in brcmf_sdio_readframes()") Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: franky.lin@broadcom.com Acked-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Sergey Matyukevich authored
Fix potential Spectre vulnerabilities and other warnings reported by smatch: drivers/net/wireless/quantenna/qtnfmac/core.c:49 qtnf_core_get_mac() warn: potential spectre issue 'bus->mac' [r] (local cap) drivers/net/wireless/quantenna/qtnfmac/core.c:51 qtnf_core_get_mac() warn: possible spectre second half. 'mac' drivers/net/wireless/quantenna/qtnfmac/event.c:671 qtnf_event_parse() warn: potential spectre issue 'mac->iflist' [r] (local cap) drivers/net/wireless/quantenna/qtnfmac/pcie/pearl_pcie.c:912 qtnf_pcie_skb_send() warn: variable dereferenced before check 'skb' (see line 881) Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
Most part of scan command data is always present, so no need to keep it in TLV. Simplify scan command processing moving most part of its parameters into a fixed part of qlink_cmd_scan message. Use fixed dwell time values for normal scan when device is not connected, and allow wireless card decide on dwell times by itself if it's operating as a STA and is connected. When connected, card can select dwell times dynamically based on traffic conditions to get best results. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
With an addition of 6GHz band support, channel number can no longer be used to uniquely identify a specific channel. Modify channel switch command to use chandef data. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
Make sure that all elements in QLINK protocol message are aligned to 4 bytes. For this purpose add necessary amount of padding bytes to each message. Besides, add padding for non-aligned variable length fields, e.g. SSID, so that the first byte of the next variable length element is aligned. to 4 bytes. Finally, introduce TLV parsing helpers to reduce boilerplate TLV parsing code. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
Each radio on a given wifi device may have different max scan SSIDs limitation, so take this information from a per-radio info structure. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Igor Mitsyanko authored
Switch to extendable implementation of channel survey dump to make sure that any new channel statistics can be added in the future without any backwards compatibility issues. For this purpose use a separate variable length bitmap to pass the list of valid statistics in firmware response. Besides, switch to using channel frequency instead of IEEE channel number to prepare for adding support of 6GHz band. Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-