summaryrefslogtreecommitdiff
path: root/drivers/net/wireless/realtek
AgeCommit message (Collapse)Author
2023-09-07wifi: rtw89: 8922a: set memory heap address for secure firmwarePing-Ke Shih
Secure firmware is protected by public/private key cryptography. To help firmware self verify integrity, configure a heap address for these data before downloading firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-9-pkshih@realtek.com
2023-09-07wifi: rtw89: fw: refine download flow to support variant firmware suitsPing-Ke Shih
To support download more than one firmware, adjust flow to download firmware by unit of firmware suit. Then, flow becomes 1. initial setup - disable/enable_wcpu 2. for all firmware suits 2.1. download WiFi CPU, and check ready 2.2. download BB MCU, and check ready 3. check status code to make sure all ready Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-8-pkshih@realtek.com
2023-09-07wifi: rtw89: 8922a: add chip_ops::bb_preinit to enable BB before downloading ↵Ping-Ke Shih
firmware Before downloading firmware for BB MCU, call this ops to enable baseband hardware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-7-pkshih@realtek.com
2023-09-07wifi: rtw89: fw: propagate an argument include_bb for BB MCU firmwarePing-Ke Shih
Though WiFi 7 chips need BB MCU firmware, we don't download it in probe stage. Instead, only bring interface up under normal operation or WoWLAN mode. So, add an argument to assist download flow to setup download settings properly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-6-pkshih@realtek.com
2023-09-07wifi: rtw89: fw: add checking type for variant type of firmwarePing-Ke Shih
For WiFi 6 chips, there is only single one firmware i.e. WiFi CPU firmware, so no need an argument to discriminate them. For WiFi 7 chips, BB MCU firmware is introduced, and we need to check it ready after downloading. For each type of firmware, we need to check corresponding hardware ready bit. After downloading all firmware, check status code to determine if all things are ready. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-5-pkshih@realtek.com
2023-09-07wifi: rtw89: fw: implement supported functions of download firmware for WiFi ↵Ping-Ke Shih
7 chips To work with generalized flow of download firmware, implement WiFi 7 specific functions to support it. These functions include disable/enable WiFi CPU, status of path ready, and status of firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-4-pkshih@realtek.com
2023-09-07wifi: rtw89: fw: generalize download firmware flow by mac_gen pointersPing-Ke Shih
In order to reuse the flow to download firmware, define some mac_gen::ops to implement them for WiFi 6 and 7 chips individually. This doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-3-pkshih@realtek.com
2023-09-07wifi: rtw89: fw: move polling function of firmware path ready to an ↵Ping-Ke Shih
individual function To download firmware, we need to check path is ready. There are two kinds of path -- one is to download firmware header, and the other is to download firmware body. Since the polling method is different from WiFi 7 chips, make it to be an individual function, and then we can reuse the download flow. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-2-pkshih@realtek.com
2023-09-07wifi: rtw89: mcc: trigger FW to start/stop MCCZong-Zhe Yang
According to Wi-Fi/BT roles' settings, we fill corresponding H2Cs (host to chip packets). Then, following MCC (multi-channel concurrency) pattern, we send these H2Cs as planned. Eventually, the trigger H2Cs will be sent to tell FW to really start/stop MCC. 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/20230831053133.24015-7-pkshih@realtek.com
2023-09-07wifi: rtw89: fix typo of rtw89_fw_h2c_mcc_macid_bitmap()Zong-Zhe Yang
Fix a typo where `bitamp` should be `bitmap`. Don't change functionality at all. 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/20230831053133.24015-6-pkshih@realtek.com
2023-09-07wifi: rtw89: mcc: decide pattern and calculate parametersZong-Zhe Yang
After the previous works, we can now expand and display the MCC pattern in more detail, as shown below. |< MCC interval >| |< duration ref >| (if mid bt) |< duration aux >| (if tail bt) | |<tob ref >|< toa ref>| ... |<tob aux >|< toa aux>| ... | V V tbtt ref tbtt aux |< beacon offset >| (where tob means `time offset behind` and toa means `time offset ahead`) There are two key points. 1. decide position of BT slot if MCC pattern needs to handle BT duration. 2. calculate all parameters related to tob and toa in MCC pattern. For point (1), when BT duration needs to be handled, BT position will rely on beacon offset, either middle or tail. For point (2), to ensure durations of the Wi-Fi roles cover their beacons, we have to calculate tob and toa for them according to their TBTT. And, there are two strategies to calculate parameters, strict and loose. In strict pattern, all parameters take HW time into account as limitation. But, the strict calculation are not always successful. In loose pattern, it only tries to give positive parameters to reference role and doesn't care much about auxiliary role. If unfortunately auxiliary role gets negative parameters in loose pattern, FW will be notified and then deal with it. So, the loose calculation won't fail. In general, we always try strict pattern cases before using a loose pattern. 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/20230831053133.24015-5-pkshih@realtek.com
2023-09-07wifi: rtw89: mcc: consider and determine BT durationZong-Zhe Yang
Before calculating MCC pattern, we have to determine whether to handle BT duration in it or not. The decision will depend on the channels that Wi-Fi roles use. And, we have three cases shown below. 1. non-2GHz + non-2GHz 2. non-2GHz + 2GHz (different band) 3. 2GHz + 2GHz (dual 2GHz) For case (1), we don't care BT duration in MCC pattern. For case (2), we still don't care BT duration in MCC pattern. Instead, we try to satisfy it by modifying duration of Wi-Fi role on non-2GHz channel. For case (3), we need to modify Wi-Fi durations and also need to handle BT duration in MCC pattern. 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/20230831053133.24015-4-pkshih@realtek.com
2023-09-07wifi: rtw89: mcc: fill fundamental configurationsZong-Zhe Yang
We determine the fundamental settings shown below. |< MCC interval >| |< duration ref >|< duration aux >| | | | | |< beacon offset >| | | V V (tbtt ref) (tbtt aux) (where `ref` (reference) and `aux` (auxiliary) mean the two MCC roles) Based on MCC mode (GO+STA or GC+STA), we fill configurations of MCC interval and beacon offset. And, we make sure each MCC role have a basically required duration in the MCC interval. The beacon offset mentioned above is a parameter for further MCC pattern calculation. If MCC is in GC+STA mode, we will calculate the real beacon offset through TSFs shown in beacons of both MCC roles. Otherwise, we will use a default beacon offset, and make GO sync STA's TSF timer with this offset. MCC pattern calculation will break down each MCC role's duration in more detail. We will implement it in the following. 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/20230831053133.24015-3-pkshih@realtek.com
2023-09-07wifi: rtw89: mcc: initialize start flowZong-Zhe Yang
We prepare to support TDMA-based MCC (multi-channel concurrency) which allows two kinds of modes below. * P2P GO + normal STA * P2P GC + normal STA Each mode has two vif and two chanctx. Then, each vif binds one separate chanctx and becomes one MCC role. We name the two MCC roles as follows. * MCC role - reference (ref) We calculate the baseline of our TDMA things accodring to its info, e.g. TBTT. In normal case, it will be put at the first slot of TDMA. * MCC role - auxiliary (aux) MCC state machine will be running in FW eventually, but before that, we have to fill and calculate things that are needed by FW. We fill the information of MCC role according to its vif and its chanctx. Then, we calculate the start time for MCC. Note that the parameters used in the calculation now is assigned by default rules. The precise parameters for better MCC behavior will be derived in the following. 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/20230831053133.24015-2-pkshih@realtek.com
2023-09-04wifi: rtw89: 8852c: Fix TSSI causes transmit power inaccuracyKuan-Chung Chen
Modify TSSI ADC FIFO Clock follow RX ADC Clock can avoid transmit power inaccuracy. 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/20230830092849.153251-3-pkshih@realtek.com
2023-09-04wifi: rtw89: 8852c: Update bandedge parameters for better performanceKuan-Chung Chen
TSSI configures bandedge to TX proper waveform, these new bandedge parameters improve the accuracy of transmit power compensation. This helps to avoid throughput degradation. 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/20230830092849.153251-2-pkshih@realtek.com
2023-09-04wifi: rtl8xxxu: mark TOTOLINK N150UA V5/N150UA-B as testedZenm Chen
TOTOLINK N150UA V5/N150UA-B (VID=0x0bda, PID=0x2005) works fine with the rtl8xxxu driver, so mark as tested. Signed-off-by: Zenm Chen <zenmchen@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230829074358.14795-1-zenmchen@gmail.com
2023-09-04wifi: rtw88: fix typo rtw8822cu_probePo-Hao Huang
The probe function of 8822cu is misplaced to 8822bu, so we fix it. Just cosmetics, no changes in functionality. 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/20230825062404.50813-1-pkshih@realtek.com
2023-08-25wifi: rtlwifi: rtl8723: Remove unused function rtl8723_cmd_send_packet()Jinjie Ruan
The function rtl8723_cmd_send_packet() is not used anywhere, so remove it. Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230824062339.1885385-1-ruanjinjie@huawei.com
2023-08-25wifi: rtw88: usb: kill and free rx urbs on probe failureSascha Hauer
After rtw_usb_alloc_rx_bufs() has been called rx urbs have been allocated and must be freed in the error path. After rtw_usb_init_rx() has been called they are submitted, so they also must be killed. Add these forgotten steps to the probe error path. Besides the lost memory this also fixes a problem when the driver fails to download the firmware in rtw_chip_info_setup(). In this case it can happen that the completion of the rx urbs handler runs at a time when we already freed our data structures resulting in a kernel crash. Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Cc: stable@vger.kernel.org Reported-by: Ilgaz Öcal <ilgaz@ilgaz.gen.tr> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230823075021.588596-1-s.hauer@pengutronix.de
2023-08-25wifi: rtw89: Fix clang -Wimplicit-fallthrough in rtw89_query_sar()Nathan Chancellor
clang warns (or errors with CONFIG_WERROR=y): drivers/net/wireless/realtek/rtw89/sar.c:216:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough] 216 | case RTW89_TAS_STATE_DPR_FORBID: | ^ drivers/net/wireless/realtek/rtw89/sar.c:216:3: note: insert 'break;' to avoid fall-through 216 | case RTW89_TAS_STATE_DPR_FORBID: | ^ | break; 1 error generated. Clang is a little more pedantic than GCC, which does not warn when falling through to a case that is just break or return. Clang's version is more in line with the kernel's own stance in deprecated.rst, which states that all switch/case blocks must end in either break, fallthrough, continue, goto, or return. Add the missing break to silence the warning. Closes: https://github.com/ClangBuiltLinux/linux/issues/1921 Fixes: eb2624f55ad1 ("wifi: rtw89: Introduce Time Averaged SAR (TAS) feature") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822-rtw89-tas-clang-implicit-fallthrough-v1-1-5cb73f0fa976@kernel.org
2023-08-25wifi: rtw89: phy: modify register setting of ENV_MNTR, PHYSTS and DIGCheng-Chieh Hsieh
The ENV_MNTR(environment monitor) is the dynamic mechanism which based on the HW of CCX(Cisco Compatible Extensions) which provide the channel loading and noisy level indicator to debug or support the 802.11k. The PHYSTS provide the detail PHY information per packet we received for debugging. The DIG(dynamic initial gain) is the dynamic mechanism to adjust the packet detect power level by received signal strength to avoid false detection of the WiFi packet. The address of registers used for ENV_MNTR, PHYSTS and DIG of WiFi 7 IC are different with WiFi 6 series, so we modify the method to access the register address in order to compatible with all WiFi 7 and 6 ICs. Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@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/20230822125822.23817-7-pkshih@realtek.com
2023-08-25wifi: rtw89: phy: add phy_gen_def::cr_base to support WiFi 7 chipsPing-Ke Shih
cr_base is base address of PHY control register. The base of WiFi 6 and 7 chips are 0x1_0000 and 0x2_0000 respectively, so define them accordingly. For example, if PHY address is 0x1330, absolute address is 0x1_1330 for WiFi 6 chips, and 0x2_1330 for WiFi 7 chips. Meanwhile, there are two copies of PHY hardware named PHY0 and PHY1. The offset between them is 0x2_0000, so the base address of PHY0 and PHY1 are 0x2_0000 and 0x4_0000 respectively. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822125822.23817-6-pkshih@realtek.com
2023-08-25wifi: rtw89: mac: define register address of rx_filter to generalize codePing-Ke Shih
rx_filter is used to decide which kind of packets are received to driver, or just dropped by MAC layer to reduce bus traffic. The bit definitions of old and new chips are the sames, but only address is changed, so define a field to generalize usage. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822125822.23817-5-pkshih@realtek.com
2023-08-25wifi: rtw89: mac: define internal memory address for WiFi 7 chipPing-Ke Shih
Define base address of WiFi 7 internal memory according to design to provide the same functions as existing WiFi 6 chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822125822.23817-4-pkshih@realtek.com
2023-08-25wifi: rtw89: mac: generalize code to indirectly access WiFi internal memoryPing-Ke Shih
To diagnose abnormal behavior, we need to dump certain internal memory. For example, dump security CAM when debugging encryption/decryption problems, or dump BA CAM when debugging abnormal BlockAck. Since the indirect address and internal memory base address are different between WiFi 6 and 7 chips, add fields to reuse codes. Also, only WiFi 6 chips initialize DMAC and CMAC tables via this indirect interface, so no need to change the constant register address, and new firmware will help to initialize these tables. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822125822.23817-3-pkshih@realtek.com
2023-08-25wifi: rtw89: mac: add mac_gen_def::band1_offset to map MAC band1 register ↵Ping-Ke Shih
address There are two copies of MAC hardware called band0 and band1. Basically, the only difference between them is base address, so we can share functions with a 'band' (or 'mac_idx') argument. The offset of base address of WiFi 6 and 7 are 0x2000 and 0x4000 respectively, so add band1_offset field to new introduced struct mac_gen_def to possibly reuse functions. Using below spatch script to convert callers: @@ expression reg, band; @@ - rtw89_mac_reg_by_idx(reg, band) + rtw89_mac_reg_by_idx(rtwdev, reg, band) @@ expression reg, port, band; @@ - rtw89_mac_reg_by_port(reg, port, band) + rtw89_mac_reg_by_port(rtwdev, reg, port, band) Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230822125822.23817-2-pkshih@realtek.com
2023-08-25wifi: rtw89: initialize multi-channel handlingZong-Zhe Yang
We prepare to deal with multiple channels via new entity modes. * MCC_PREPARE: Transitional mode before MCC * MCC: Multi-Channel Concurrent mode And, enum of sub-entity is extended for second channel context. We add the entry flow of multi-channel handling and the core stuffs for extended index of sub-entity. And, we now deal with the filling of entity channels' info in entity recalc where we know the number of active chanctx. However, the other detail coding of MCC start/stop will be implemented in the following. Besides, chanctx listener struct is pre-added in chip info. Each component can add callback type in chanctx listener and configure its callback function to react according to chanctx states. We know at least RFK (RF calibration) and BTC (BT coexistence) will require such callbacks. 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/20230816082133.57474-7-pkshih@realtek.com
2023-08-25wifi: rtw89: provide functions to configure NoA for beacon updateZong-Zhe Yang
Callers call renew function when wanting to generate a new P2P NoA information element, and call append function to append NoA attribute one by one. Then, updating beacon work will fetch the P2P NoA information element configured by callers and add it to beacon. The use case of MCC (multi-channel concurrent) <GO + STA> for example: * start MCC - GO part renew P2P NoA append period NoA after calculation * download beacon for GO fetch P2P NoA and add to beacon content * stop MCC - GO part renew P2P NoA (reset) 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/20230816082133.57474-6-pkshih@realtek.com
2023-08-25wifi: rtw89: call rtw89_chan_get() by vif chanctx if aware of vifZong-Zhe Yang
We adjust these processes which can work accodrding to vif but call rtw89_chan_get() with static RTW89_SUB_ENTITY_0. After multi-channel support, chanctx of vif won't always be on RTW89_SUB_ENTITY_0. So, we make them call rtw89_chan_get() with rtwvif->sub_entity_idx. 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/20230816082133.57474-5-pkshih@realtek.com
2023-08-25wifi: rtw89: sar: let caller decide the center frequency to queryZong-Zhe Yang
If multiple channels, SAR will be hard to determine the center frequency to query. Therefore, we move this decision out of SAR. 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/20230816082133.57474-4-pkshih@realtek.com
2023-08-25wifi: rtw89: refine rtw89_correct_cck_chan() by rtw89_hw_to_nl80211_band()Zong-Zhe Yang
In rtw89_correct_cck_chan(), we turn to use rtw89_hw_to_nl80211_band(). The difference between rtw89_hw_to_nl80211_band() and the original raw judgement is the case on 6 GHz. Since rtw89_correct_cck_chan() is common code independent on chip, if runtime chip doesn't support 6 GHz, it is probably safe. Otherwise, it might not. 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/20230816082133.57474-3-pkshih@realtek.com
2023-08-25wifi: rtw89: add function prototype for coex request durationZong-Zhe Yang
The request duration comes from coex mechanism, indicating the length of time that should be reserved for BT in each time division. It is required to handle update notification when channel concurrency processes. Since it will involve in both coex and wifi code flow, this commit ahead adds the prototype for required function interfaces to split the implementation of coex and wifi in the following. The follow-up are expected be add afterwards. 1. coex mechanism call rtw89_core_ntfy_btc_event() once bt req len changes 2. channel concurrency flow updates related stuffs when notified 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/20230816082133.57474-2-pkshih@realtek.com
2023-08-25Fix nomenclature for USB and PCI wireless devicesAlan Stern
A mouse that uses a USB connection is called a "USB mouse" device (or "USB mouse" for short), not a "mouse USB" device. By analogy, a WiFi adapter that connects to the host computer via USB is a "USB wireless" device, not a "wireless USB" device. (The latter term more properly refers to a defunct Wireless USB specification, which described a technology for sending USB protocol messages over an ultra wideband radio link.) Similarly for a WiFi adapter card that plugs into a PCIe slot: It is a "PCIe wireless" device, not a "wireless PCIe" device. Rephrase the text in the kernel source where the word ordering is wrong. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/57da7c80-0e48-41b5-8427-884a02648f55@rowland.harvard.edu
2023-08-21wifi: rtw89: regd: update regulatory map to R64-R43Zong-Zhe Yang
Sync Realtek Regulatory R43 and Realtek Channel Plan R64. 1. add entry for XK (Kosovo) 2. change TH (Thailand) to Realtek regd world-wide 3. configures Realtek 6 GHz regd for below countries * AR, MX, HT -> FCC * LB, ZA, BF, LA, MN -> ETSI 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/20230815120253.9901-1-pkshih@realtek.com
2023-08-21wifi: rtw89: fix a width vs precision bugDan Carpenter
The "buf" is skb->data that comes from the firmware. We want to print "len" number of bytes. But there is a missing period so the "len" variable is used for formatting (width) instead of limiting the output (precision). Fixes: cad2bd8a136c ("wifi: rtw89: support firmware log with formatted text") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/0700c7b9-bfd3-4aa6-82bf-5bf3c74644e1@moroto.mountain
2023-08-21wifi: rtlwifi: use eth_broadcast_addr() to assign broadcast addressYang Yingliang
Use eth_broadcast_addr() to assign broadcast address instead of memcpy(). 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/20230804090120.1332091-1-yangyingliang@huawei.com
2023-08-21wifi: rtw89: Introduce Time Averaged SAR (TAS) featureKuan-Chung Chen
Time Averaged SAR (TAS) tracks the amount of transmit power over a period of time and adjusts the power accordingly. Two thresholds are used to determine when to increase or reduce transmit power: Dynamic Power Reduction (DPR) on/off. Compared to Static SAR, which has a constant transmit power, TAS can improve the user experience or range extension. TAS can be enabled through BIOS, and the driver will evaluate Realtek ACPI DSM with RTW89_ACPI_DSM_FUNC_TAS_EN to determine whether TAS should be enabled. 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/20230804053458.31492-1-pkshih@realtek.com
2023-08-21wifi: rtw89: 8852b: rfk: fine tune IQK parameters to improve performance on ↵Ping-Ke Shih
2GHz band A few samples get bad performance on 2GHz band, so use proper IQK command code and select another group to have wider range of calibration value. Fixes: f2abe804e823 ("wifi: rtw89: 8852b: rfk: add IQK") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230803110150.8457-1-pkshih@realtek.com
2023-08-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR. No conflicts. Adjacent changes: drivers/net/ethernet/intel/igc/igc_main.c 06b412589eef ("igc: Add lock to safeguard global Qbv variables") d3750076d464 ("igc: Add TransmissionOverrun counter") drivers/net/ethernet/microsoft/mana/mana_en.c a7dfeda6fdec ("net: mana: Fix MANA VF unload when hardware is unresponsive") a9ca9f9ceff3 ("page_pool: split types and declarations from page_pool.h") 92272ec4107e ("eth: add missing xdp.h includes in drivers") net/mptcp/protocol.h 511b90e39250 ("mptcp: fix disconnect vs accept race") b8dc6d6ce931 ("mptcp: fix rcv buffer auto-tuning") tools/testing/selftests/net/mptcp/mptcp_join.sh c8c101ae390a ("selftests: mptcp: join: fix 'implicit EP' test") 03668c65d153 ("selftests: mptcp: join: rework detailed report") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-08wifi: rtw89: fix 8852AE disconnection caused by RX full flagsPing-Ke Shih
RX full flags are raised if certain types of RX FIFO are full, and then drop all following MPDU of AMPDU. In order to resume to receive MPDU when RX FIFO becomes available, we clear the register bits by the commit a0d99ebb3ecd ("wifi: rtw89: initialize DMA of CMAC"). But, 8852AE needs more settings to support this. To quickly fix disconnection problem, revert the behavior as before. Fixes: a0d99ebb3ecd ("wifi: rtw89: initialize DMA of CMAC") Reported-by: Damian B <bronecki.damian@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217710 Cc: <Stable@vger.kernel.org> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Tested-by: Damian B <bronecki.damian@gmail.com> Link: https://lore.kernel.org/r/20230808005426.5327-1-pkshih@realtek.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-08-03wifi: rtw89: return failure if needed firmware elements are not recognizedPing-Ke Shih
WiFi 7 chips doesn't have static const tables defined in driver. If tables aren't loaded properly from firmware file, driver can get NULL pointer access exception. One way is to add the checking statements when trying to access these tables, but I choose to check them right after loading firmware elements from firmware file, so I don't need to add error handlers everywhere. Currently, the needed firmware elements of WiFi 6 chips are all zero, and coming WiFi 7 chip will need at least BB MCU, parameters of BB and RF. We will add them after 8922AE is verified. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-9-pkshih@realtek.com
2023-08-03wifi: rtw89: add to parse firmware elements of BB and RF tablesPing-Ke Shih
The tables of BB and RF parameters are pairs of {addr, value}. Load them and convert from little-endian to CPU order, and show the version to clear which version we are using. rtw89_8922ae 0000:03:00.0: Firmware element BB version: 00 04 00 00 rtw89_8922ae 0000:03:00.0: Firmware element radio A version: 00 13 00 00 rtw89_8922ae 0000:03:00.0: Firmware element NCTL version: 00 05 00 00 We use tables defined in firmware elements with higher priority than original static const tables defined in driver, because WiFi 7 chips will not define the tables in driver, and existing chips can possibly migrate to the new design one by one. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-8-pkshih@realtek.com
2023-08-03wifi: rtw89: introduce infrastructure of firmware elementsPing-Ke Shih
In order to pack more data into firmware file, we introduce firmware elements and append BB_MCU firmware first. The first part of new firmware file is still unchanged firmware of WiFi CPU, so the new firmware format can be backward compatible to old format. The new elements part consists of ID and size basically, which can append more elements simply. To avoid unaligned access in certain platform and be easy to read, headers of all elements start at 16-byte aligned address. +===========================================+ | original firmware | | +-------------+ | | padding | +===========================================+ | elm ID 1 | elm size | other header data | +----------+----------+ | | | +-------------------------------------------+ | content (variable length) | | +-------------+ | | padding | +===========================================+ | elm ID 2 | elm size | other header data | +----------+----------+ | | | +-------------------------------------------+ | content (variable length) | | +-----------------------+ | | (no padding for the last one) +===================+ More detail of element header is shown below. The additional fields 'version' and 'element_priv[]' are meta data of elements, so that we can know element version easily, and element_priv[] provide specific fields for certain element, such as RF path index for RF parameter tables. +===========================================+ | elm ID | elm size | version | rsvd0 | +----------+----------+----------+----------+ | rsvd1/2 | element_priv[] | +-------------------------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-7-pkshih@realtek.com
2023-08-03wifi: rtw89: add firmware suit for BB MCU 0/1Ping-Ke Shih
For existing chips, firmware is only for WiFi CPU, but WiFi 7 chips add new hardware component BB MCU that needs firmware as well. The firmwares of BB MCU 0/1 are also downloaded via the same path like WiFi CPU firmware, and use the same firmware header format, so add firmware suits to access them commonly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-6-pkshih@realtek.com
2023-08-03wifi: rtw89: add firmware parser for v1 formatPing-Ke Shih
A firmware with v1 format contains many sections to download. Add parser to read section type, target address, length, checksum and so on, and then download the section to WiFi CPU with proper location. The additional dynamic header length named dynamic_hdr_len is used to skip content of dynamic header containing compiler flags of firmware, which can help to determine variant firmware build, but currently rtw89 only use single one variant. So, just skip the content. The layout of a WiFi CPU firmware with v1 format looks like: +---------------------------------------+ | Header (12 words) | +---------------------------------------+ | Section header 1 (4 words) | | Section header 2 (4 words) | | Section header 3 (4 words) | | ... | +---------------------------------------+ | Dynamic header (variable length) | +---------------------------------------+ | Data used & pointed by section | | ... | +---------------------------------------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-5-pkshih@realtek.com
2023-08-03wifi: rtw89: introduce v1 format of firmware headerPing-Ke Shih
New firmware header is used by upcoming WiFi 7 chips to have more information, so use common field w3[31:24] to determine header version, and then use corresponding function to read firmware version and commit ID: rtw89_8852be 0000:03:00.0: Firmware version 0.29.29.1 (799134c3), cmd version 1, type 5 rtw89_8852be 0000:03:00.0: Firmware version 0.29.29.1 (799134c3), cmd version 1, type 3 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230801021127.15919-4-pkshih@realtek.com
2023-08-03wifi: rtw89: support firmware log with formatted textChin-Yen Lee
Original firmware log which is sent via C2H message bloats code size of firmware and is also length-limited. So we put some common log into format file, and firmware could use a log ID and some variables in C2H message to map a formatted text via pre-designed rule. Signed-off-by: Chin-Yen Lee <timlee@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/20230801021127.15919-3-pkshih@realtek.com
2023-08-03wifi: rtw89: recognize log format from firmware fileChin-Yen Lee
Firmware log format is an element of multi-firmware file and used for firmware to provide log with formatted text. Driver needs to recognize it in advance if it exists. Signed-off-by: Chin-Yen Lee <timlee@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/20230801021127.15919-2-pkshih@realtek.com
2023-08-01wifi: rtw89: get data rate mode/NSS/MCS v1 from RX descriptorPing-Ke Shih
The data rate from RX descriptor also uses hardware rate v1 for WiFi 7 chips. The rate code contains three parts -- mode, NSS and MCS. For CCK/OFDM/HT rates, NSS/MCS parts are the same as before. VHT/HE/EHT rates are changed and listed as below: mode NSS MCS V0 [8:7] [6:4] [3:0] V1 [10:8] [7:5] [4:0] Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-11-pkshih@realtek.com
generated by cgit (git 2.34.1) at 2025-09-23 14:57:51 +0000