Use min()/max() to reduce the code and improve its readability.
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250715121721.266713-8-rongqianfeng@vivo.com
txpower_info_{2g,5g} are too big to fit on the stack, but in most of the
rtlwifi variants this stays below the warning limit for stack frames.
In rtl8192ee and a few others, I see a case where clang decides to fully
inline this into rtl92ee_read_eeprom_info, triggering this warning:
drivers/net/wireless/realtek/rtlwifi/rtl8192ee/hw.c:2178:6: error: stack frame size (1312) exceeds limit (1280) in 'rtl92ee_read_eeprom_info' [-Werror,-Wframe-larger-than]
Mark _rtl92ee_read_txpower_info_from_hwpg() as noinline_for_stack to
and mark _rtl92ee_get_chnl_group() as __always_inline to make clang
behave the same way as gcc. Inlining _rtl92ee_get_chnl_group helps
let the compiler see that the index is always in range. The same
change appears to be necessary in all rtlwifi variants.
A more thorough approach would be to avoid the use of the two structures
on the stack entirely and combine them with the struct rtl_efuse
data that is dynamically allocated and holds the same information.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250610092240.2639751-1-arnd@kernel.org
'struct rtl_hal_ops' and 'struct rtl_hal_cfg' are not modified in these
drivers.
Constifying this structure moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers.
Constification of rtl_hal_cfg is only needed in rtl8192cu/sw.c
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
10167 5512 128 15807 3dbf drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.o
After:
=====
text data bss dec hex filename
10743 4936 128 15807 3dbf drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/2c3f3d8d8b2f7dcb8cc64cebe89e55720d1d733d.1747500351.git.christophe.jaillet@wanadoo.fr
rtl92d_phy_ap_calibrate(),
rtl92du_phy_ap_calibrate(),
rtl92ee_phy_ap_calibrate(), and
rtl8821ae_phy_ap_calibrate()
are all empty function stubs that are never called anywhere.
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/20250425235340.288340-3-linux@treblig.org
A previous clean-up fix removed the assignment of v2 inside a while loop
that turned it into an infinite loop. Fix this by restoring the assignment
of v2 from array[] so that v2 is updated inside the loop.
Fixes: cda3744571 ("wifi: rtlwifi: rtl8821ae: phy: remove some useless code")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Tested-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Su Hui <suhui@nfschina.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241106154642.1627886-1-colin.i.king@gmail.com
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
_rtl8821ae_clear_pci_pme_status() accesses the upper byte of the Power
Management Control/Status register (PMCS) with literal 5 offset.
Access the entire PMCS register using defines from pci_regs.h to
improve code readability.
While at it, remove the obvious comment and tweak debug prints
slightly to not sound misleading.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-9-ilpo.jarvinen@linux.intel.com
Instead of open coding the capability structure search, find the PM
Capability using pci_find_capability().
While at it, rename the generic 'cap_pointer' to 'pm_cap' which makes
the intent of the code more obvious.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-7-ilpo.jarvinen@linux.intel.com
BIT(7) (PME_Status) is first checked and then set unnecessarily. Remove
the unnecessary setting for the bit that is already on and adjust the
comment related to it.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231124084725.12738-5-ilpo.jarvinen@linux.intel.com
Clang static checker warns:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:184:49:
The result of the left shift is undefined due to shifting by '32',
which is greater or equal to the width of type 'u32'.
[core.UndefinedBinaryOperatorResult]
If the value of the right operand is negative or is greater than or
equal to the width of the promoted left operand, the behavior is
undefined.[1][2]
For example, when using different gcc's compilation optimization options
(-O0 or -O2), the result of '(u32)data << 32' is different. One is 0, the
other is old value of data. Let _rtl8821ae_phy_calculate_bit_shift()'s
return value less than 32 to fix this problem. Warn if bitmask is zero.
[1] https://stackoverflow.com/questions/11270492/what-does-the-c-standard-say-about-bitshifting-more-bits-than-the-width-of-type
[2] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
Fixes: 21e4b0726d ("rtlwifi: rtl8821ae: Move driver from staging to regular tree")
Signed-off-by: Su Hui <suhui@nfschina.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231127013511.26694-2-suhui@nfschina.com
Clang static checker warns:
Value stored to 'v1' is never read [deadcode.DeadStores]
Value stored to 'channel' is never read [deadcode.DeadStores]
Remove them to save some place.
Signed-off-by: Su Hui <suhui@nfschina.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231127013511.26694-1-suhui@nfschina.com
Remove the unused "const_amdpci_aspm" member of struct rtl_pci and
struct rtl_ps_ctl.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20231116180529.52752-1-helgaas@kernel.org
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
Simplify 'rtl92ee_dm_common_info_self_update()',
'rtl8723be_dm_common_info_self_update()', and
'rtl8821ae_dm_common_info_self_update()' by using
'list_count_nodes()'. 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/20231011045227.7989-1-dmantipov@yandex.ru
Since 'u8' comparison against zero is always false, drop the
corresponding branches of AMPDU_MIN_SPACE adjustment within
'rtlxxxx_set_hw_reg()' for rtl8188ee, rtl8192ce, rtl8192de,
rtl8723ae, rtl8723be, and rtl8821ae. Compile tested only.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
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/20230925090452.25633-1-dmantipov@yandex.ru
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
There is a global-out-of-bounds reported by KASAN:
BUG: KASAN: global-out-of-bounds in
_rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]
Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411
CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D
6.1.0-rc8+ #144 e15588508517267d37
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
Call Trace:
<TASK>
...
kasan_report+0xbb/0x1c0
_rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]
rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]
rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]
...
</TASK>
The root cause of the problem is that the comparison order of
"prate_section" in _rtl8812ae_phy_set_txpower_limit() is wrong. The
_rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two
strings from tail to head, which causes the problem. In the
_rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet
this requirement by carefully designing the comparison order.
For example, "pregulation" and "pbandwidth" are compared in order of
length from small to large, first is 3 and last is 4. However, the
comparison order of "prate_section" dose not obey such order requirement,
therefore when "prate_section" is "HT", when comparing from tail to head,
it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As
mentioned above, the _rtl8812ae_eq_n_byte() has the same function as
strcmp(), so just strcmp() is enough.
Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely.
Although it can be fixed by adjusting the comparison order of
"prate_section", this may cause the value of "rate_section" to not be
from 0 to 5. In addition, commit "21e4b0726dc6" not only moved driver
from staging to regular tree, but also added setting txpower limit
function during the driver config phase, so the problem was introduced
by this commit.
Fixes: 21e4b0726d ("rtlwifi: rtl8821ae: Move driver from staging to regular tree")
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221212025812.1541311-1-lizetao1@huawei.com
It is not allowed to call kfree_skb() from hardware interrupt
context or with interrupts being disabled. All the SKBs have
been dequeued from the old queue, so it's safe to enqueue these
SKBs to a free queue, then free them after spin_unlock_irqrestore()
at once. Compile tested only.
Fixes: 5c99f04fec ("rtlwifi: rtl8723be: Update driver to match Realtek release of 06/28/14")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221207141411.46098-2-yangyingliang@huawei.com
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
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>
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
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
84d26fda52 ("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: 84d26fda52 ("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
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
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
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c: In function ‘_rtl8812ae_phy_get_txpower_limit’:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:2453:3: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
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-35-lee.jones@linaro.org
Fixes the following W=1 kernel build warning(s):
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c: In function ‘rtl8821ae_phy_switch_wirelessband’:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:597:14: warning: variable ‘rxpath’ set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:597:6: warning: variable ‘txpath’ set but not used [-Wunused-but-set-variable]
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-34-lee.jones@linaro.org
There are thousands of warnings in a W=2 build from just one file:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.c:3788:15: warning: pointer targets in initialization of 'u8 *' {aka 'unsigned char *'} from 'char *' differ in signedness [-Wpointer-sign]
Change the types to consistently use 'const char *' for the
strings.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20201026213040.3889546-6-arnd@kernel.org
This addresses the following coccinelle warning:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2680:27-47: WARNING:
Comparison of 0/1 to bool variable
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2683:3-23: WARNING:
Assignment of 0/1 to bool variable
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2686:3-23: WARNING:
Assignment of 0/1 to bool variable
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200919074428.3459234-1-yanaijie@huawei.com
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:1816:5-13: WARNING: Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:1825:5-13: WARNING: Comparison to bool
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:1839:5-13: 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-6-zhengbin13@huawei.com
Fixes coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/hw.c:1897:5-13: 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-5-zhengbin13@huawei.com
Change the misleading macro name to one that is more descriptive for
rtl8821ae. 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/20200831184536.29950-1-Larry.Finger@lwfinger.net
Fix the following coccicheck warning:
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c:79:1-34: WARNING:
Assignment of 0/1 to bool variable
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c:81:1-34: WARNING:
Assignment of 0/1 to bool variable
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Jason Yan <yanaijie@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200418070236.9620-6-yanaijie@huawei.com
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:142:17:
warning: cckswing_table_ch1ch13 defined but not used [-Wunused-const-variable=]
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:178:17:
warning: cckswing_table_ch14 defined but not used [-Wunused-const-variable=]
drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:96:18:
warning: ofdmswing_table defined but not used [-Wunused-const-variable=]
These variable is never used, so remove them.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Some of functions which were exposed in sw.h, are only used in sw.c, so
just make them static. This makes sw.h unnecessary, so remove it.
Signed-off-by: Amadeusz Sławiński <amade@asmblr.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Besides the previously changed macros for the RX and TX descriptors.
the local macros are used in other places. These are replaced with
standard bit manipulation macros.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
rf_lock is used to protect RF register access, but they will not called
from interrupt context, so *_irqsave version isn't necessary. Then, these
delays don't affect IRQ services.
The old code holds spin_lock_irqsave() that will be detected a long delay
as below:
kworker/-276 4d... 0us : _raw_spin_lock_irqsave
kworker/-276 4d... 0us : rtl8723_phy_rf_serial_read <-rtl8723de_phy_set_rf_reg
kworker/-276 4d... 1us : rtl8723_phy_query_bb_reg <-rtl8723_phy_rf_serial_read
kworker/-276 4d... 3us : rtl8723_phy_set_bb_reg <-rtl8723_phy_rf_serial_read
kworker/-276 4d... 4us : __const_udelay <-rtl8723_phy_rf_serial_read
kworker/-276 4d... 4us!: delay_mwaitx <-rtl8723_phy_rf_serial_read
kworker/-276 4d... 1004us : rtl8723_phy_set_bb_reg <-rtl8723_phy_rf_serial_read
[...]
Reported-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
