summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek/rtlwifi
AgeCommit message (Collapse)Author
2022-05-22wifi: rtlwifi: remove always-true condition pointed out by GCC 12Jakub Kicinski
The .value is a two-dim array, not a pointer. struct iqk_matrix_regs { bool iqk_done; long value[1][IQK_MATRIX_REG_NUM]; }; Acked-by: Kalle Valo <kvalo@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-13rtlwifi: Use pr_warn instead of WARN_ONCEDongliang Mu
This memory allocation failure can be triggered by fault injection or high pressure testing, resulting a WARN. Fix this by replacing WARN with pr_warn. Reported-by: syzkaller <syzkaller@googlegroups.com> Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220511014453.1621366-1-dzm91@hust.edu.cn
2022-04-27rtlwifi: btcoex: fix if == else warningGuo Zhengkui
Fix the following coccicheck warning: drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:1604:2-4: WARNING: possible condition with no effect (if == else). Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220425031725.5808-1-guozhengkui@vivo.com
2022-04-12rtlwifi: rtl8192cu: Fix spelling mistake "writting" -> "writing"Lv Ruyi
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-12rtlwifi: Fix spelling mistake "cacluated" -> "calculated"Lv Ruyi
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/20220408095803.2495336-1-lv.ruyi@zte.com.cn
2022-04-11mac80211: prepare sta handling for MLO supportSriram R
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-04-06rtlwifi: replace usage of found with dedicated list iterator variableJakob Koschel
To move the list iterator variable into the list_for_each_entry_*() macro in the future it should be avoided to use the list iterator variable after the loop body. To *never* use the list iterator variable after the loop it was concluded to use a separate iterator variable instead of a found boolean [1]. This removes the need to use a found variable and simply checking if the variable was set, can determine if the break/goto was hit. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220324072124.62458-1-jakobkoschel@gmail.com
2022-03-16rtlwifi: rtl8821ae: fix typos in commentsJulia Lawall
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220314115354.144023-20-Julia.Lawall@inria.fr
2022-03-16rtlwifi: rtl8192cu: Add On Networks N150Jonathan Teh
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
2022-03-10rtlwifi: rtl8192ce: remove duplicated function '_rtl92ce_phy_set_rf_sleep'Lu Jicong
This function exists in phy_common.c as '_rtl92c_phy_set_rf_sleep'. Switch to the one in common file. Signed-off-by: Lu Jicong <jiconglu58@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220306090846.28523-1-jiconglu58@gmail.com
2022-02-01rtlwifi: remove redundant initialization of variable ul_encalgoColin Ian King
Variable ul_encalgo is initialized with a value that is never read, it is being re-assigned a new value in every case in the following switch statement. The initialization is redundant and can be removed. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220130223714.6999-1-colin.i.king@gmail.com
2021-12-20rtlwifi: rtl8192cu: Fix WARNING when calling local_irq_restore() with ↵Larry Finger
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-11-29rtlwifi: rtl8192de: Style clean-upsKees Cook
Clean up some style issues: - Use ARRAY_SIZE() even though it's a u8 array. - Remove redundant CHANNEL_MAX_NUMBER_2G define. Additionally fix some dead code WARNs. Acked-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://lore.kernel.org/lkml/57d0d1b6064342309f680f692192556c@realtek.com/ Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211119192233.1021063-1-keescook@chromium.org
2021-10-13wireless: Remove redundant 'flush_workqueue()' callsChristophe JAILLET
'destroy_workqueue()' already drains the queue before destroying it, so there is no need to flush it explicitly. Remove the redundant 'flush_workqueue()' calls. This was generated with coccinelle: @@ expression E; @@ - flush_workqueue(E); destroy_workqueue(E); Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/0855d51423578ad019c0264dad3fe47a2e8af9c7.1633849511.git.christophe.jaillet@wanadoo.fr
2021-10-13rtlwifi: rtl8192ee: Remove redundant initialization of variable versionColin Ian King
The variable version is being initialized with a value that is never read, it is being updated afterwards in both branches of an if statement. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20211007163722.20165-1-colin.king@canonical.com
2021-08-29rtlwifi: rtl8192de: Fix initialization of place in ↵Nathan Chancellor
_rtl92c_phy_get_rightchnlplace() Clang warns: drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:901:6: warning: variable 'place' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] if (chnl > 14) { ^~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:909:9: note: uninitialized use occurs here return place; ^~~~~ drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:901:2: note: remove the 'if' if its condition is always true if (chnl > 14) { ^~~~~~~~~~~~~~~ drivers/net/wireless/realtek/rtlwifi/rtl8192de/phy.c:899:10: note: initialize the variable 'place' to silence this warning u8 place; ^ = '\0' 1 warning generated. Commit 369956ae5720 ("rtlwifi: rtl8192de: Remove redundant variable initializations") removed the initialization of place but it appears that this removal was in the wrong function. _rtl92c_phy_get_rightchnlplace() returns place's value at the end of the function so now if the if statement is false, place never gets initialized. Add that initialization back to address the warning. place's initialization is not necessary in rtl92d_get_rightchnlplace_for_iqk() as place is only used within the if statement so it can be removed, which is likely what was intended in the first place. Fixes: 369956ae5720 ("rtlwifi: rtl8192de: Remove redundant variable initializations") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210823222014.764557-1-nathan@kernel.org
2021-08-21rtlwifi: rtl8192de: make arrays static const, makes object smallerColin Ian King
Don't populate arrays the stack but instead make them static const. Replace array channel_info with channel_all since it contains the same data as channel_all. Makes object code smaller by 961 bytes. Before: text data bss dec hex filename 128147 44250 1024 173421 2a56d ../realtek/rtlwifi/rtl8192de/phy.o After text data bss dec hex filename 127122 44314 1024 172460 2a1ac ../realtek/rtlwifi/rtl8192de/phy.o (gcc version 10.2.0) Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210803144949.79433-2-colin.king@canonical.com
2021-08-21rtlwifi: rtl8192de: Remove redundant variable initializationsColin Ian King
The variables rtstatus and place are being initialized with a values that are never read, the initializations are redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210803144949.79433-1-colin.king@canonical.com
2021-06-22rtlwifi: rtl8192de: Fully initialize curvecount_valKees Cook
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring array fields. The size argument to memset() is bytes, but the array element size of curvecount_val is u32, so "CV_CURVE_CNT * 2" was only 1/4th of the contents of curvecount_val. Adjust memset() to wipe full buffer size. Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210617171317.3410722-1-keescook@chromium.org
2021-06-15rtlwifi: Fix spelling of 'download'Ding Senjie
downlaod -> download Signed-off-by: Ding Senjie <dingsenjie@yulong.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210521062734.21284-1-dingsenjie@163.com
2021-06-15rtlwifi: Remove redundant assignments to ul_enc_algoYang Li
Variable ul_enc_algo is being initialized with a value that is never read, it is being set again in the following switch statements in all of the case and default paths. Hence the unitialization is redundant and can be removed. Clean up clang warning: drivers/net/wireless/realtek/rtlwifi/cam.c:170:6: warning: Value stored to 'ul_enc_algo' during its initialization is never read [clang-analyzer-deadcode.DeadStores] Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1621303199-1542-1-git-send-email-yang.lee@linux.alibaba.com
2021-06-15rtlwifi: rtl8723ae: remove redundant initialization of variable rtstatusColin Ian King
The variable rtstatus is being initialized with a value that is never read, it is being updated later on. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210513122410.59204-1-colin.king@canonical.com
2021-06-15rtlwifi: btcoex: 21a 2ant: Delete several duplicate condition branch codesZhen Lei
The statements of the "if (max_interval == 3)" branch are the same as those of the "else" branch. Delete them to simplify the code. No functional change. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210510082237.3315-1-thunder.leizhen@huawei.com
2021-06-15rtlwifi: 8821a: btcoexist: add comments to explain why if-else branches are ↵Ping-Ke Shih
identical The coexistence programmers preserve the same code of branches intentionally to fine tune performance easier, because bandwidth and RSSI strength are highly related to coexistence performance. The basic rule of performance tuning is to assign most time slot to BT for realtime application, and WiFi uses remaining time slot but don't lower than low bound. Reported-by: Inigo Huguet <ihuguet@redhat.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210506013738.5943-1-pkshih@realtek.com
2021-06-15rtlwifi: Fix wrong function name in commentsYang Shen
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
2021-05-13net: rtlwifi: properly check for alloc_workqueue() failureGreg Kroah-Hartman
If alloc_workqueue() fails, properly catch this and propagate the error to the calling functions, so that the devuce initialization will properly error out. Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Bryan Brattlof <hello@bryanbrattlof.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-14-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-05-13Revert "rtlwifi: fix a potential NULL pointer dereference"Greg Kroah-Hartman
This reverts commit 765976285a8c8db3f0eb7f033829a899d0c2786e. Because of recent interactions with developers from @umn.edu, all commits from them have been recently re-reviewed to ensure if they were correct or not. Upon review, this commit was found to be incorrect for the reasons below, so it must be reverted. It will be fixed up "correctly" in a later kernel change. This commit is not correct, it should not have used unlikely() and is not propagating the error properly to the calling function, so it should be reverted at this point in time. Also, if the check failed, the work queue was still assumed to be allocated, so further accesses would have continued to fail, meaning this patch does nothing to solve the root issues at all. Cc: Kangjie Lu <kjlu@umn.edu> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Bryan Brattlof <hello@bryanbrattlof.com> Fixes: 765976285a8c ("rtlwifi: fix a potential NULL pointer dereference") Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210503115736.2104747-13-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-21rtlwifi: implement set_tim by update beacon contentPing-Ke Shih
Once beacon content is changed, we update the content to wifi card by send_beacon_frame(). Then, STA with PS can wake up properly to receive its packets. Since we update beacon content to PCI wifi devices every beacon interval, the only one usb device, 8192CU, needs to update beacon content when mac80211 calling set_tim. Reported-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210419065956.6085-1-pkshih@realtek.com
2021-04-17rtlwifi: rtl8192de: Use DEFINE_SPINLOCK() for spinlockGuobin Huang
spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Guobin Huang <huangguobin4@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1617711406-49649-1-git-send-email-huangguobin4@huawei.com
2021-04-17rtlwifi: Simplify locking of a skb list accessesChristophe JAILLET
The 'c2hcmd_lock' spinlock is only used to protect some __skb_queue_tail() and __skb_dequeue() calls. Use the lock provided in the skb itself and call skb_queue_tail() and skb_dequeue(). These functions already include the correct locking. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/99cf8894fd52202cb7ce2ec6e3200eef400bc071.1617609346.git.christophe.jaillet@wanadoo.fr
2021-04-17rtlwifi: remove rtl_get_tid_hChristophe JAILLET
'rtl_get_tid_h()' is the same as 'ieee80211_get_tid()'. So this function can be removed to save a line of code. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/db340a67a95c119e4f9ba8fa99aea1c73d0dcfc9.1617383263.git.christophe.jaillet@wanadoo.fr
2021-04-17rtlwifi: rtl8188ee: remove redundant assignment of variable ↵Yang Li
rtlpriv->btcoexist.reg_bt_sco Assigning value "3" to "rtlpriv->btcoexist.reg_bt_sco" here, but that stored value is overwritten before it can be used. Coverity reports this problem as CWE563: A value assigned to a variable is never used. drivers/net/wireless/realtek/rtlwifi/rtl8188ee/hw.c: rtl8188ee_bt_reg_init Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1617182023-110950-1-git-send-email-yang.lee@linux.alibaba.com
2021-04-17rtlwifi: remove redundant assignment to variable errColin Ian King
Variable err is assigned -ENODEV followed by an error return path via label error_out that does not access the variable and returns with the -ENODEV error return code. The assignment to err is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210327230014.25554-1-colin.king@canonical.com
2021-04-17rtlwifi: Few mundane typo fixesBhaskar Chowdhury
s/resovle/resolve/ s/broadcase/broadcast/ s/sytem/system/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210320194426.21621-1-unixbhaskar@gmail.com
2021-04-17rtlwifi: 8821ae: upgrade PHY and RF parametersPing-Ke Shih
The signal strength of 5G is quite low, so user can't connect to an AP far away. New parameters with new format and its parser are updated by the commit 84d26fda52e2 ("rtlwifi: Update 8821ae new phy parameters and its parser."), but some parameters are missing. Use this commit to update to the novel parameters that use new format. Fixes: 84d26fda52e2 ("rtlwifi: Update 8821ae new phy parameters and its parser") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210219052607.7323-1-pkshih@realtek.com
2021-02-10rtlwifi: rtl8821ae: phy: Simplify bool comparisonJiapeng Chong
Fix the following coccicheck warning: ./drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:3853:7-17: WARNING: Comparison of 0/1 to bool variable. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1612840381-109714-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-02-10rtlwifi: rtl8192se: Simplify bool comparisonJiapeng Chong
Fix the follow coccicheck warnings: ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:2305:6-27: WARNING: Comparison of 0/1 to bool variable. ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:1376:5-26: WARNING: Comparison of 0/1 to bool variable. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/1612839264-85773-1-git-send-email-jiapeng.chong@linux.alibaba.com
2021-02-08rtlwifi: rtl8192se: remove redundant initialization of variable rtstatusColin Ian King
The variable rtstatu is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210128171048.644669-1-colin.king@canonical.com
2021-02-08rtlwifi: use tasklet_setup to initialize rx_work_taskletEmil Renner Berthing
In commit d3ccc14dfe95 most of the tasklets in this driver was updated to the new API. However for the rx_work_tasklet only the type of the callback was changed from void _rtl_rx_work(unsigned long data) to void _rtl_rx_work(struct tasklet_struct *t). The initialization of rx_work_tasklet was still open-coded and the function pointer just cast into the old type, and hence nothing sets rx_work_tasklet.use_callback = true and the callback was still called as t->func(t->data); with uninitialized/zero t->data. Commit 6b8c7574a5f8 changed the casting of _rtl_rx_work a bit and initialized t->data to a pointer to the tasklet cast to an unsigned long. This way calling t->func(t->data) might actually work through all the casting, but it still doesn't update the code to use the new tasklet API. Let's use the new tasklet_setup to initialize rx_work_tasklet properly and set rx_work_tasklet.use_callback = true so that the callback is called as t->callback(t); without all the casting. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210126171550.3066-1-kernel@esmil.dk
2021-01-25rtlwifi: rtl8821ae: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl8821ae, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c, "if (rtlefuse->autoload_failflag == false)" can be replaced with "if (!rtlefuse->autoload_failflag)" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-6-yashsri421@gmail.com
2021-01-25rtlwifi: rtl8192se: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl8192se, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-5-yashsri421@gmail.com
2021-01-25rtlwifi: rtl8188ee: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl8188ee, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8188ee/dm.c, "if (mac->act_scanning == true)" can be replaced with "if (mac->act_scanning)" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-4-yashsri421@gmail.com
2021-01-25rtlwifi: rtl8192c-common: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl8192c-common, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/rtl8192c/dm_common.c, "else if (initialized == false) {" can be replaced with "else if (!initialized) {" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-3-yashsri421@gmail.com
2021-01-25rtlwifi: rtl_pci: fix bool comparison in expressionsAditya Srivastava
There are certain conditional expressions in rtl_pci, where a boolean variable is compared with true/false, in forms such as (foo == true) or (false != bar), which does not comply with checkpatch.pl (CHECK: BOOL_COMPARISON), according to which boolean variables should be themselves used in the condition, rather than comparing with true/false E.g., in drivers/net/wireless/realtek/rtlwifi/ps.c, "if (find_p2p_ie == true)" can be replaced with "if (find_p2p_ie)" Replace all such expressions with the bool variables appropriately Signed-off-by: Aditya Srivastava <yashsri421@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210110121525.2407-2-yashsri421@gmail.com
2020-12-17rtlwifi: rise completion at the last step of firmware callbackPing-Ke Shih
request_firmware_nowait() which schedules another work is used to load firmware when USB is probing. If USB is unplugged before running the firmware work, it goes disconnect ops, and then causes use-after-free. Though we wait for completion of firmware work before freeing the hw, firmware callback rises completion too early. So I move it to the last step. usb 5-1: Direct firmware load for rtlwifi/rtl8192cufw.bin failed with error -2 rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin rtlwifi: Selected firmware is not available ================================================================== BUG: KASAN: use-after-free in rtl_fw_do_work.cold+0x68/0x6a drivers/net/wireless/realtek/rtlwifi/core.c:93 Write of size 4 at addr ffff8881454cff50 by task kworker/0:6/7379 CPU: 0 PID: 7379 Comm: kworker/0:6 Not tainted 5.10.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events request_firmware_work_func Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xae/0x4c8 mm/kasan/report.c:385 __kasan_report mm/kasan/report.c:545 [inline] kasan_report.cold+0x1f/0x37 mm/kasan/report.c:562 rtl_fw_do_work.cold+0x68/0x6a drivers/net/wireless/realtek/rtlwifi/core.c:93 request_firmware_work_func+0x12c/0x230 drivers/base/firmware_loader/main.c:1079 process_one_work+0x933/0x1520 kernel/workqueue.c:2272 worker_thread+0x64c/0x1120 kernel/workqueue.c:2418 kthread+0x38c/0x460 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 The buggy address belongs to the page: page:00000000f54435b3 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1454cf flags: 0x200000000000000() raw: 0200000000000000 0000000000000000 ffffea00051533c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881454cfe00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff8881454cfe80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff8881454cff00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff8881454cff80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff8881454d0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Reported-by: syzbot+65be4277f3c489293939@syzkaller.appspotmail.com Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214053106.7748-1-pkshih@realtek.com
2020-12-09rtlwifi: rtl8192de: fix ofdm power compensationPing-Ke Shih
ofdm_index[] is used to indicate how many power compensation is needed to current thermal value. For internal PA module or 2.4G band, the min_index is different from other cases. This issue originally is reported by Dan. He found the size of ofdm_index[] is 2, but access index 'i' may be equal to 2 if 'rf' is 2 in case of 'is2t'. In fact, the chunk of code is added to wrong place, so move it back to proper place, and then power compensation and buffer overflow are fixed. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201207031903.7599-1-pkshih@realtek.com
2020-11-24rtlwifi: rtl8723ae: avoid accessing the data mapped to streaming DMAJia-Ju Bai
In rtl8723e_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on line 531: dma_addr_t mapping = dma_map_single(..., skb->data, ...); On line 534, skb->data is assigned to hdr after cast: struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data); Then hdr->frame_control is accessed on line 535: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201119015218.12220-1-baijiaju1990@gmail.com
2020-11-24rtlwifi: rtl8192de: avoid accessing the data mapped to streaming DMAJia-Ju Bai
In rtl92de_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on line 667: dma_addr_t mapping = dma_map_single(..., skb->data, ...); On line 669, skb->data is assigned to hdr after cast: struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data); Then hdr->frame_control is accessed on line 670: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201119015205.12162-1-baijiaju1990@gmail.com
2020-11-24rtlwifi: rtl8192ce: avoid accessing the data mapped to streaming DMAJia-Ju Bai
In rtl92ce_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on line 530: dma_addr_t mapping = dma_map_single(..., skb->data, ...); On line 533, skb->data is assigned to hdr after cast: struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data); Then hdr->frame_control is accessed on line 534: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201119015151.12110-1-baijiaju1990@gmail.com
2020-11-24rtlwifi: rtl8188ee: avoid accessing the data mapped to streaming DMAJia-Ju Bai
In rtl88ee_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on line 677: dma_addr_t mapping = dma_map_single(..., skb->data, ...); On line 680, skb->data is assigned to hdr after cast: struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data); Then hdr->frame_control is accessed on line 681: __le16 fc = hdr->frame_control; This DMA access may cause data inconsistency between CPU and hardwre. To fix this bug, hdr->frame_control is accessed before the DMA mapping. Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201119015127.12033-1-baijiaju1990@gmail.com
generated by cgit (git 2.34.1) at 2025-04-06 10:10:57 +0000