summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtlwifi/rtl8192cu
AgeCommit message (Collapse)AuthorFilesLines
2024-05-30wifi: rtlwifi: Constify rtl_hal_cfg.{ops,usb_interface_cfg} and rtl_priv.cfgBitterblue Smith1-2/+1
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-03-22wifi: rtlwifi: always assume QoS mode in rtl8192cuDmitry Antipov1-26/+4
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 Antipov1-117/+48
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-02-21wifi: rtlwifi: set initial values for unexpected cases of USB endpoint priorityPing-Ke Shih1-3/+3
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 Smith2-14/+17
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 Smith3-37/+42
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 Smith2-2/+3
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-01-19wifi: rtlwifi: Speed up firmware loading for USBBitterblue Smith1-3/+3
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-12wifi: rtlwifi: cleanup few rtlxxx_tx_fill_desc() routinesDmitry Antipov1-3/+0
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: rtl8192cu: using calculate_bit_shift()Su Hui1-3/+3
Using calculate_bit_shift() to replace _rtl92c_phy_calculate_bit_shift(). And fix an undefined bitwise shift behavior problem. Fixes: f0a39ae738d6 ("rtlwifi: rtl8192cu: Add routine phy") Signed-off-by: Su Hui <suhui@nfschina.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20231219065739.1895666-6-suhui@nfschina.com
2023-10-19wifi: rtlwifi: drop fill_fake_txdesc() from HAL interfaceDmitry Antipov3-29/+0
Since 'fill_fake_txdesc()' is actually implemented for rtl8192cu only but never used, there is no need to maintain function pointer in 'struct rtl_hal_ops' and 'rtl92cu_fill_fake_txdesc()' may be dropped. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231016135925.129223-2-dmantipov@yandex.ru
2023-10-14wifi: rtlwifi: simplify TX command fill callbacksDmitry Antipov3-9/+6
Since 'rtlpriv->cfg->ops->fill_tx_cmddesc()' is always called with 'firstseg' and 'lastseg' set to 1 (and the latter is never actually used), all of the relevant chip-specific routines may be simplified. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20231011154442.52457-2-dmantipov@yandex.ru
2023-06-21wifi: rtlwifi: simplify LED managementDmitry Antipov3-53/+11
Introduce 'rtl_init_sw_leds()' to replace per-chip LED initialization code (and so drop 'struct rtl_led' as no longer used), drop 'init_sw_leds' and 'deinit_sw_leds' fields from 'struct rtl_hal_ops', adjust related code. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230614061832.40882-1-dmantipov@yandex.ru
2023-06-01wifi: rtlwifi: use helper function rtl_get_hdr()Juhee Kang1-2/+2
Although rtl_get_hdr was added in commit 3dad618b7b92 ("rtlwifi: Change wifi.h for rtl8192se and rtl8192de"), it is currently not being utilized in some areas. This commit replaces the open code with the rtl_get_hdr() function. Signed-off-by: Juhee Kang <claudiajkang@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230527114954.3281-1-claudiajkang@gmail.com
2022-04-12rtlwifi: rtl8192cu: Fix spelling mistake "writting" -> "writing"Lv Ruyi1-2/+2
There are some spelling mistakes in the comments. Fix it. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220411032458.2517551-1-lv.ruyi@zte.com.cn
2022-04-11mac80211: prepare sta handling for MLO supportSriram R2-14/+14
Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it. With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif. To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this. For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member. For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info. Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases. Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink. @ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@ ( s-> - var + deflink.var | si->sta. - var + deflink.var ) @sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@ ( si-> - var + deflink.var ) Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-03-16rtlwifi: rtl8192cu: Add On Networks N150Jonathan Teh1-0/+1
This is an RTL8188CUS device, identifies as model N150MA-199WWS. Signed-off-by: Jonathan Teh <jonathan.teh@outlook.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/DBAPR04MB7366E8014ECA839E1F5CCE29920E9@DBAPR04MB7366.eurprd04.prod.outlook.com
2021-12-20rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with ↵Larry Finger1-0/+1
interrupts enabled Syzbot reports the following WARNING: [200~raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 1 PID: 1206 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x1d/0x20 kernel/locking/irqflag-debug.c:10 Hardware initialization for the rtl8188cu can run for as long as 350 ms, and the routine may be called with interrupts disabled. To avoid locking the machine for this long, the current routine saves the interrupt flags and enables local interrupts. The problem is that it restores the flags at the end without disabling local interrupts first. This patch fixes commit a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long disable of IRQs"). Reported-by: syzbot+cce1ee31614c171f5595@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Fixes: a53268be0cb9 ("rtlwifi: rtl8192cu: Fix too long disable of IRQs") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20211215171105.20623-1-Larry.Finger@lwfinger.net
2021-06-15rtlwifi: Fix wrong function name in commentsYang Shen1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:124: warning: expecting prototype for writeLLT(). Prototype was for rtl92c_llt_write() instead drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:154: warning: expecting prototype for rtl92c_init_LLT_table(). Prototype was for rtl92c_init_llt_table() instead Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Yang Shen <shenyang39@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210517050141.61488-9-shenyang39@huawei.com
2020-11-07rtlwifi: rtl8192cu: trx: Demote clear abuse of kernel-doc formatLee Jones1-1/+1
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:455: warning: Function parameter or member 'txdesc' not described in '_rtl_tx_desc_checksum' Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201102112410.1049272-6-lee.jones@linaro.org
2020-11-07rtlwifi: rtl8192cu: mac: Fix some missing/ill-documented function parametersLee Jones1-4/+3
Fixes the following W=1 kernel build warning(s): drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:124: warning: Function parameter or member 'hw' not described in 'rtl92c_llt_write' drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:124: warning: Excess function parameter 'io' description in 'rtl92c_llt_write' drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:155: warning: Function parameter or member 'hw' not described in 'rtl92c_init_llt_table' drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:155: warning: Excess function parameter 'io' description in 'rtl92c_init_llt_table' Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201102112410.1049272-4-lee.jones@linaro.org
2020-09-21rtlwifi: rtl8192cu: fix comparison to bool warning in hw.cZheng Bin1-1/+1
Fixes coccicheck warning: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:831:14-49: WARNING: Comparison to bool Signed-off-by: Zheng Bin <zhengbin13@huawei.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200918102505.16036-7-zhengbin13@huawei.com
2020-09-21rtlwifi: rtl8192cu: fix comparison to bool warning in mac.cZheng Bin1-4/+4
Fixes coccicheck warning: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:161:14-17: WARNING: Comparison to bool drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:168:13-16: WARNING: Comparison to bool drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:179:14-17: WARNING: Comparison to bool drivers/net/wireless/realtek/rtlwifi/rtl8192cu/mac.c:186:13-16: WARNING: Comparison to bool Signed-off-by: Zheng Bin <zhengbin13@huawei.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200918102505.16036-4-zhengbin13@huawei.com
2020-08-31rtlwifi: rtl8192cu: Rename RT_TRACE to rtl_dbgLarry Finger7-231/+231
Change the misleading macro name to one that is more descriptive for rtl8192cu. Changes suggested by ckeckpatch.pl have been made. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200723204244.24457-8-Larry.Finger@lwfinger.net
2020-07-16treewide: Remove uninitialized_var() usageKees Cook1-2/+2
Using uninitialized_var() is dangerous as it papers over real bugs[1] (or can in the future), and suppresses unrelated compiler warnings (e.g. "unused variable"). If the compiler thinks it is uninitialized, either simply initialize the variable or make compiler changes. In preparation for removing[2] the[3] macro[4], remove all remaining needless uses with the following script: git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \ xargs perl -pi -e \ 's/\buninitialized_var\(([^\)]+)\)/\1/g; s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;' drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid pathological white-space. No outstanding warnings were found building allmodconfig with GCC 9.3.0 for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64, alpha, and m68k. [1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/ [2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/ [3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/ [4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/ Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5 Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs Signed-off-by: Kees Cook <keescook@chromium.org>
2020-07-16rtlwifi: rtl8192cu: Remove uninitialized_var() usageKees Cook1-2/+2
Using uninitialized_var() is dangerous as it papers over real bugs[1] (or can in the future), and suppresses unrelated compiler warnings (e.g. "unused variable"). If the compiler thinks it is uninitialized, either simply initialize the variable or make compiler changes. As a precursor to removing[2] this[3] macro[4], just initialize this variable to NULL, and avoid sending garbage by returning. [1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/ [2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/ [3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/ [4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/ Fixes: dc0313f46664 ("rtlwifi: rtl8192cu: Add routine hw") Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Kalle Valo <kvalo@codeaurora.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2020-01-26rtlwifi: rtl8192cu: Remove sw.h headerAmadeusz Sławiński2-28/+0
It has one define, which is already defined in include from reg.h. All functions are declared in their own headers and included in *.c files belonging to them. This makes sw.h unnecessary, so we can remove it. Signed-off-by: Amadeusz Sławiński <amade@asmblr.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2020-01-26rtlwifi: rtl8192cu: Fix typoAmadeusz Sławiński1-17/+17
Replace USB_VENDER_ID_REALTEK with USB_VENDOR_ID_REALTEK. Signed-off-by: Amadeusz Sławiński <amade@asmblr.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-12-18rtlwifi: rtl8192cu: use generic rtl_signal_scale_mappingMichael Straube1-31/+2
Function _rtl92c_signal_scale_mapping is identical to the generic version rtl_signal_scale_mapping. Remove _rtl92c_signal_scale_mapping and use the generic function. Signed-off-by: Michael Straube <straube.linux@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-12-18rtlwifi: rtl8192cu: use generic rtl_query_rxpwrpercentageMichael Straube1-13/+3
Function _rtl92c_query_rxpwrpercentage is identical to the generic version rtl_query_rxpwrpercentage. Remove _rtl92c_query_rxpwrpercentage and use the generic function. Signed-off-by: Michael Straube <straube.linux@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-11-06rtlwifi: fix memory leak in rtl92c_set_fw_rsvdpagepkt()Ping-Ke Shih1-0/+2
This leak was found by testing the EDIMAX EW-7612 on Raspberry Pi 3B+ with Linux 5.4-rc5 (multi_v7_defconfig + rtlwifi + kmemleak) and noticed a single memory leak during probe: unreferenced object 0xec13ee40 (size 176): comm "kworker/u8:1", pid 36, jiffies 4294939321 (age 5580.790s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<fc1bbb3e>] __netdev_alloc_skb+0x9c/0x164 [<863dfa6e>] rtl92c_set_fw_rsvdpagepkt+0x254/0x340 [rtl8192c_common] [<9572be0d>] rtl92cu_set_hw_reg+0xf48/0xfa4 [rtl8192cu] [<116df4d8>] rtl_op_bss_info_changed+0x234/0x96c [rtlwifi] [<8933575f>] ieee80211_bss_info_change_notify+0xb8/0x264 [mac80211] [<d4061e86>] ieee80211_assoc_success+0x934/0x1798 [mac80211] [<e55adb56>] ieee80211_rx_mgmt_assoc_resp+0x174/0x314 [mac80211] [<5974629e>] ieee80211_sta_rx_queued_mgmt+0x3f4/0x7f0 [mac80211] [<d91091c6>] ieee80211_iface_work+0x208/0x318 [mac80211] [<ac5fcae4>] process_one_work+0x22c/0x564 [<f5e6d3b6>] worker_thread+0x44/0x5d8 [<82c7b073>] kthread+0x150/0x154 [<b43e1b7d>] ret_from_fork+0x14/0x2c [<794dff30>] 0x0 It is because 8192cu doesn't implement usb_cmd_send_packet(), and this patch just frees the skb within the function to resolve memleak problem by now. Since 8192cu doesn't turn on fwctrl_lps that needs to download command packet for firmware via the function, applying this patch doesn't affect driver behavior. Reported-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-13rtlwifi: rtl8192cu: replace _rtl92c_evm_db_to_percentage with generic versionMichael Straube1-17/+1
Function _rtl92c_evm_db_to_percentage is functionally identical to the generic version rtl_evm_db_to_percentage, so remove _rtl92c_evm_db_to_percentage and use the generic version instead. Signed-off-by: Michael Straube <straube.linux@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-03rtlwifi: rtl8192cu: Convert inline routines to little-endian wordsLarry Finger3-121/+127
In this step, the read/write routines for the descriptors are converted to use __le32 quantities, thus a lot of casts can be removed. Callback routines still use the 8-bit arrays, but these are changed within the specified routine. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-03rtlwifi: rtl8192cu: Convert macros that set descriptorLarry Finger3-235/+402
As a first step in the conversion, the macros that set the RX and TX descriptors are converted to static inline routines, and the names are changed from upper to lower case. To minimize the changes in a given step, the input descriptor information is left as as a byte array (u8 *), even though it should be a little-endian word array (__le32 *). That will be changed in the next patch. Several places where checkpatch.pl complains about a space after a cast and other warnings are fixed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-03rtlwifi: rtl8192cu: Replace local bit manipulation macrosLarry Finger1-55/+55
This driver uses a set of local macros to manipulate the TX and RX descriptors, which are all little-endian quantities. These macros are replaced by the bitfield macros le32p_replace_bits() and le32_get_bits(). In several places, the macros operated on an entire 32-bit word. In these cases, a direct read or replacement is used. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-03rtlwifi: rtl8192cu: Remove unused GET_XXX and SET_XXXLarry Finger1-147/+3
As the first step in converting from macros that get/set information in the RX and TX descriptors, unused macros are being removed. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-09-03rtlwifi: rtl8192cu: Fix value set in descriptorLarry Finger1-1/+1
In the process of converting the bit manipulation macros were converted to use GENMASK(), the compiler reported a value too big for the field. The offending statement was trying to write 0x100 into a 5-bit field. An accompaning comment says to set bit 3, thus the code is changed appropriately. This error has been in the driver since its initial submission. Fixes: 29d00a3e46bb ("rtlwifi: rtl8192cu: Add routine trx") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-07-24rtlwifi: remove assignment to itselfPing-Ke Shih1-2/+0
Module parameters of 'sw_crypto' and 'disable_watchdog' are false by default. If new value is desired, we can do it during inserting module, assignment existing in source code is not reasonable. Reported-by: David Binderman <dcb314@hotmail.com> CC: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-04-26rtlwifi: rtl8192cu: remove set but not used variable 'turbo_scanoff'YueHaibing1-3/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c: In function 'rtl92cu_phy_rf6052_set_cck_txpower': drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:45:7: warning: variable 'turbo_scanoff' set but not used [-Wunused-but-set-variable] It is not used any more since commit e9b0784bb9de ("rtlwifi: rtl8192cu: Fix some code in RF handling") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-28rtlwifi: rtl8192cu: Fix problems with blank linesLarry Finger6-11/+22
The following problems were found: WARNING: Missing a blank line after declarations CHECK: Please don't use multiple blank lines CHECK: Please use a blank line after function/struct/union/enum declarations There are no code changes. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19rtlwifi: rtl8192{c,u}: Remove CamelCase variablesLarry Finger9-250/+250
This patch affects modules rtl8192ce, rtl8192cu, and rtl8192com. The following checkpatch exceptions are also fixed: CHECK: No space is necessary after a cast #237: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c:90: + (u8 *) (&rfstate)); CHECK: No space is necessary after a cast #744: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/rf.c:329: + pwr_val[i] = (u8) ((writeval & (0x7f << CHECK: No space is necessary after a cast #784: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/rf.c:365: + (u8) writeval); CHECK: spaces preferred around that '/' (ctx:VxV) #963: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:513: + txqpageunit = txqpagenum/outepnum; ^ CHECK: Unnecessary parentheses around 'outepnum > 1' #975: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:521: + if ((outepnum > 1) && (txqremaininpage)) CHECK: Alignment should match open parenthesis #1059: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/hw.c:617: +static void _rtl92cu_init_chipn_two_out_ep_priority(struct ieee80211_hw *hw, bool wmm_enable, ERROR: "foo * bar" should be "foo *bar" #1940: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:591: +void rtl92cu_fill_fake_txdesc(struct ieee80211_hw *hw, u8 *pdesc, Note that not all checkpatch exceptions are addressed. Those will be handled in later patches. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19rtlwifi: Remove CamelCase variables from base codeLarry Finger2-3/+3
There are a number of CamelCase variables remaining in the source files of modules rtl_pci, rtl_usb, and rtlwifi. The following checkpatch excettions are also fixed: for_kalle1/0001-rtlwifi-Remove-CamelCase-variables-from-base-code.patch ----------------------------------------------------------------------- CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]' #68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1]' #68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377: + if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) || + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != + rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i + 1])) { WARNING: line over 80 characters #70: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:379: + (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] != CHECK: No space is necessary after a cast #186: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:396: + status->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast #208: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c:335: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast #243: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:301: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); CHECK: No space is necessary after a cast #252: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:368: + stats.rx_is40mhzpacket = (bool) GET_RX_DESC_BW(rxdesc); CHECK: No space is necessary after a cast #265: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c:475: + stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc); WARNING: Unnecessary space before function pointer arguments #455: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:1462: + void (*writen_sync) (struct rtl_priv *rtlpriv, u32 addr, void *buf, WARNING: Unnecessary space before function pointer arguments #483: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:2257: + void (*fill_fake_txdesc) (struct ieee80211_hw *hw, u8 *pdesc, Note that not all checkpatch exceptions are addressed. Those will be handled in later patches. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2019-02-19rtlwifi: rtl8192cu: Replace old-style license informationLarry Finger20-476/+40
The traditional license information is replaced by the SPDX form. There are no code changes. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-02-27rtlwifi: rtl8192cu: remove pointless memcpyArnd Bergmann1-1/+0
gcc-8 points out that source and destination of the memcpy() are always the same pointer, so the effect of memcpy() is undefined here (its arguments must not overlap): drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c: In function '_rtl_rx_process': drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:430:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict] Most likely this is harmless, but it's easy to just remove the line and get rid of the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2018-02-27rtlwifi: rtl8192cu: Remove variable self-assignment in rf.cMatthias Kaehlcke1-3/+0
In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal is assigned to itself in an if ... else statement, apparently only to document that the branch condition is handled and that a previously read value should be returned unmodified. The self-assignment causes clang to raise the following warning: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13: error: explicitly assigning value of variable of type 'u32' (aka 'unsigned int') to itself [-Werror,-Wself-assign] writeVal = writeVal; Delete the branch with the self-assignment. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
2017-11-04Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller1-0/+1
Files removed in 'net-next' had their license header updated in 'net'. We take the remove from 'net-next'. Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisite