kernel/drivers/net/wireless/realtek/rtw89/mac.c, branch linux-6.2.y

wifi: rtw89: add join info upon create interface

2022-12-08T14:47:59Z

To support multiple vifs, fw need more information of each role. Send this info to make things work as expected. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221202061527.505668-5-pkshih@realtek.com

wifi: rtw89: stop mac port function when stop_ap()

2022-12-08T14:47:58Z

Disable hardware beacon related functions when ap stops. So hardware won't transmit beacons while interface is already removed. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221202061527.505668-3-pkshih@realtek.com

wifi: rtw89: add mac TSF sync function

2022-12-08T14:47:58Z

If the interface is in AP/P2P GO mode, we adjust the TSF with random offset to avoid TBTT of different vifs to overlap and collide. For every new interface added, we adjust the value and resync for all interfaces. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221202061527.505668-2-pkshih@realtek.com

wifi: rtw89: mac: process MCC related C2H

2022-12-01T11:04:26Z

Process C2H(s) related to MCC (multi-channel concurrency). These handling, which either call rtw89_complete_cond() or show message in debug mode, can be considered atomic/lock-free. So, they should be safe to be processed directly after C2H pre-check in previous patch. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221129083130.45708-5-pkshih@realtek.com

wifi: rtw89: check if atomic before queuing c2h

2022-12-01T11:04:26Z

Before queuing C2H work, we check atomicity of the C2H's handler first now. If atomic or lock-free, handle it directly; otherwise, handle it with mutex in work as previous. This prepares for MAC MCC C2Hs which require to be processed directly. And, their handlers will be functions which can be considered atomic. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221129083130.45708-3-pkshih@realtek.com

wifi: rtw89: avoid inaccessible IO operations during doing change_interface()

2022-11-22T10:15:56Z

During doing change_interface(), hardware is power-off, so some components are inaccessible and return error. This causes things unexpected, and we don't have a warning message for that. So, ignore some IO operations in this situation, and add a warning message to indicate something wrong. Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221117085235.53777-1-pkshih@realtek.com

wifi: rtw89: use u32_encode_bits() to fill MAC quota value

2022-11-09T06:59:58Z

Coverity reported shift 16 bits could cause sign extension and might get an unexpected value. Since the input values are predefined and no this kind of case, original code is safe so far. But, still changing them to use u32_encode_bits() will be more clear and prevent mistakes in the future. The original message of Coverity is: Suspicious implicit sign extension: "max_cfg->cma0_dma" with type "u16" (16 bits, unsigned) is promoted in "max_cfg->cma0_dma << 16" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "max_cfg->cma0_dma << 16" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1." Reported-by: coverity-bot Addresses-Coverity-ID: 1527095 ("Integer handling issues") Fixes: e3ec7017f6a2 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221108013858.10806-1-pkshih@realtek.com

wifi: rtw89: update D-MAC and C-MAC dump to diagnose SER

2022-11-08T07:39:47Z

To detect TX or RX stuck, we implement SER (system error recovery) in firmware to recover abnormal states of hardware, and report events to driver. This kind of events could happen rarely per day. SER might be true-positive or false-negative cases, and it could be failed to recover true-positive case. We dump related registers to kernel message at that moment and collect them from users, because they occur rarely, randomly and hard to make sure we reproduce the same symptom. To address problems accurately, add more registers by this patch. It also might be false-positive cases that looks like TX or RX get stuck, we need to dump registers from debugfs manually, so also add similar things to debugfs as well. Signed-off-by: Chia-Yuan Li Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221102014300.14091-3-pkshih@realtek.com

wifi: rtw89: add WoWLAN function support

2022-11-01T09:26:14Z

WoWLAN is a feature which allows devices to be woken up from suspend state through WLAN events. When user enables WoWLAN feature and then let the device enter suspend state, WoWLAN firmware will be loaded by the driver and periodically monitors WiFi packets. Power consumption of WiFi chip will be reduced in this state. We now implement WoWLAN function in rtw8852ae and rtw8852ce chip. Currently supported WLAN events include receiving magic packet, rekey packet and deauth packet, and disconnecting from AP. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221027052707.14605-7-pkshih@realtek.com

wifi: rtw89: add drop tx packet function

2022-11-01T09:26:13Z

When entering WoWLAN mode, we need to drop all transmit packets, including those in mac buffer, to avoid memory leakage, so implement the drop_tx function. Signed-off-by: Chih-Kang Chang Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20221027052707.14605-5-pkshih@realtek.com