summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtlwifi
AgeCommit message (Collapse)Author
2024-11-13Merge tag 'wireless-next-2024-11-13' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.13 Most likely the last -next pull request for v6.13. Most changes are in Realtek and Qualcomm drivers, otherwise not really anything noteworthy. Major changes: mac80211 * EHT 1024 aggregation size for transmissions ath12k * switch to using wiphy_lock() and remove ar->conf_mutex * firmware coredump collection support * add debugfs support for a multitude of statistics ath11k * dt: document WCN6855 hardware inputs ath9k * remove include/linux/ath9k_platform.h ath5k * Arcadyan ARV45XX AR2417 & Gigaset SX76[23] AR241[34]A support rtw88: * 8821au and 8812au USB adapters support rtw89 * thermal protection * firmware secure boot for WiFi 6 chip * tag 'wireless-next-2024-11-13' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (154 commits) Revert "wifi: iwlegacy: do not skip frames with bad FCS" wifi: mac80211: pass MBSSID config by reference wifi: mac80211: Support EHT 1024 aggregation size in TX net: rfkill: gpio: Add check for clk_enable() wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw() wifi: Switch back to struct platform_driver::remove() wifi: ipw2x00: libipw_rx_any(): fix bad alignment wifi: brcmfmac: release 'root' node in all execution paths wifi: iwlwifi: mvm: don't call power_update_mac in fast suspend wifi: iwlwifi: s/IWL_MVM_INVALID_STA/IWL_INVALID_STA wifi: iwlwifi: bump minimum API version in BZ/SC to 92 wifi: iwlwifi: move IWL_LMAC_*_INDEX to fw/api/context.h wifi: iwlwifi: be less noisy if the NIC is dead in S3 wifi: iwlwifi: mvm: tell iwlmei when we finished suspending wifi: iwlwifi: allow fast resume on ax200 wifi: iwlwifi: mvm: support new initiator and responder command version wifi: iwlwifi: mvm: use wiphy locked debugfs for low-latency wifi: iwlwifi: mvm: MLO scan upon channel condition degradation wifi: iwlwifi: mvm: support new versions of the wowlan APIs wifi: iwlwifi: mvm: allow always calling iwl_mvm_get_bss_vif() ... ==================== Link: https://patch.msgid.link/20241113172918.A8A11C4CEC3@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-11-06wifi: rtlwifi: Remove some exhalbtc deadcodeDr. David Alan Gilbert
exhalbtc_rf_status_notify(), exhalbtc_coex_dm_switch() and exhalbtc_antenna_detection() are unused since they were added in 2017's commit 7937f02d1953 ("rtlwifi: btcoex: hook external functions for newer chips") Remove them. This leaves ex_btc8723b1ant_coex_dm_reset() unused. Remove it. exhalbtc_dbg_control(), exhalbtc_stack_update_profile_info(), exhalbtc_set_hci_version(), and exhalbtc_set_bt_patch_version() are unused since their addition in 2014 by commit aa45a673b291 ("rtlwifi: btcoexist: Add new mini driver") Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241104144331.29262-1-linux@treblig.org
2024-11-06wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failuresGuilherme G. Piccoli
Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? usb_alloc_urb+0x95/0xa4 usb_control_msg+0xff/0x184 _usbctrl_vendorreq_sync+0xa0/0x161 _usb_read_sync+0xb3/0xc5 read_efuse_byte+0x13c/0x146 read_efuse+0x351/0x5f0 efuse_read_all_map+0x42/0x52 rtl_efuse_shadow_map_update+0x60/0xef rtl_get_hwinfo+0x5d/0x1c2 rtl92cu_read_eeprom_info+0x10a/0x8d5 ? rtl92c_read_chip_version+0x14f/0x17e rtl_usb_probe+0x323/0x851 usb_probe_interface+0x278/0x34b really_probe+0x202/0x4a4 __driver_probe_device+0x166/0x1b2 driver_probe_device+0x2f/0xd8 [...] We propose hereby to drastically reduce the attempts of doing the I/O reads in case of failures, restricted to USB devices (given that they're inherently slower than PCIe ones). By retrying up to 10 times (instead of 10000), we got reponsiveness in the reproducer, while seems reasonable to believe that there's no sane USB device implementation in the field requiring this amount of retries at every I/O read in order to properly work. Based on that assumption, it'd be good to have it backported to stable but maybe not since driver implementation (the 10k number comes from day 0), perhaps up to 6.x series makes sense. [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race") [1] A note about that: this syzkaller report presents multiple reproducers that differs by the type of emulated USB device. For this specific case, check the entry from 2024/08/08 06:23 in the list of crashes; the C repro is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000. Cc: stable@vger.kernel.org # v6.1+ Reported-by: syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com
2024-10-31Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.12-rc6). Conflicts: drivers/net/wireless/intel/iwlwifi/mvm/mld-mac80211.c cbe84e9ad5e2 ("wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd") 188a1bf89432 ("wifi: mac80211: re-order assigning channel in activate links") https://lore.kernel.org/all/20241028123621.7bbb131b@canb.auug.org.au/ net/mac80211/cfg.c c4382d5ca1af ("wifi: mac80211: update the right link for tx power") 8dd0498983ee ("wifi: mac80211: Fix setting txpower with emulate_chanctx") drivers/net/ethernet/intel/ice/ice_ptp_hw.h 6e58c3310622 ("ice: fix crash on probe for DPLL enabled E810 LOM") e4291b64e118 ("ice: Align E810T GPIO to other products") ebb2693f8fbd ("ice: Read SDP section from NVM for pin definitions") ac532f4f4251 ("ice: Cleanup unused declarations") https://lore.kernel.org/all/20241030120524.1ee1af18@canb.auug.org.au/ No adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-25wifi: rtlwifi: use MODULE_FIRMWARE() to declare used firmwarePing-Ke Shih
Some used firmware are missing to be added to MODULE_FIRMWARE(). Add them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20241018055651.21166-1-pkshih@realtek.com
2024-10-17wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171Bitterblue Smith
This ID appears to be RTL8188SU, not RTL8192DU. This is the wrong driver for RTL8188SU. The r8712u driver from staging handles this ID. I think this ID comes from the original rtl8192du driver from Realtek. I don't know if they added it by mistake, or it was actually used for two different chips. RTL8188SU with this ID exists in the wild. RTL8192DU with this ID probably doesn't. Fixes: b5dc8873b6ff ("wifi: rtlwifi: Add rtl8192du/sw.c") Cc: stable@vger.kernel.org # v6.11 Closes: https://github.com/lwfinger/rtl8192du/issues/105 Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/40245564-41fe-4a5e-881f-cd517255b20a@gmail.com
2024-09-20wifi: rtlwifi: make read-only arrays static constColin Ian King
Don't populate the read-only arrays params, toshiba_smid1, toshiba_smid2, samsung_smid and lenovo_smid on the stack at run time, instead make them static const. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240912135335.590464-1-colin.i.king@gmail.com
2024-08-07wifi: rtlwifi: rtl8192du: Initialise value32 in ↵Bitterblue Smith
_rtl92du_init_queue_reserved_page GCC complains: In file included from include/linux/ieee80211.h:21, from include/net/mac80211.h:20, from drivers/net/wireless/realtek/rtlwifi/rtl8192du/../wifi.h:14, from drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:4: In function 'u32p_replace_bits', inlined from '_rtl92du_init_queue_reserved_page.isra' at drivers/net/wireless/realtek/rtlwifi/rtl8192du/hw.c:225:2: >> include/linux/bitfield.h:189:18: warning: 'value32' is used uninitialized [-Wuninitialized] Part of the variable is indeed left uninitialised. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202408062100.DWhN0CYH-lkp@intel.com/ Fixes: e769c67105d3 ("wifi: rtlwifi: Add rtl8192du/hw.{c,h}") Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://patch.msgid.link/2a808244-93d0-492c-b304-ae1974df5df9@gmail.com
2024-07-09Merge tag 'rtw-next-2024-07-05' of https://github.com/pkshih/rtwKalle Valo
rtw-next patches for v6.11 Some cleanups of rtl8xxxu and rtlwifi, and some fixes of rtw88. The major change is to develop WoWLAN and preparation of RTL8852BE-VT listed below: rtw89: - preparation of RTL8852BE-VT * add RF calibration code * move shared code with RTL8852BE to common module - add WoWLAN for WiFi 6 chips - support 36-bit PCI DMA
2024-07-05wifi: rtlwifi: fix default typoFredrik Lönnegren
Change 'defult' to 'default' in comments in several rtlwifi drivers. Signed-off-by: Fredrik Lönnegren <fredrik@frelon.se> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240703070627.135328-1-fredrik@frelon.se
2024-06-26wifi: mac80211: inform the low level if drv_stop() is a suspendEmmanuel Grumbach
This will allow the low level driver to take different actions for different flows. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240618192529.739036208b6e.Ie18a2fe8e02bf2717549d39420b350cfdaf3d317@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-06-10Merge tag 'wireless-next-2024-06-07' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.11 The first "new features" pull request for v6.11 with changes both in stack and in drivers. Nothing out of ordinary, except that we have two conflicts this time: net/mac80211/cfg.c https://lore.kernel.org/all/20240531124415.05b25e7a@canb.auug.org.au drivers/net/wireless/microchip/wilc1000/netdev.c https://lore.kernel.org/all/20240603110023.23572803@canb.auug.org.au Major changes: cfg80211/mac80211 * parse Transmit Power Envelope (TPE) data in mac80211 instead of in drivers wilc1000 * read MAC address during probe to make it visible to user space iwlwifi * bump FW API to 91 for BZ/SC devices * report 64-bit radiotap timestamp * enable P2P low latency by default * handle Transmit Power Envelope (TPE) advertised by AP * start using guard() rtlwifi * RTL8192DU support ath12k * remove unsupported tx monitor handling * channel 2 in 6 GHz band support * Spatial Multiplexing Power Save (SMPS) in 6 GHz band support * multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA) support * dynamic VLAN support * add panic handler for resetting the firmware state ath10k * add qcom,no-msa-ready-indicator Device Tree property * LED support for various chipsets * tag 'wireless-next-2024-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (194 commits) wifi: ath12k: add hw_link_id in ath12k_pdev wifi: ath12k: add panic handler wifi: rtw89: chan: Use swap() in rtw89_swap_sub_entity() wifi: brcm80211: remove unused structs wifi: brcm80211: use sizeof(*pointer) instead of sizeof(type) wifi: ath12k: do not process consecutive RDDM event dt-bindings: net: wireless: ath11k: Drop "qcom,ipq8074-wcss-pil" from example wifi: ath12k: fix memory leak in ath12k_dp_rx_peer_frag_setup() wifi: rtlwifi: handle return value of usb init TX/RX wifi: rtlwifi: Enable the new rtl8192du driver wifi: rtlwifi: Add rtl8192du/sw.c wifi: rtlwifi: Constify rtl_hal_cfg.{ops,usb_interface_cfg} and rtl_priv.cfg wifi: rtlwifi: Add rtl8192du/dm.{c,h} wifi: rtlwifi: Add rtl8192du/fw.{c,h} and rtl8192du/led.{c,h} wifi: rtlwifi: Add rtl8192du/rf.{c,h} wifi: rtlwifi: Add rtl8192du/trx.{c,h} wifi: rtlwifi: Add rtl8192du/phy.{c,h} wifi: rtlwifi: Add rtl8192du/hw.{c,h} wifi: rtlwifi: Add new members to struct rtl_priv for RTL8192DU wifi: rtlwifi: Add rtl8192du/table.{c,h} ... Signed-off-by: Jakub Kicinski <kuba@kernel.org> ==================== Link: https://lore.kernel.org/r/20240607093517.41394C2BBFC@smtp.kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-06-01wifi: rtlwifi: Ignore IEEE80211_CONF_CHANGE_RETRY_LIMITSBitterblue Smith
Since commit 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers") ieee80211_hw_config() is no longer called with changed = ~0. rtlwifi relied on ~0 in order to ignore the default retry limits of 4/7, preferring 48/48 in station mode and 7/7 in AP/IBSS. RTL8192DU has a lot of packet loss with the default limits from mac80211. Fix it by ignoring IEEE80211_CONF_CHANGE_RETRY_LIMITS completely, because it's the simplest solution. Link: https://lore.kernel.org/linux-wireless/cedd13d7691f4692b2a2fa5a24d44a22@realtek.com/ Cc: stable@vger.kernel.org # 6.9.x Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/1fabb8e4-adf3-47ae-8462-8aea963bc2a5@gmail.com
2024-05-30wifi: rtlwifi: handle return value of usb init TX/RXPing-Ke Shih
Handle error code to cause failed to USB probe result from unexpected USB EP number, otherwise when USB disconnect skb_dequeue() an uninitialized skb list and cause warnings below. usb 2-1: USB disconnect, device number 76 INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 54060 Comm: kworker/0:1 Not tainted 6.9.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:114 assign_lock_key kernel/locking/lockdep.c:976 [inline] register_lock_class+0xc18/0xfa0 kernel/locking/lockdep.c:1289 __lock_acquire+0x108/0x3bc0 kernel/locking/lockdep.c:5014 lock_acquire kernel/locking/lockdep.c:5754 [inline] lock_acquire+0x1b0/0x550 kernel/locking/lockdep.c:5719 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3d/0x60 kernel/locking/spinlock.c:162 skb_dequeue+0x20/0x180 net/core/skbuff.c:3846 rtl_usb_cleanup drivers/net/wireless/realtek/rtlwifi/usb.c:706 [inline] rtl_usb_deinit drivers/net/wireless/realtek/rtlwifi/usb.c:721 [inline] rtl_usb_disconnect+0x4a4/0x850 drivers/net/wireless/realtek/rtlwifi/usb.c:1051 usb_unbind_interface+0x1e8/0x980 drivers/usb/core/driver.c:461 device_remove drivers/base/dd.c:568 [inline] device_remove+0x122/0x170 drivers/base/dd.c:560 __device_release_driver drivers/base/dd.c:1270 [inline] device_release_driver_internal+0x443/0x620 drivers/base/dd.c:1293 bus_remove_device+0x22f/0x420 drivers/base/bus.c:574 device_del+0x395/0x9f0 drivers/base/core.c:3909 usb_disable_device+0x360/0x7b0 drivers/usb/core/message.c:1418 usb_disconnect+0x2db/0x930 drivers/usb/core/hub.c:2305 hub_port_connect drivers/usb/core/hub.c:5362 [inline] hub_port_connect_change drivers/usb/core/hub.c:5662 [inline] port_event drivers/usb/core/hub.c:5822 [inline] hub_event+0x1e39/0x4ce0 drivers/usb/core/hub.c:5904 process_one_work+0x97b/0x1a90 kernel/workqueue.c:3267 process_scheduled_works kernel/workqueue.c:3348 [inline] worker_thread+0x680/0xf00 kernel/workqueue.c:3429 kthread+0x2c7/0x3b0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Reported-by: Shichao Lai <shichaorai@gmail.com> Closes: https://lore.kernel.org/linux-wireless/CAEk6kZuuezkH1dVRJf3EAVZK-83=OpTz62qCugkpTkswj8JF6w@mail.gmail.com/T/#u Tested-by: Shichao Lai <shichaorai@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240524003248.5952-1-pkshih@realtek.com
2024-05-30wifi: rtlwifi: Enable the new rtl8192du driverBitterblue Smith
The RTL8192DU is an older Wifi 4 dual band chip. It comes in two flavours: single MAC single PHY (like most Realtek Wifi 4 USB devices), and dual MAC dual PHY. The single MAC single PHY version is 2T2R and can work either in the 2.4 GHz band or the 5 GHz band. The dual MAC dual PHY version has two USB interfaces and appears to the system as two separate 1T1R Wifi devices, one working in the 2.4 GHz band, the other in the 5 GHz band. This was tested only with a single MAC single PHY device, mostly in station mode. The speeds in the 2.4 GHz band with 20 MHz channel width are similar to the out-of-tree driver: 85/51 megabits/second. Stefan Lippers-Hollmann tested the speed in the 5 GHz band with 40 MHz channel width: 173/99 megabits/second. It was also tested briefly in AP mode. It's emitting beacons and my phone can connect to it. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/5f2da7ee-876a-42fc-8fec-ec5386fa8c26@gmail.com
2024-05-30wifi: rtlwifi: Add rtl8192du/sw.cBitterblue Smith
This contains the new module's entry point. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/1fdc83ac-4a6f-4645-8837-6e38683b6c84@gmail.com
2024-05-30wifi: rtlwifi: Constify rtl_hal_cfg.{ops,usb_interface_cfg} and rtl_priv.cfgBitterblue Smith
This allows the drivers to declare the structs rtl_hal_cfg, rtl_hal_ops, and rtl_hal_usbint_cfg as const. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/1b29994f-3d07-4297-875d-57c3a87a1ec6@gmail.com
2024-05-30wifi: rtlwifi: Add rtl8192du/dm.{c,h}Bitterblue Smith
These contain functions related to the dynamic mechanism, which runs every two seconds to adjust to changes in the environment. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/a010ed6d-efb0-456d-bd4a-dfc6da23e7aa@gmail.com
2024-05-30wifi: rtlwifi: Add rtl8192du/fw.{c,h} and rtl8192du/led.{c,h}Bitterblue Smith
fw.c contains a function for loading the firmware. led.c contains a function for controlling the LED. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/a52b8907-267c-4811-90ca-5eb852a2aa09@gmail.com
2024-05-30wifi: rtlwifi: Add rtl8192du/rf.{c,h}Bitterblue Smith
These contain one RF configuration function and some functions related to dual MAC operation. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/36258d72-11fd-4f70-84c6-782972f706ed@gmail.com
2024-05-30wifi: rtlwifi: Add rtl8192du/trx.{c,h}Bitterblue Smith
These contain routines related to sending frames to the chip. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/bd2c24a0-a1fe-493a-8079-d83fda81a0d5@gmail.com
2024-05-30wifi: rtlwifi: Add rtl8192du/phy.{c,h}Bitterblue Smith
These contain mostly the calibration and channel switching routines for RTL8192DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/299a5ab7-46bf-410b-bbeb-e252eeeeb34c@gmail.com
2024-05-30wifi: rtlwifi: Add rtl8192du/hw.{c,h}Bitterblue Smith
These contain mostly hardware init/deinit routines for RTL8192DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/282afe18-f37d-45f7-9275-68c39d1fde09@gmail.com
2024-05-30wifi: rtlwifi: Add new members to struct rtl_priv for RTL8192DUBitterblue Smith
These are needed for the dual MAC version of RTL8192DU. The two mutexes are used to avoid concurrent access to the hardware from the two USB interfaces. The two arrays are filled by one interface during LC calibration and accessed by the other interface during channel switching. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/d1bf581b-de41-4d09-bf56-768c2fc29dd3@gmail.com
2024-05-30wifi: rtlwifi: Add rtl8192du/table.{c,h}Bitterblue Smith
These contain the MAC, BB, RF, and AGC initialisation tables for RTL8192DU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/5ea548b9-5ec6-4358-aa5d-94071f2341cb@gmail.com
2024-05-30wifi: rtlwifi: rtl8192d: Use "rtl92d" prefixBitterblue Smith
Some functions moved from rtl8192de still use the "rtl92de" prefix. Rename them. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/abe3624d-f986-4a24-966c-67defa962e3f@gmail.com
2024-05-04wifi: rtlwifi: 8192d: initialize rate_mask in rtl92de_update_hal_rate_mask()Ping-Ke Shih
le32p_replace_bits() only updates partial bits of rate_mask, and GCC warns below. Set initial value to avoid warnings, and prevent random value of missed bits (bit 6 of rate_mask.macid_and_short_gi). In file included from ./include/linux/fortify-string.h:5, from ./include/linux/string.h:369, from ./include/linux/bitmap.h:13, from ./include/linux/cpumask.h:13, from ./include/linux/sched.h:16, from drivers/net/wireless/realtek/rtlwifi/rtl8192d/../wifi.h:9, from drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c:4: In function 'le32p_replace_bits', inlined from 'rtl92de_update_hal_rate_mask.isra' at drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c:986:2: ./include/linux/bitfield.h:189:15: warning: 'rate_mask' is used uninitialized [-Wuninitialized] 189 | *p = (*p & ~to(field)) | type##_encode_bits(val, field); \ | ^~ ./include/linux/bitfield.h:196:9: note: in expansion of macro '____MAKE_OP' 196 | ____MAKE_OP(le##size,u##size,cpu_to_le##size,le##size##_to_cpu) \ | ^~~~~~~~~~~ ./include/linux/bitfield.h:201:1: note: in expansion of macro '__MAKE_OP' 201 | __MAKE_OP(32) | ^~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c: In function 'rtl92de_update_hal_rate_mask.isra': drivers/net/wireless/realtek/rtlwifi/rtl8192d/hw_common.c:863:37: note: 'rate_mask' declared here 863 | struct rtl92d_rate_mask_h2c rate_mask; | ^~~~~~~~~ Compile tested only. Fixes: 014bba73b525 ("wifi: rtlwifi: Adjust rtl8192d-common for USB") Cc: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240504111916.31445-1-pkshih@realtek.com
2024-05-04wifi: rtlwifi: Remove unused structs and avoid multiple -Wfamnae warningsGustavo A. R. Silva
Wflex-array-member-not-at-end is coming in GCC-14, and we are getting ready to enable it globally. So, remove unused structs and fix the following -Wflex-array-member-not-at-end warnings: drivers/net/wireless/realtek/rtlwifi/btcoexist/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8188ee/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192c/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192ce/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192cu/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192de/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192ee/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8192se/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8723ae/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8723be/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8723com/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/rtl8821ae/../wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] drivers/net/wireless/realtek/rtlwifi/wifi.h:1063:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/ZjLFIa31BGPVCGh1@neat
2024-05-02wifi: rtlwifi: Adjust rtl8192d-common for USBBitterblue Smith
A few of the shared functions need small changes for the USB driver: - firmware loading - efuse reading - rate mask updating - rf register reading - initial gain for scanning Also, add a few macros to wifi.h and initialise rtlhal.interfaceindex for USB devices. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/28100330-f421-4b85-b41b-f1045380cef2@gmail.com
2024-05-02wifi: rtlwifi: Clean up rtl8192d-common a bitBitterblue Smith
Improve readability: * add empty lines * use abs_diff in rtl92d_dm_txpower_tracking_callback_thermalmeter * roll up repeated statements into a for loop in rtl92d_dm_txpower_tracking_callback_thermalmeter * shorten lines by replacing many instances of "rtlpriv->dm" with "dm" pointer in rtl92d_dm_txpower_tracking_callback_thermalmeter * sort some declarations by length * refactor _rtl92d_get_txpower_writeval_by_regulatory a little * refactor _rtl92de_readpowervalue_fromprom a little Delete unused structs tag_dynamic_init_gain_operation_type_definition and swat. Simplify rtl92d_fill_h2c_cmd a little and delete a pointless wrapper function. Tested with a single MAC single PHY USB dongle from Aliexpress labelled "CC&C WL-6210-V3". Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/f6acfa78-2f4e-47f1-95d4-65aa77510113@gmail.com
2024-05-02wifi: rtlwifi: Move code from rtl8192de to rtl8192d-commonBitterblue Smith
Create the new module rtl8192d-common and move some code into it from rtl8192de. Now the rtl8192de driver (PCI) and the new rtl8192du driver (USB) can share some of the code. This is mostly the code that required little effort to make it shareable. There are a few more functions which they could share, with more changes. Add phy_iq_calibrate member to struct rtl_hal_ops to allow moving the TX power tracking code from dm.c. The other changes in this patch are adjusting whitespace, renaming some functions, making some arrays const, and making checkpatch.pl less unhappy. rtl8192de is compile-tested only. rtl8192d-common is tested with the new rtl8192du driver. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/69c4358a-6fbf-4433-92a6-341c83e9dd48@gmail.com
2024-05-02wifi: rtlwifi: rtl8192de: Fix endianness issue in RX pathBitterblue Smith
Structs rx_desc_92d and rx_fwinfo_92d will not work for big endian systems. Delete rx_desc_92d because it's big and barely used, and instead use the get_rx_desc_rxmcs and get_rx_desc_rxht functions, which work on big endian systems too. Fix rx_fwinfo_92d by duplicating four of its members in the correct order. Tested only with RTL8192DU, which will use the same code. Tested only on a little endian system. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/698463da-5ef1-40c7-b744-fa51ad847caf@gmail.com
2024-05-02wifi: rtlwifi: rtl8192de: Fix low speed with WPA3-SAEBitterblue Smith
Some (all?) management frames are incorrectly reported to mac80211 as decrypted when actually the hardware did not decrypt them. This results in speeds 3-5 times lower than expected, 20-30 Mbps instead of 100 Mbps. Fix this by checking the encryption type field of the RX descriptor. rtw88 does the same thing. This fix was tested only with rtl8192du, which will use the same code. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/4d600435-f0ea-46b0-bdb4-e60f173da8dd@gmail.com
2024-05-02wifi: rtlwifi: rtl8192de: Fix 5 GHz TX powerBitterblue Smith
Different channels have different TX power settings. rtl8192de is using the TX power setting from the wrong channel in the 5 GHz band because _rtl92c_phy_get_rightchnlplace expects an array which includes all the channel numbers, but it's using an array which includes only the 5 GHz channel numbers. Use the array channel_all (defined in rtl8192de/phy.c) instead of the incorrect channel5g (defined in core.c). Tested only with rtl8192du, which will use the same TX power code. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/c7653517-cf88-4f57-b79a-8edb0a8b32f0@gmail.com
2024-04-29wifi: rtlwifi: rtl8723be: Make read-only arrays static constColin Ian King
Don't populate the read-only arrays cck_rates, ofdm_rates, ht_rates_1t and channel_all on the stack at run time, instead make them static const and clean up the formatting. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240425155733.114423-1-colin.i.king@gmail.com
2024-03-22wifi: rtlwifi: always assume QoS mode in rtl8192cuDmitry Antipov
In 'rtl92cu_set_hw_reg()', always assume that QoS mode is enabled as it was hardcoded since an initial commit. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240320084324.109506-2-dmantipov@yandex.ru
2024-03-22wifi: rtlwifi: drop WMM stubs from rtl8192cuDmitry Antipov
Since WMM support was never actually implemented and related TODO is more than 13 years old, it might be reasonable to remove all of the WMM stubs from rtl8192cu and simplify related code. Minor comment style adjustments suggested by checkpatch.pl, compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240320084324.109506-1-dmantipov@yandex.ru
2024-03-05wifi: rtlwifi: Remove rtl_intf_ops.read_efuse_byteBitterblue Smith
PCI drivers and USB drivers can both use the same function, read_efuse_byte(), and they can call it directly. rtl8192de was the only user. Tested only with the upcoming rtl8192du driver. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/4e2c968d-f25c-4a40-be97-4fdcbdde69cf@gmail.com
2024-02-21wifi: rtlwifi: set initial values for unexpected cases of USB endpoint priorityPing-Ke Shih
Map USB endpoints to hardware and AC queues according to number of USB endpoints. However, original only give a warning for unexpected cases but initial values are not given. Then, smatch warns: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:642 _rtl92cu_init_chipn_two_out_ep_priority() error: uninitialized symbol 'valuelow'. drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:644 _rtl92cu_init_chipn_two_out_ep_priority() error: uninitialized symbol 'valuehi'. drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:649 _rtl92cu_init_chipn_two_out_ep_priority() error: uninitialized symbol 'valuehi'. drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:650 _rtl92cu_init_chipn_two_out_ep_priority() error: uninitialized symbol 'valuelow'. The regular selection is high and low queues, so move default (unexpected) case along with that. Compile tested only. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240216033949.34765-1-pkshih@realtek.com
2024-02-21wifi: rtlwifi: rtl8192cu: Fix TX aggregationBitterblue Smith
rtl8192cu is checking rtl_mac.tids when deciding if it should enable aggregation. This is wrong because rtl_mac.tids is not initialised anywhere. Check rtl_sta_info.tids instead, which is initialised. Also, when enabling aggregation also enable RTS. The vendor driver does this, my router does this. It seems like the thing to do. Also also, it seems right to set the AMPDU density only when enabling aggregation. Also also also, delete the unused member rtl_mac.tids and the unused macros RTL_AGG_ON and RTL_AGG_OFF. Naturally, with working AMPDU the download/upload speeds are better. Before: 59/32 Mbps. After: 68/46 Mbps. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/4e936334-5f81-403f-a495-0628ebfb6903@gmail.com
2024-02-15wifi: rtlwifi: rtl_usb: Store the endpoint addressesBitterblue Smith
And use the stored addresses in rtl8192cu instead of hardcoding them. This is what the vendor drivers do. Perhaps this is not strictly necessary for RTL8192CU devices. However, the dual mac version of RTL8192DU has two USB interfaces, each with its own set of endpoints. Hardcoding their addresses in the upcoming rtl8192du driver would require making some assumptions which I'm not qualified to make. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/7b6a602a-6101-4bab-958d-bcff4d565b40@gmail.com
2024-02-15wifi: rtlwifi: rtl8192cu: Fix 2T2R chip type detectionBitterblue Smith
rtl8192cu handles 1T1R devices (RTL8188CUS), 1T2R devices (RTL8191CU), and 2T2R devices (RTL8192CU). The 2T2R devices were incorrectly detected as 1T2R because of a mistake in the IS_92C_1T2R macro. The visible effect of this is that the firmware was allowed to use TX rates only up to MCS7. Fix the IS_92C_1T2R macro. Now my 2T2R device has much better upload speed. Before: 46 Mbps. After: 82 Mbps. Also fix a debug message which was printing "RF_1T1R" even for 1T2R chips. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/ed960059-5c77-422d-ac4e-fe9fc9d0d296@gmail.com
2024-02-08wifi: mac80211: simplify non-chanctx driversJohannes Berg
There are still surprisingly many non-chanctx drivers, but in mac80211 that code is a bit awkward. Simplify this by having those drivers assign 'emulated' ops, so that the mac80211 code can be more unified between non-chanctx/chanctx drivers. This cuts the number of places caring about it by about 15, which are scattered across - now they're fewer and no longer in the channel context handling. Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2024-01-19wifi: rtlwifi: Speed up firmware loading for USBBitterblue Smith
Currently it takes almost 6 seconds to upload the firmware for RTL8192CU (and 11 seconds for RTL8192DU). That's because the firmware is uploaded one byte at a time. Also, after plugging the device, the firmware gets uploaded three times before a connection to the AP is established. Maybe this is fine for most users, but when testing changes to the driver it's really annoying to wait so long. Speed up the firmware upload by writing chunks of 64 bytes at a time. This way it takes about 110 ms for RTL8192CU (and about 210 ms for RTL8192DU). PCI devices could upload it in chunks of 4 bytes, but I don't have any to test and commit 89d32c9071aa ("rtlwifi: Download firmware as bytes rather than as dwords") decided otherwise anyway. Allocate memory for the firmware image with kmalloc instead of vzalloc because this memory is passed directly to usb_control_msg(), which can't take memory allocated by vmalloc. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/d9bd4949-6e92-4f35-8b60-3b45f9ad74ab@gmail.com
2024-01-18wifi: rtlwifi: rtl8192de: Don't read register in _rtl92de_query_rxphystatusBitterblue Smith
Instead of reading bit 9 of RFPGA0_XA_HSSIPARAMETER2 every time a frame is received, just use rtlphy->cck_high_power, which is initialised in _rtl92d_phy_bb_config(). That bit never changes anyway. With this change _rtl92de_query_rxphystatus() can be shared with the upcoming USB driver. The USB driver can't read registers in this function because register reading can sleep. Compile tested only. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/19a3e023-0eaa-4096-9f78-a2c8e909cb54@gmail.com
2024-01-12wifi: rtlwifi: rtl_usb: Use sync register writesBitterblue Smith
Currently rtl_usb performs register writes using the async usb_submit_urb() function. This appears to work fine for the RTL8192CU, but the RTL8192DU (soon to be supported by rtlwifi) has a problem: it transmits everything at the 1M rate in the 2.4 GHz band. (The 5 GHz band is still untested.) With this patch, rtl_usb performs the register writes using the synchronous usb_control_msg() function, and the RTL8192DU works normally. The RTL8192CU still works. The vendor drivers use the async writes in only one function, rtl8192du_trigger_gpio_0 / rtl8192cu_trigger_gpio_0, which probably doesn't even run in real life. They use sync writes everywhere else. Also, remove "sync" and "async" from the names of the members of struct rtl_io to avoid confusion: write{8,16,32}_async -> write{8,16,32} read{8,16,32}_sync -> read{8,16,32} Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/fb71bae6-8b19-4b6e-b4a6-0d260f2139e1@gmail.com
2024-01-12wifi: rtlwifi: cleanup few rtlxxx_tx_fill_desc() routinesDmitry Antipov
Remove unreachable branches in 'rtl92ce_tx_fill_desc()', 'rtl92cu_tx_fill_desc()' and 'rtl8723e_tx_fill_desc()'. Compile tested only. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240109104735.140550-1-dmantipov@yandex.ru
2023-12-21wifi: rtlwifi: rtl8723{be,ae}: using calculate_bit_shift()Su Hui
Using calculate_bit_shift() to replace rtl8723_phy_calculate_bit_shift(). And fix an undefined bitwise shift behavior problem. Signed-off-by: Su Hui <suhui@nfschina.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231219065739.1895666-12-suhui@nfschina.com
2023-12-21wifi: rtlwifi: rtl8723_common: using calculate_bit_shift()Su Hui
Using calculate_bit_shift() to replace rtl8723_phy_calculate_bit_shift(). And fix the undefined bitwise shift behavior problem. Fixes: 0a168b48cdf7 ("rtlwifi: rtl8723ae: rtl8723-common: Create new driver for common code") Signed-off-by: Su Hui <suhui@nfschina.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231219065739.1895666-11-suhui@nfschina.com
2023-12-21wifi: rtlwifi: rtl8192se: using calculate_bit_shift()Su Hui
Using calculate_bit_shift() to replace _rtl92s_phy_calculate_bit_shift(). And fix the undefined bitwise shift behavior problem. Fixes: d15853163bea ("rtlwifi: rtl8192se: Merge phy routines") Signed-off-by: Su Hui <suhui@nfschina.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231219065739.1895666-10-suhui@nfschina.com
generated by cgit (git 2.34.1) at 2025-03-21 01:18:49 +0000