When the driver fails at ieee80211_alloc_hw() at the probe time, the
driver will free the 'hw' which is not allocated, causing a bug.
The following log can reveal it:
[ 15.981294] BUG: KASAN: user-memory-access in mutex_is_locked+0xe/0x40
[ 15.981558] Read of size 8 at addr 0000000000001ab0 by task modprobe/373
[ 15.982583] Call Trace:
[ 15.984282] ieee80211_free_hw+0x22/0x390
[ 15.984446] rtl8xxxu_probe+0x3a1/0xab30 [rtl8xxxu]
Fix the bug by changing the order of the error handling.
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220716130444.2950690-1-zheyuma97@gmail.com
When calling start/stop_ap(), mac80211 already has a protected
link_conf pointer. Pass it to the driver, so it shouldn't
handle RCU protection.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
TX BD (TX ring index) and TX WD (WiFi descriptor buffer) are freed
asynchronously. With burst packets, we free TX WD, but the corresponding
TX BD couldn't be freed yet. Then, TX can possibly get stuck due to no
more TX BD.
To avoid this, ignore reclaiming TX BD only if TX WD is no free space,
because at this moment TX BD must have some spaces. Otherwise, we reclaim
TX BD to resolve TX stuck issue.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-11-pkshih@realtek.com
In low power mode, regular IO is power off, so we don't schedule napi to
poll RX and TX completion. Therefore, calling ieee80211_rx_napi() with
napi instance causes long RX latency. To fix this, use NULL as argument,
and then it can use netif_receive_skb_list() to receive.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-10-pkshih@realtek.com
Some warning messages could bother users. With proper handling, these
situations don't really affect usage, but we still need to keep monitor
these messages. If they happen frequently, we must review driver or
hardware design to clarify.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-8-pkshih@realtek.com
To improve VO throughput, we enable VO TX AMPDU.
We measure the latency of enable or disable VO TX AMPDU. The experimental
results show that the difference between the two is insignificant only
300µs, so the little impact can be ignored for user experience.
Moreover, we found some APs will have a group key handshake timeout issue
when the EAPOL's TID is already setup BA session. Therefore, when
transmitting EAPOL, if EAPOL's TID BA session is already setup, we need
to delete it.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220610072610.27095-7-pkshih@realtek.com
Pass the link id through to the get_beacon and return
the beacon for a specific link id.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Start making some SMPS related code MLD-aware. This isn't
really done yet, but again cuts down our 'deflink' reliance.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Split the bss_info_changed method to vif_cfg_changed and
link_info_changed, with the latter getting a link ID.
Also change the 'changed' parameter to u64 already, we
know we need that.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg says:
====================
wireless-next patches for v5.20
Here's a first set of patches for v5.20. This is just a
queue flush, before we get things back from net-next that
are causing conflicts, and then can start merging a lot
of MLO (multi-link operation, part of 802.11be) code.
Lots of cleanups all over.
The only notable change is perhaps wilc1000 being the
first driver to disable WEP (while enabling WPA3).
* tag 'wireless-next-2022-06-10' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (29 commits)
wifi: mac80211_hwsim: Directly use ida_alloc()/free()
wifi: mac80211: refactor some key code
wifi: mac80211: remove cipher scheme support
wifi: nl80211: fix typo in comment
wifi: virt_wifi: fix typo in comment
rtw89: add new state to CFO state machine for UL-OFDMA
rtw89: 8852c: add trigger frame counter
ieee80211: add trigger frame definition
wifi: wfx: Remove redundant NULL check before release_firmware() call
wifi: rtw89: support MULTI_BSSID and correct BSSID mask of H2C
wifi: ray_cs: Drop useless status variable in parse_addr()
wifi: ray_cs: Utilize strnlen() in parse_addr()
wifi: rtw88: use %*ph to print small buffer
wifi: wilc1000: add IGTK support
wifi: wilc1000: add WPA3 SAE support
wifi: wilc1000: remove WEP security support
wifi: wilc1000: use correct sequence of RESET for chip Power-UP/Down
wifi: rtlwifi: fix error codes in rtl_debugfs_set_write_h2c()
wifi: rtw88: Fix Sparse warning for rtw8821c_hw_spec
wifi: rtw88: Fix Sparse warning for rtw8723d_hw_spec
...
====================
Link: https://lore.kernel.org/r/20220610142838.330862-1-johannes@sipsolutions.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The BSSID mask of H2C is used to match BSSID of receiving packets.
Normally, we set six bits BSSID mask to exactly match BSSID of packets
sent by target AP. After we support multiple BSSID, it could connect a
nontransmitted BSSID, so we can only match first five bytes of BSSID.
That means we could possibly receive other AP's packets if only the last
byte of BSSID is different from target AP.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220530112743.106857-1-pkshih@realtek.com
If the copy_from_user() fails or the user gives invalid date then the
correct thing to do is to return a negative error code. (Currently it
returns success).
I made a copy additional related cleanups:
1) There is no need to check "buffer" for NULL. That's handled by
copy_from_user().
2) The "h2c_len" variable cannot be negative because it is unsigned
and because sscanf() does not return negative error codes.
Fixes: 610247f46f ("rtlwifi: Improve debugging by using debugfs")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/YoOLnDkHgVltyXK7@kili
Sparse lists the following:
CHECK drivers/net/wireless/realtek/rtw88/rtw8821c.c
drivers/net/wireless/realtek/rtw88/rtw8821c.c:1880:22: warning: symbol 'rtw8821c_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8821c_hw_spec
occurs in rtw8821ce.h, which is not included in rtw8821c.h. That line is
moved, and the now empty file rtw8821ce.h is deleted.
Symbol 'rtw8821c_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153716.20450-1-Larry.Finger@lwfinger.net
Sparse lists the following:
CHECK drivers/net/wireless/realtek/rtw88/rtw8723d.c
drivers/net/wireless/realtek/rtw88/rtw8723d.c:2704:22: warning: symbol 'rtw8723d_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8723d_hw_spec
occurs in rtw8723de.h, which is not included in rtw8723d.h. That line is
moved, and the now empty file rtw8723de.h is deleted.
Symbol 'rtw8723d_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153621.19027-4-Larry.Finger@lwfinger.net
Sparse reports the following:
CHECK drivers/net/wireless/realtek/rtw88/rtw8822c.c
drivers/net/wireless/realtek/rtw88/rtw8822c.c:5313:22: warning: symbol 'rtw8822c_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8822c_hw_spec
occurs in rtw8822ce.h, which is not included in rtw8822c.h. That line is
moved, and the now empty file rtw8822ce.h is deleted.
Symbol 'rtw8822c_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153621.19027-3-Larry.Finger@lwfinger.net
Sparse lists the following for rtw88:
CHECK drivers/net/wireless/realtek/rtw88/rtw8822b.c
drivers/net/wireless/realtek/rtw88/rtw8822b.c:2500:22: warning: symbol 'rtw8822b_hw_spec' was not declared. Should it be static?
The warning arises because the external declaration for rtw8822b_hw_spec
occurs in rtw8822be.h, which is not included in rtw8822b.h. That line is
moved, and the now empty file rtw8822be.h is deleted.
Symbol 'rtw8822b_hw_spec' can be made constant.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220524153621.19027-2-Larry.Finger@lwfinger.net
Add this check to avoid crash by dereferencing a null pointer. When hwscan
fails due to no memory or dma failure, the scan flag in ieee80211_local is
cleared. So mac80211 determine that it's not hw_scan then calls
sw_scan_complete() with null vif, which is also freed during the fail.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220520081523.45987-1-pkshih@realtek.com
Since SAR is more expected to follow U-NII bands to plan subbands,
division of 6GHz band is quite different from defined enum of subbands
which is used by PHY in most cases. It's hard and painful if we want to
keep using the same enum on SAR. So, we introduce another enum for SAR
subbands and adjust SAR flow to use it.
Besides, since 6GHz SAR subbands won't be divided with edge alignment,
some cases will span two SAR subbands. For these cases, we describe them
within an array of rtw89_sar_span and take the smaller one between SAR
settings of the two subbands.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220520071731.38563-6-pkshih@realtek.com
Add this check to avoid crash by dereferencing a null pointer. When hwscan
fails due to no memory or dma failure, the scan flag in ieee80211_local is
cleared. So mac80211 determine that it's not hw_scan then calls
sw_scan_complete() with null vif, which is also freed during the fail.
Signed-off-by: Po Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220520071731.38563-3-pkshih@realtek.com
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>
The design of INT indicator register (R_AX_PCIE_HIMR00_V1) is to reduce IO
during frequent interrupts, because it can stop chip sending interrupt to
host if we just set this indicator to 0, not all IMR(s). This indicator
register looks like a root interrupt controller of wifi chip.
However, we can't set all other IMR(s) to 0 during we are running on
interrupt service routine, or the indicator register can't reflect the
status of certain interrupt happened during this period, and then miss
some interrupts especially SER interrupt events.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220516005215.5878-7-pkshih@realtek.com
