- 13 Apr, 2022 3 commits
-
-
Ping-Ke Shih authored
Add to configure security CAM while mac80211 calls set_key and del_key. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220413010804.8941-4-pkshih@realtek.com
-
Ping-Ke Shih authored
DCTL is short for D-MAC control that V1 chip uses this H2C to configure security CAM. Implement the callers in next patch. Signed-off-by:
-
Ping-Ke Shih authored
In order to support new chip that has capability of 160M, we need new format to fill new information, so add a new V1 ID for newer use. Since most fields are the same, fill fields according to the function ID of chip. Signed-off-by:
-
- 12 Apr, 2022 22 commits
-
-
Kalle Valo authored
This is an immutable branch shared between wireless-next and staging-next for moving wfx driver out of staging to drivers/net/wireless directory.
-
Lv Ruyi authored
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:
-
Lv Ruyi authored
There are some spelling mistakes in the comments. Fix it. Reported-by:
-
Minghao Chi authored
Using pm_runtime_resume_and_get is more appropriate for simplifing code Reported-by:
Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by:
-
Jimmy Hon authored
Make workaround work for other 8821CE devices with different PCI ID Signed-off-by:
Jimmy Hon <honyuenkwun@gmail.com> Reviewed-by:
-
Jimmy Hon authored
New device ID 0xb821 found on TP-Link T2E Tested it with c821 driver. 2.4GHz and 5GHz works. PCI id: 05:00.0 Network controller: Realtek Semiconductor Co., Ltd. Device b821 Subsystem: Realtek Semiconductor Co., Ltd. Device b821 Signed-off-by: -
Po-Hao Huang authored
RSSI value per frame is reported to mac80211 but not maintained in our own statistics, add it back to help us debug. Signed-off-by:
Po-Hao Huang <phhuang@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
Calling calibration to yield expected PHY performance. We do this in STA mode, so do this in AP mode as well. Signed-off-by:
-
Po-Hao Huang authored
Without this setting, hardware would not report to driver even if management frames are transmitted successfully. So we fix it. Signed-off-by:
-
Po-Hao Huang authored
To support stations in power saving mode, AP should notify stations that there are frames buffered at the AP via TIM during beacons. Driver used to transmit identical beacons that were downloaded to hardware during the initiation phase. This beacon will become obsolete over time. If the beacon does not contain sufficient information, station would not be able to percept that there is data to receive. Hence it won't wake up and start the PS-poll procedure, this could lead to timeout and/or lost data segments. In order to resolve this issue, driver will now download beacon to hardware whenever the content is updated. Enable hardware to update dtim_count for more efficiency, this reduces the overhead of downloading beacon at every beacon interval since most of the time only the dtim_count needs to be updated. Change queue mapping for broadcast/multicast frames to high queue, so these frames can be prioritized and sent when dtim_count is zero. Signed-off-by:
-
Po-Hao Huang authored
We should only fill in frequency reported by firmware during scan. Add this so frames won't be dropped by mac80211 due to frequency mismatch. Signed-off-by:
-
Po-Hao Huang authored
Adding this allows us to get notification when bitrate configuration of the station changes. Update according parameters to firmware so the rate control algorithm can work properly. Signed-off-by:
-
Joe Perches authored
Change the struct and the uses to const to reduce data. $ size drivers/net/wireless/realtek/rtw89/ser.o* (x86-64 defconfig w/ rtw89) text data bss dec hex filename 3741 8 0 3749 ea5 drivers/net/wireless/realtek/rtw89/ser.o.new 3437 312 0 3749 ea5 drivers/net/wireless/realtek/rtw89/ser.o.old Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
-
Chia-Yuan Li authored
Initialize registers to default values, such as PTA and GNT pin, and set pin MUX according to number of antenna on hardware module. Signed-off-by:
Chia-Yuan Li <leo.li@realtek.com> Signed-off-by:
-
Johnson Lin authored
Separated DIG RX gain, IGI configurations from not supportted HW using "support_igi" capability flag. Signed-off-by:
Johnson Lin <johnson.lin@realtek.com> Signed-off-by:
-
Chia-Yuan Li authored
Disable watchdog timer to prevent it timeout suddenly. Signed-off-by:
-
Ping-Ke Shih authored
BA CAM is used to react receiving AMPDU packets, so reset them to be expected initial state. Signed-off-by:
-
Ping-Ke Shih authored
The bit B_AX_SS_NONEMPTY_SS2FINFO_EN should be clear, because we configure C-MAC as hardware TX/RX mode. Signed-off-by:
-
Ping-Ke Shih authored
Turn on ERR IMR, and then firmware can capture interrupts reflecting errors to recover hardware states. Signed-off-by:
-
Chia-Yuan Li authored
Similarly, create functions to set specific C-MAC masks for firmware recovery. Signed-off-by:
-
Chia-Yuan Li authored
These interrupts are used by firmware to recover hardware. Create functions to set specific D-MAC masks to replace plain register settings. Signed-off-by:
-
Zong-Zhe Yang authored
add `break` to fix warning of unannotated fall-through between switch labels. Fixes: 14f9f479 ("rtw89: ser: control hci interrupts on/off by state") Signed-off-by:
Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by:
-
- 11 Apr, 2022 6 commits
-
-
Sriram R authored
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>
-
Peter Seiderer authored
Using an ath9k card the debugfs output of minstrel_ht looks like the following (note the zero values for the first four rates sum-of success/attempts): best ____________rate__________ ____statistics___ _____last____ ______sum-of________ mode guard # rate [name idx airtime max_tp] [avg(tp) avg(prob)] [retry|suc|att] [#success | #attempts] OFDM 1 DP 6.0M 272 1640 5.2 3.1 53.8 3 0 0 0 0 OFDM 1 C 9.0M 273 1104 7.7 4.6 53.8 4 0 0 0 0 OFDM 1 B 12.0M 274 836 10.0 6.0 53.8 4 0 0 0 0 OFDM 1 A S 18.0M 275 568 14.3 8.5 53.8 5 0 0 0 0 OFDM 1 S 24.0M 276 436 18.1 0.0 0.0 5 0 1 80 1778 OFDM 1 36.0M 277 300 24.9 0.0 0.0 0 0 1 0 107 OFDM 1 S 48.0M 278 236 30.4 0.0 0.0 0 0 0 0 75 OFDM 1 54.0M 279 212 33.0 0.0 0.0 0 0 0 0 72 Total packet count:: ideal 16582 lookaround 885 Average # of aggregated frames per A-MPDU: 1.0 Debugging showed that the rate statistics for the first four rates where stored in the MINSTREL_CCK_GROUP instead of the MINSTREL_OFDM_GROUP because in minstrel_ht_get_stats() the supported check was not honoured as done in various other places, e.g net/mac80211/rc80211_minstrel_ht_debugfs.c: 74 if (!(mi->supported[i] & BIT(j))) 75 continue; With the patch applied the output looks good: best ____________rate__________ ____statistics___ _____last____ ______sum-of________ mode guard # rate [name idx airtime max_tp] [avg(tp) avg(prob)] [retry|suc|att] [#success | #attempts] OFDM 1 D 6.0M 272 1640 5.2 5.2 100.0 3 0 0 1 1 OFDM 1 C 9.0M 273 1104 7.7 7.7 100.0 4 0 0 38 38 OFDM 1 B 12.0M 274 836 10.0 9.9 89.5 4 2 2 372 395 OFDM 1 A P 18.0M 275 568 14.3 14.3 97.2 5 52 53 6956 7181 OFDM 1 S 24.0M 276 436 18.1 0.0 0.0 0 0 1 6 163 OFDM 1 36.0M 277 300 24.9 0.0 0.0 0 0 1 0 35 OFDM 1 S 48.0M 278 236 30.4 0.0 0.0 0 0 0 0 38 OFDM 1 S 54.0M 279 212 33.0 0.0 0.0 0 0 0 0 38 Total packet count:: ideal 7097 lookaround 287 Average # of aggregated frames per A-MPDU: 1.0 Signed-off-by:Peter Seiderer <ps.report@gmx.net> Link: https://lore.kernel.org/r/20220404165414.1036-1-ps.report@gmx.netSigned-off-by:
-
Johannes Berg authored
There's no real reason not to send the SSID to userspace when it requests information about P2P_GO, it is, in that respect, exactly the same as AP interfaces. Fix that. Fixes: 44905265 ("nl80211: don't expose wdev->ssid for most interfaces") Signed-off-by:
-
Lorenzo Bianconi authored
Add ieee80211_rx_check_bss_color_collision routine in order to introduce BSS color collision detection in mac80211 if it is not supported in HW/FW (e.g. for mt7915 chipset). Add IEEE80211_HW_DETECTS_COLOR_COLLISION flag to let the driver notify BSS color collision detection is supported in HW/FW. Set this for ath11k which apparently didn't need this code. Tested-by:
Peter Chiu <Chui-Hao.Chiu@mediatek.com> Co-developed-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/a05eeeb1841a84560dc5aaec77894fcb69a54f27.1648204871.git.lorenzo@kernel.org [clarify commit message a bit, move flag to mac80211] Signed-off-by:
-
Toke Høiland-Jørgensen authored
The comment above the ieee80211_tx_info_clear_status() helper was somewhat confusing as to which fields it was or wasn't clearing. So replace it by something that is hopefully more, well, clear. Signed-off-by:
Toke Høiland-Jørgensen <toke@toke.dk> Link: https://lore.kernel.org/r/20220404210108.2684907-1-toke@toke.dkSigned-off-by:
-
Lorenzo Bianconi authored
Even if it is not a real issue since ieee80211_set_after_csa_beacon() or ieee80211_set_after_color_change_beacon() are run only when csa or bcc is active, move next_beacon check before running ieee80211_assign_beacon routine. Signed-off-by:
-
- 06 Apr, 2022 9 commits
-
-
Meng Tang authored
Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR, which makes the code a bit shorter and easier to read. Signed-off-by:
Meng Tang <tangmeng@uniontech.com> Signed-off-by:
-
Christophe Leroy authored
powerpc's asm/prom.h brings some headers that it doesn't need itself. In order to clean it up, first add missing headers in users of asm/prom.h Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
-
Haowen Bai authored
crypt and crypt->ops could be null, so we need to checking null before dereference Signed-off-by:
Haowen Bai <baihaowen@meizu.com> Signed-off-by:
-
Haowen Bai authored
fix warning reported by smatch: drivers/net/wireless/broadcom/b43/phy_n.c:585 b43_nphy_adjust_lna_gain_table() warn: assigning (-2) to unsigned variable '*(lna_gain[0])' Signed-off-by:
-
Haowen Bai authored
fix warning reported by smatch: drivers/net/wireless/broadcom/b43legacy/phy.c:1181 b43legacy_phy_lo_b_measure() warn: assigning (-772) to unsigned variable 'fval' Signed-off-by:
-
Chris Chiu authored
RTL8188CUS/RTL8192CU(gen1) don't support rate adaptive report hence no real txrate info can be retrieved. The vendor driver reports the highest rate in HT capabilities from the IEs to avoid empty txrate. This commit initiates the txrate information with the highest supported rate negotiated with AP. The gen2 chip keeps update the txrate from the rate adaptive reports, and gen1 chips at least have non-NULL txrate after associated. Signed-off-by:
Chris Chiu <chris.chiu@canonical.com> Signed-off-by:
-
Chris Chiu authored
Fill up the available TX/RX antenna so the iw commands can show correct antenna information for different chips. Signed-off-by:
-
Jakob Koschel authored
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:
-
Ulf Hansson authored
Keeping the power to the SDIO card during system wide suspend, consumes energy. Especially on battery driven embedded systems, this can be a problem. Therefore, let's change the behaviour into allowing the SDIO card to be powered off, unless WOWL is supported and enabled. Note that, the downside from this change, is that during system resume the SDIO card needs to be re-initialized and the FW must be re-programmed. Even if this may take some time to complete, it should we worth it, rather than draining the battery. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Tested-by:
Christophe Roullier <christophe.roullier@foss.st.com> Reviewed-by:
Yann Gautier <yann.gautier@foss.st.com> Signed-off-by:
-
