- 05 Jul, 2024 6 commits
-
-
Fredrik Lönnegren authored
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
-
Zong-Zhe Yang authored
Driver will notify FW the target index of RFK table to use at some moments. When MCC (multi-channel concurrent), the correctness of the notification is especially important. We now unify the selection logic of RFK table as below among chips. 1. check each table if it matches target channel 2. check all tables if any is idle by iterating active channels 3. replace the first table if all are busy unexpectedly Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240702124452.18747-2-pkshih@realtek.com
-
Zong-Zhe Yang authored
MRC (multi-role concurrency) has a C2H event for status report. Newer FW will report some kinds of failures. We parse them now and show by debug log. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240702124452.18747-1-pkshih@realtek.com
-
Ping-Ke Shih authored
For 8852BT, the initial settings of BT-coexistence is a little bit different, so add the extra handles. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240701014619.7300-2-pkshih@realtek.com
-
Ping-Ke Shih authored
The BT coexistence part of 8852B and 8852BT are similar, so move shared code into common module. Don't change logic for existing RTL8852BE. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240701014619.7300-1-pkshih@realtek.com
-
Marcin Ślusarz authored
Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup. The stack trace looks like this: rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on. Fix this by moving the first usb_submit_urb after everything is set up. For me, this bug manifested as: [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped [ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status. Link: https://lore.kernel.org/linux-wireless/CA+shoWQ7P49jhQasofDcTdQhiuarPTjYEDa--NiVVx494WcuQw@mail.gmail.com/Signed-off-by: Marcin Ślusarz <mslusarz@renau.com> Cc: Tim K <tpkuester@gmail.com> Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Kalle Valo <kvalo@kernel.org> Cc: linux-wireless@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240528110246.477321-1-marcin.slusarz@gmail.com
-
- 02 Jul, 2024 6 commits
-
-
Ping-Ke Shih authored
RCK is synchronize RC calibration. Driver triggers this calibration and writes the result to registers. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240627025849.25198-5-pkshih@realtek.com
-
Ping-Ke Shih authored
DACK (digital-to-analog converters calibration) is used to calibrate DAC to output signals as expected. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240627025849.25198-4-pkshih@realtek.com
-
Ping-Ke Shih authored
RX DCK stands for receiver DC calibration. With this calibration, we have proper DC offset to reflect correct received signal strength indicator. Do this calibration when bringing up interface and going to connect. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240627025849.25198-3-pkshih@realtek.com
-
Ping-Ke Shih authored
IQ signal calibration is a very important calibration to yield good RF performance. We do this calibration once we are going to an AP. During scanning phase, without this calibration RF performance is still acceptable because it transmits and receives with low data rate at this phase. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240627025849.25198-2-pkshih@realtek.com
-
Zong-Zhe Yang authored
Calculate a TX power constraint based on content of ieee80211 Transmit Power Envelope (TPE). Since HW control registers aren't designed as many as all kinds of TPE fields, we strictly intersect all TPE inputs in driver. Then, according to result, constrain TX power via TX power limit/limit_RU. Besides, extend dbgfs txpwr_table to show info about 6 GHz regulatory. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240626023237.7901-1-pkshih@realtek.com
-
Ching-Te Ku authored
Add additional policy option to let Bluetooth audio can play well during Wi-Fi is hardware scanning. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240626023129.7776-1-pkshih@realtek.com
-
- 27 Jun, 2024 12 commits
-
-
Martin Kaistra authored
TX power index is read from the efuse on init, the values get written to the TX power registers when the channel gets switched. When the chip has not yet been calibrated, the efuse values are 0xFF, which on some boards leads to USB timeouts for reading/writing registers after the first frames have been sent. The vendor driver (v5.11.5-1) checks for these invalid values and sets default values instead. Implement something similar in rtl8188fu_parse_efuse(). Fixes: c888183b ("wifi: rtl8xxxu: Support new chip RTL8188FU") Signed-off-by: Martin Kaistra <martin.kaistra@linutronix.de> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240624140037.231657-1-martin.kaistra@linutronix.de
-
Kuan-Chung Chen authored
An incorrect definition caused DPK to fail to backup and restore a set of KIP registers. Fixing this will improve RX throughput from 902 to 997 Mbps. Fixes: 5b8471ac ("wifi: rtw89: 8852b: rfk: add DPK") Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240621123617.6687-2-pkshih@realtek.com
-
Ping-Ke Shih authored
Enlarge AMSDU limit to improve MAC efficient to get better TX throughput from 851 to 895 Mbps. No change for RX throughput 902 Mbps. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240621123617.6687-1-pkshih@realtek.com
-
Ping-Ke Shih authored
DPK is short for digital pre-distortion calibration. It can adjusts digital waveform according to PA linear characteristics dynamically to enhance TX EVM for high power. Do this calibration when we are going to run on AP channel. To prevent power offset out of boundary, it monitors thermal and set proper boundary to register. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240621073458.55187-3-pkshih@realtek.com
-
Ping-Ke Shih authored
TSSI is transmitter signal strength indication, which is a close-loop hardware circuit to feedback actual transmitting power as a reference for next transmission. It does full calibration when we are going to connect an AP. When switching bands or channels for scanning or some reasons, reset hardware status to prevent use wrong power value feedback from previous transmission. It also loads tables of compensation values reflecting current temperature into registers according to channel and band group to transmit packets with expected power. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240621073458.55187-2-pkshih@realtek.com
-
Chih-Kang Chang authored
We add polling after sending LPS H2C to ensure that the Firmware is received and executes RPWM thereafter. Otherwise, if the Firmware executes RPWM without receiving LPS H2C, it will cause beacon loss in WoWLAN mode due to the inability to obtain channel and bandwidth information from H2C. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240620055825.17592-8-pkshih@realtek.com
-
Chih-Kang Chang authored
To avoid wake up by AP disconnection, but no beacon filter setting and driver can't disconnect successfully. We need to enable beacon filter after swapping firmware in WoWLAN mode. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240620055825.17592-7-pkshih@realtek.com
-
Chih-Kang Chang authored
While downloading Firmware in the resume flow, it is possible to receive beacon and send H2C to Firmware. However, if Firmware receives unexpected H2C during the download process, it will fail. Therefore, we prevent to send unexpected H2C during download Firmware in WoWLAN mode. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240620055825.17592-6-pkshih@realtek.com
-
Chih-Kang Chang authored
We mistakenly put skb too large and that may exceed skb->end. Therefore, we fix it. skbuff: skb_over_panic: text:ffffffffc09e9a9d len:416 put:204 head:ffff8fba04eca780 data:ffff8fba04eca7e0 tail:0x200 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:192! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4747 Comm: kworker/u4:44 Tainted: G O 6.6.30-02659-gc18865c4dfbd #1 86547039b47e46935493f615ee31d0b2d711d35e Hardware name: HP Meep/Meep, BIOS Google_Meep.11297.262.0 03/18/2021 Workqueue: events_unbound async_run_entry_fn RIP: 0010:skb_panic+0x5d/0x60 Code: c6 63 8b 8f bb 4c 0f 45 f6 48 c7 c7 4d 89 8b bb 48 89 ce 44 89 d1 41 56 53 41 53 ff b0 c8 00 00 00 e8 27 5f 23 00 48 83 c4 20 <0f> 0b 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 RSP: 0018:ffffaa700144bad0 EFLAGS: 00010282 RAX: 0000000000000089 RBX: 0000000000000140 RCX: 14432c5aad26c900 RDX: 0000000000000000 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffaa700144bae0 R08: 0000000000000000 R09: ffffaa700144b920 R10: 00000000ffffdfff R11: ffffffffbc28fbc0 R12: ffff8fba4e57a010 R13: 0000000000000000 R14: ffffffffbb8f8b63 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8fba7bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007999c4ad1000 CR3: 000000015503a000 CR4: 0000000000350ee0 Call Trace: <TASK> ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? skb_panic+0x5d/0x60 ? do_error_trap+0x6d/0x90 ? skb_panic+0x5d/0x60 ? handle_invalid_op+0x30/0x40 ? skb_panic+0x5d/0x60 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_panic+0x5d/0x60 skb_put+0x49/0x50 rtw89_fw_h2c_wow_gtk_ofld+0xbd/0x220 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5] rtw89_wow_resume+0x31f/0x540 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5] rtw89_ops_resume+0x2b/0xa0 [rtw89_core 778b32de31cd1f14df2d6721ae99ba8a83636fa5] ieee80211_reconfig+0x84/0x13e0 [mac80211 818a894e3b77da6298269c59ed7cdff065a4ed52] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] ? dev_printk_emit+0x51/0x70 ? _dev_info+0x6e/0x90 ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] wiphy_resume+0x89/0x180 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 1a793119e2aeb157c4ca4091ff8e1d9ae233b59d] dpm_run_callback+0x3c/0x140 device_resume+0x1f9/0x3c0 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x29/0xd0 process_scheduled_works+0x1d8/0x3d0 worker_thread+0x1fc/0x2f0 kthread+0xed/0x110 ? __pfx_worker_thread+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x38/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Modules linked in: ccm 8021q r8153_ecm cdc_ether usbnet r8152 mii dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc uinput rfcomm cmac algif_hash rtw89_8922ae(O) algif_skcipher rtw89_8922a(O) af_alg rtw89_pci(O) rtw89_core(O) btusb(O) snd_soc_sst_bxt_da7219_max98357a btbcm(O) snd_soc_hdac_hdmi btintel(O) snd_soc_intel_hda_dsp_common snd_sof_probes btrtl(O) btmtk(O) snd_hda_codec_hdmi snd_soc_dmic uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videobuf2_common snd_sof_pci_intel_apl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_intel_hda soundwire_intel soundwire_generic_allocation snd_sof_intel_hda_mlink soundwire_cadence snd_sof_pci snd_sof_xtensa_dsp mac80211 snd_soc_acpi_intel_match snd_soc_acpi snd_sof snd_sof_utils soundwire_bus snd_soc_max98357a snd_soc_avs snd_soc_hda_codec snd_hda_ext_core snd_intel_dspcfg snd_intel_sdw_acpi snd_soc_da7219 snd_hda_codec snd_hwdep snd_hda_core veth ip6table_nat xt_MASQUERADE xt_cgroup fuse bluetooth ecdh_generic cfg80211 ecc gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]--- Fixes: ed9a3c0d ("wifi: rtw89: wow: construct EAPoL packet for GTK rekey offload") Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240620055825.17592-5-pkshih@realtek.com
-
Chih-Kang Chang authored
The 802.11ax chip also needs rtw89_mac_cpu_io_rx(), which notifies Firmware to start or stop WoWLAN and waits until Firmware process over. Then, the driver can continue processing to avoid unexpected behavior. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240620055825.17592-4-pkshih@realtek.com
-
Chih-Kang Chang authored
Need to update WoWLAN wakeup reason register after firmware version 0.35.22.0 for RTL8922A, and 0.27.80.0 for RTL8852CE. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240620055825.17592-3-pkshih@realtek.com
-
Chih-Kang Chang authored
When creating EAPOL_KEY, SA_QUERY and ARP_RSP packet offload, we need to append security header offset for different cipher as required by the firmware. Only 8852A, 8852B, 8852BT and 8851B need it. Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240620055825.17592-2-pkshih@realtek.com
-
- 21 Jun, 2024 2 commits
-
-
Jiapeng Chong authored
Use existing swap() function rather than duplicating its implementation. ./drivers/net/wireless/realtek/rtl8xxxu/core.c:6749:30-31: WARNING opportunity for swap(). Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9358Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20240619024017.53246-1-jiapeng.chong@linux.alibaba.com
-
Bitterblue Smith authored
Currently the number of frames sent to the chip in a single USB Request Block is limited only by the size of the TX buffer, which is 20 KiB. Testing reveals that as many as 13 frames get aggregated. This is more than what any of the chips would like to receive. RTL8822CU, RTL8822BU, and RTL8821CU want at most 3 frames, and RTL8723DU wants only 1 frame per URB. RTL8723DU in particular reliably malfunctions during a speed test if it receives more than 1 frame per URB. All traffic seems to stop. Pinging the AP no longer works. Fix this problem by limiting the number of frames sent to the chip in a single URB according to what each chip likes. Also configure RTL8822CU, RTL8822BU, and RTL8821CU to expect 3 frames per URB. RTL8703B may or may not be found in USB devices. Declare that it wants only 1 frame per URB, just in case. Tested with RTL8723DU and RTL8811CU. Cc: stable@vger.kernel.org Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/cb46ea35-7e59-4742-9c1f-01ceeaad36fb@gmail.com
-
- 17 Jun, 2024 7 commits
-
-
Ping-Ke Shih authored
Read 32 bits RX info to a local variable to fix race condition between reading RX length and RX tag. Another solution is to get RX tag at first statement, but adopted solution can save some memory read, and also save 15 bytes binary code. RX tag, a sequence number, is used to ensure that RX data has been DMA to memory completely, so driver must check sequence number is expected before reading other data. This potential problem happens only after enabling 36-bit DMA. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240611021901.26394-2-pkshih@realtek.com
-
Ping-Ke Shih authored
Modern platforms can install more than 4GB memory, so DMA address can larger than 32 bits. If a platform doesn't enable IOMMU, kernel needs extra works of swiotlb to help DMA that packets reside on memory over 4GB. The DMA addressing capability of Realtek WiFi chips is 36 bits, so set LSB 4 bits of high 32-bit address to register and TX/RX descriptor, which below figure shows 3-level pointers in TX direction, and RX direction is similar but 2-level pointers only. +--------+ | | register to head of TX BD +---|----+ | +---------+ +-----> | TX BD | (in memory) +----|----+ | +---------+ +------> | TX WD | (in memory) +----|----+ | +--------+ +------> | skb | +--------+ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240611021901.26394-1-pkshih@realtek.com
-
Ping-Ke Shih authored
Version C of 8922AE hardware will use the same firmware of version B, so extend rule of firmware recognition to allow less but closest firmware version. Originally only accept firmware with matched version. Tested on version A/B/C of 8922AE. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240607140251.8295-1-pkshih@realtek.com
-
Ping-Ke Shih authored
Many common settings can share to 8851B, 8852B and 8852BT, so add an inline function rtw89_is_rtl885xb() to be concise. Meanwhile review and align settings for existing chips. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240607070659.80263-4-pkshih@realtek.com
-
Ping-Ke Shih authored
The channel configuration of 8852BT is very similar but a little different to 8852B, so use chip ID as condition to add extra handles including external loss compensation, ADC configurations, spur settings and so on. Don't affect existing 8852BE. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240607070659.80263-3-pkshih@realtek.com
-
Ping-Ke Shih authored
New upcoming chip is RTL8852BE-VT (or RTL8852BTE; 8852BT PCIE interface), which is a variant of 8852B, and many codes excepting to RF calibration can be shared, so move common code to an new kernel module named rtw89_8852b_common.ko. No logic change. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240607070659.80263-2-pkshih@realtek.com
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240603091541.8367-6-wsa+renesas@sang-engineering.com
-
- 12 Jun, 2024 7 commits
-
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240603091541.8367-7-wsa+renesas@sang-engineering.com
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_interruptible_timeout() causing patterns like: timeout = wait_for_completion_interruptible_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Fix to the proper variable type 'long' while here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240603091541.8367-5-wsa+renesas@sang-engineering.com
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_for_completion_timeout() causing patterns like: timeout = wait_for_completion_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240603091541.8367-4-wsa+renesas@sang-engineering.com
-
Wolfram Sang authored
There is a confusing pattern in the kernel to use a variable named 'timeout' to store the result of wait_event_timeout() causing patterns like: timeout = wait_event_timeout(...) if (!timeout) return -ETIMEDOUT; with all kinds of permutations. Use 'time_left' as a variable to make the code self explaining. Fix to the proper variable type 'long' while here. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/20240603091541.8367-3-wsa+renesas@sang-engineering.com
-
Erick Archer authored
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. As the "cmd_buf" variable is a pointer to "struct at76_command" and this structure ends in a flexible array: struct at76_command { [...] u8 data[]; } __packed; the preferred way in the kernel is to use the struct_size() helper to do the arithmetic instead of the calculation "size + count" in the kmalloc() function. Also, declare a new variable (total_size) since the return value of the struct_size() helper is used several times. At the same time, prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). In this case, it is important to note that the attribute used is "__counted_by_le" since the counter type is "__le16". This way, the code is more readable and safer. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by: Erick Archer <erick.archer@outlook.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/AS8PR02MB7237578654CEDDFE5F8C17BA8BFE2@AS8PR02MB7237.eurprd02.prod.outlook.com
-
Erick Archer authored
It is preferred to use sizeof(*pointer) instead of sizeof(type) due to the type of the variable can change and one needs not change the former (unlike the latter). This patch has no effect on runtime behavior. At the same time remove some redundant NULL initializations. Signed-off-by: Erick Archer <erick.archer@outlook.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://msgid.link/AS8PR02MB7237C784C14DBC943CB719F88BFE2@AS8PR02MB7237.eurprd02.prod.outlook.com
-
Shaul Triebitz authored
This is the first step towards removing the P2P Device MAC. Use ROC (which uses the AUX MAC) for P2P Device discoveribility and action frames. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240605140556.8c90e457abbd.I8e340759ecb299e05b1809f3d8060429c6cbbd01@changeidSigned-off-by: Johannes Berg <johannes.berg@intel.com>
-