| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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: c888183b21f3 ("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
|
|
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: 5b8471ace5b1 ("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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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: ed9a3c0d4dd9 ("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
|
|
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
|
|
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
|
|
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
|
|
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=9358
Signed-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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
wait_for_completion_interruptible_timeout()
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If non-BSS and remain-on-channel (ROC) blocking were to occur
simultaneously, they'd step on each other's toes, unblocking
when not yet supported. Disentangle these bits, and ROC doesn't
need to use the non_bss_link() function then.
Fixes: a1efeb823084 ("wifi: iwlwifi: mvm: Block EMLSR when a p2p/softAP vif is active")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140556.461fcf7b95bb.Id0d21dcb739d426ff15ec068b5df8abaab58884d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Stop supporting all FWs older than the max API version.
These FW versions were supported since v6.5.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240605140327.ad6d43fe9893.I96f769e7d5be3e6499d260451df781bd694a5142@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When EMLSR gets unblocked, the current code checks if the last exit was
due to an EXIT reason (as opposed to a BLOCKING one), and if so, it
does nothing, as in this case a MLO scan was scheduled to run in 30
seconds.
But the code doesn't consider the time that passed from the last exit,
so if immediately after the exit a blocker occurred (e.g. non-BSS
interface), and lasts for more than 30 seconds, then the MLO scan and the
following link selection will decide not to enter EMLSR, and when the
unblocking event finally happens, the reason is still set to the EXIT one,
so it will do nothing, and we will not have the chance to re-enable EMLSR.
Fix this by checking also the time that has passed since the last exit,
only if it is less than 30 seconds, we can count on the scheduled MLO
scan.
Note that clearing the reason itself can't be done since it is needed
for the EMLSR prevention mechanism.
Fixes: 2f33561ea8f9 ("wifi: iwlwifi: mvm: trigger link selection after exiting EMLSR")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240605140327.58556fc4cfa9.I4c55b3cd9f20b21b37f28258d0fb6842ba413966@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This was needed when we had multiple types of transports. Now we only
have pcie, so there is no need for this ops.
Cleanup the code such as the different trans APIs will call the pcie
function directly, instead of calling the callback,
and remove struct iwl_trans_ops.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140327.8315ff64f9f3.Ifdbc1f26d49766f7de553dcb5f613885f4ee65cc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The TX queue code was mostly moved out to support an internal
transport that we were never going to publish, but we're no
longer using that. Since we're also going to be dissolving
the virtual transport layer entirely, integrate the TX queue
code into the PCIe layer.
This also has a small kernel of already removing the virtual
transport function layer, since iwl_trans_send_cmd() calls
iwl_trans_pcie_send_hcmd() directly now, even if that still
calls the transport send_cmd method for now, we'll clean it
up later.
Also, not everything is renamed yet.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140327.936b13f45071.Ib219ce01a1e67bcad79d5131626db950252aaa46@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This needs to include dbg-tlv.h since it uses the value of
IWL_FW_INI_ALLOCATION_NUM from that file.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140327.2d25691283eb.I0909621a0e293a8a21d4f1de6e5fd59c22e4b212@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This really isn't correct to be in the opmode, do the clamping
(and power-of-2 fixup that may be necessary due to this, or even
otherwise) in the queue code. Also move down the retrying of the
allocation, it should be after all the size fixups, but also it
just makes sense, and avoids retrying same-size allocations in
the case of the BZ-family A-step workaround.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140327.000a0a1e807d.Ib822590d5aca76ff3168418ae2c139b3d43d81ed@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When entering D3 we want to configure skip over DTIM, but
it can't use the deflink configuration, that will not even
exist. Adjust the code to handle multiple links by taking
the min skip, even if we should only have a single active
link at this point.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605140327.bccf980fadb4.Idc98b9f3634f39d2fae9bd9916f5d050ccd48f95@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Stop supporting older FWs.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240605140327.ff8477233010.Ic8c73bd6749cc5f8ab5297807bb0be9bd96a59fa@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
These entries are not used, remove them.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240605140327.0c7c520814d5.I19cefb3d81b03a5be94c029cfffd1c8b8c437182@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If a user uses iw to connect to a network and we don't have any
information about the existing networks, cfg80211 will trigger a scan
internally even if the user didn't ask for a scan. This scan is
implemented by cfg80211_conn_scan(). This function called rdev_scan()
directly without honoring the WIPHY_FLAG_SPLIT_SCAN_6GHZ flag.
Use cfg80211_scan instead, this will split the scan if the low level
driver asked to.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605135233.33f03661476a.I7b5be20a55aafe012cd9ddb3b4ba2d46b256ace4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There's no need to have the always-zero ret variable in
the function scope, move it into the inner scope only.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605135233.eb7a24632d98.I72d7fe1da89d4b89bcfd0f5fb9057e3e69355cfe@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When e.g. wpa_supplicant sets only the MLD "sta" authorized
state, the code actually applies that change, but then returns
an error to userspace anyway because there were no changes to
the link station, and no link ID was given. However, it's not
incorrect to not have a link ID when wanting to change only
the MLD peer ("sta") state, so the code shouldn't require it.
To fix this, separate the "new_link" argument out into a new
three-state enum, because if modify is called on a link STA
only, it should return an error if no link is given or if it
doesn't exist. For modify on the MLD "sta", not having a link
ID is OK, but if there is one it should be validated.
This seems to not have mattered much as wpa_supplicant just
prints a message and continues, and the authorized state was
already set before this error return. However, in the later
code powersave recalculation etc. will be skipped, so that it
may result in never allowing powersave on MLO connections.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605135233.48e2b8af07e3.Ib9793c383fcba118c05100e024f4a11a1c3d0e85@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Setting a channel with 320 MHz channel width over hwsim results in an
array-index-out-of-bounds error. Fix it by adding 320 MHz to hwsim
supported channel widths.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605135233.a766c1465566.Ib859c7233511b61b8a34022cfceeb4971c739d80@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In NDP ranging, the number of NDP exchanges is not negotiated
and thus is not limited by the protocol. Remove the limit on
FTMs per burst for trigger based and non trigger based ranging.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240605135233.916e228537d9.I5fe4c1cefa1c1328726e7615dd5a0d861c694381@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
On 6 GHz (and also 5 GHz to some degree), only a specific set of center
frequencies should be used depending on the channel bandwidth. Verify
this is the case on 6 GHz. For 5 GHz, we are more accepting as there are
APs that got it wrong historically.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240602102200.876b10a2beda.I0d3d0daea4014e99654437ff6691378dbe452652@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add a regulatory flag to allow VLP AP operation even on
channels otherwise marked NO_IR, which may be possible
in some regulatory domains/countries.
Note that this requires checking also when the beacon is
changed, since that may change the regulatory power type.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240523120945.63792ce19790.Ie2a02750d283b78fbf3c686b10565fb0388889e2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
