| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently for CCMP256, GCMP128 and GCMP256 ciphers, in ath11k_install_key()
IEEE80211_KEY_FLAG_GENERATE_IV_MGMT is not set. And in ath11k_mac_mgmt_tx_wmi()
a length of IEEE80211_CCMP_MIC_LEN is reserved for all ciphers.
This results in unexpected management frame drop in case either of above 3 ciphers
is used. The reason is, without IEEE80211_KEY_FLAG_GENERATE_IV_MGMT set, mac80211
will not generate CCMP/GCMP headers in frame for ath11k. Also MIC length reserved
is wrong. Such frame is dropped later by hardware:
ath11k_pci 0000:5a:00.0: mac tx mgmt frame, buf id 0
ath11k_pci 0000:5a:00.0: mgmt tx compl ev pdev_id 1, desc_id 0, status 1
From user point of view, we have observed very low throughput due to this issue:
action frames are all dropped so ADDBA response from DUT never reaches AP. AP
can not use aggregation thus throughput is low.
Fix this by setting IEEE80211_KEY_FLAG_GENERATE_IV_MGMT flag and by reserving proper
MIC length for those ciphers.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Reported-by: Yaroslav Isakov <[email protected]>
Tested-by: Yaroslav Isakov <[email protected]>
Closes: https://lore.kernel.org/all/CADS+iDX5=JtJr0apAtAQ02WWBxgOFEv8G063vuGYwDTC8AVZaw@mail.gmail.com
Signed-off-by: Baochen Qiang <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
Currently, in the Rx error processing handler, once an MSDU drop is
detected, the subsequent MSDUs get unintentionally dropped due to the
previous drop flag being retained across all MSDU processing, leading
to the discarding of valid MSDUs. To resolve this issue, the drop flag
should be reset to false before processing each descriptor.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Signed-off-by: Karthikeyan Periyasamy <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
Current documentation on RCU in ath11k_mac_op_ipv6_changed() says:
/* Note: read_lock_bh() calls rcu_read_lock() */
read_lock_bh(&idev->lock);
This is wrong because without enabling CONFIG_PREEMPT_RT
rcu_read_lock() is not called by read_lock_bh(). The reason
why current code works even in a CONFIG_PREEMPT_RT=n kernel
is because atomic_notifier_call_chain() already does that for
us, see:
int atomic_notifier_call_chain()
{
...
rcu_read_lock();
ret = notifier_call_chain(&nh->head, val, v, -1, NULL);
rcu_read_unlock();
...
}
and backtrace:
ath11k_mac_op_ipv6_changed
ieee80211_ifa6_changed
notifier_call_chain
atomic_notifier_call_chain
So update the comment to make it correct.
This is found during code review, compile tested only.
Fixes: feafe59c8975 ("wifi: ath11k: use RCU when accessing struct inet6_dev::ac_list")
Signed-off-by: Baochen Qiang <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
Currently ACPI notification handler is installed when driver loads and only
gets removed when driver unloads. During resume after firmware is reloaded,
ath12k tries to install it by default. Since it is installed already, ACPI
subsystem rejects it and returns an error:
[ 83.094206] ath12k_pci 0000:03:00.0: failed to install DSM notify callback: 7
Fix it by removing that handler when going to suspend. This also avoid any
possible ACPI call to firmware before firmware is reloaded/reinitialized.
Note ab->acpi also needs to be cleared in ath12k_acpi_stop() such that we
are in a clean state when ACPI structures are reinitialized in
ath12k_acpi_start().
Tested-on: WCN7850 HW2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Fixes: 576771c9fa21 ("wifi: ath12k: ACPI TAS support")
Signed-off-by: Baochen Qiang <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
When multiple radios are advertised as a single wiphy which supports various
bands, vdev creation for the vif is deferred until channel is assigned to it.
If a remain on channel (RoC) request is received from mac80211, select the
corresponding radio (ar) based on channel and create a vdev on that radio to
initiate an RoC scan.
Note that on RoC completion this vdev is not deleted. If a new RoC/hw scan
request is seen on that same vif for a different band the vdev will be deleted
and created on the new radio supporting the request.
Also if the RoC scan is requested when the vdev is in started state, no
switching to new radio is allowed and RoC request can be accepted only on
channels within same radio.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Signed-off-by: Rameshkumar Sundaram <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Kalle Valo says:
====================
wireless-next patches for v6.11
The first "new features" pull request for v6.11 with changes both in
stack and in drivers. Nothing out of ordinary, except that we have
two conflicts this time:
net/mac80211/cfg.c
https://lore.kernel.org/all/[email protected]
drivers/net/wireless/microchip/wilc1000/netdev.c
https://lore.kernel.org/all/[email protected]
Major changes:
cfg80211/mac80211
* parse Transmit Power Envelope (TPE) data in mac80211 instead of in drivers
wilc1000
* read MAC address during probe to make it visible to user space
iwlwifi
* bump FW API to 91 for BZ/SC devices
* report 64-bit radiotap timestamp
* enable P2P low latency by default
* handle Transmit Power Envelope (TPE) advertised by AP
* start using guard()
rtlwifi
* RTL8192DU support
ath12k
* remove unsupported tx monitor handling
* channel 2 in 6 GHz band support
* Spatial Multiplexing Power Save (SMPS) in 6 GHz band support
* multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA)
support
* dynamic VLAN support
* add panic handler for resetting the firmware state
ath10k
* add qcom,no-msa-ready-indicator Device Tree property
* LED support for various chipsets
* tag 'wireless-next-2024-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (194 commits)
wifi: ath12k: add hw_link_id in ath12k_pdev
wifi: ath12k: add panic handler
wifi: rtw89: chan: Use swap() in rtw89_swap_sub_entity()
wifi: brcm80211: remove unused structs
wifi: brcm80211: use sizeof(*pointer) instead of sizeof(type)
wifi: ath12k: do not process consecutive RDDM event
dt-bindings: net: wireless: ath11k: Drop "qcom,ipq8074-wcss-pil" from example
wifi: ath12k: fix memory leak in ath12k_dp_rx_peer_frag_setup()
wifi: rtlwifi: handle return value of usb init TX/RX
wifi: rtlwifi: Enable the new rtl8192du driver
wifi: rtlwifi: Add rtl8192du/sw.c
wifi: rtlwifi: Constify rtl_hal_cfg.{ops,usb_interface_cfg} and rtl_priv.cfg
wifi: rtlwifi: Add rtl8192du/dm.{c,h}
wifi: rtlwifi: Add rtl8192du/fw.{c,h} and rtl8192du/led.{c,h}
wifi: rtlwifi: Add rtl8192du/rf.{c,h}
wifi: rtlwifi: Add rtl8192du/trx.{c,h}
wifi: rtlwifi: Add rtl8192du/phy.{c,h}
wifi: rtlwifi: Add rtl8192du/hw.{c,h}
wifi: rtlwifi: Add new members to struct rtl_priv for RTL8192DU
wifi: rtlwifi: Add rtl8192du/table.{c,h}
...
Signed-off-by: Jakub Kicinski <[email protected]>
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath
ath.git patches for v6.11
ath12k
* remove unsupported tx monitor handling
* channel 2 in 6 GHz band support
* Spatial Multiplexing Power Save (SMPS) in 6 GHz band support
* multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA) support
* dynamic VLAN support
* add panic handler for resetting the firmware state
ath10k
* add qcom,no-msa-ready-indicator Device Tree property
* LED support for various chipsets
|
|
rtw-next patches for v6.11
Some fixes and refactors of rtlwifi, rtw88 and rtw89. Only one major change
listed below:
rtlwifi:
- add new chip support of RTL8192DU
|
|
Currently, hw_link_id is sent in WMI service ready event but it
is not parsed anywhere.
But, in future, for multi-link operation, this parameter would be
needed by many WMI commands such as WMI beacon template
(WMI_BCN_TMPL_CMDID), WMI vdev start for Multi-link virtual AP
interfaces (WMI_VDEV_START_REQUEST_CMDID), WMI peer assoc command
(WMI_PEER_ASSOC_CMDID) for Multi-link peer and so on.
Hence, add changes to parse and store the hw_link_id received in
WMI service ready event in ath12k_pdev structure.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
Signed-off-by: Karthikeyan Periyasamy <[email protected]>
Signed-off-by: Harshitha Prem <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
Currently for ath12k PCI devices, firmware could be running in one of
several execution environments, e.g., PBL, SBL and mission mode etc. Among
which PBL is the only stage where PCIe link negotiation could happen. So
normally firmware runs in PBL in order to be enumerated during system reboot.
However it might not work in kernel crash scenario: ath12k target is not
found after warm reboot from kernel crash. This is because when kernel crashes,
ath12k host does nothing to firmware. And during warm reboot, WLAN power
is sustained. So firmware is likely to keep running in mission mode throughout
the bootup process. As a result PCIe link is not established and thus target
not enumerated.
So add a handler in panic notification list for ath12k. When kernel crashes,
this handler gets called and tries to reset target to PBL state. Then PCIe
link negotiation could happen and target gets enumerated.
This change applies to all PCI devices including WCN7850 and QCN9274.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Signed-off-by: Baochen Qiang <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
Use existing swap() function instead of keeping duplicate source code.
./drivers/net/wireless/realtek/rtw89/chan.c:2336:32-33: WARNING opportunity for swap().
Reported-by: Abaci Robot <[email protected]>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9174
Signed-off-by: Jiapeng Chong <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
Since commit 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx
drivers") ieee80211_hw_config() is no longer called with changed = ~0.
rtlwifi relied on ~0 in order to ignore the default retry limits of
4/7, preferring 48/48 in station mode and 7/7 in AP/IBSS.
RTL8192DU has a lot of packet loss with the default limits from
mac80211. Fix it by ignoring IEEE80211_CONF_CHANGE_RETRY_LIMITS
completely, because it's the simplest solution.
Link: https://lore.kernel.org/linux-wireless/[email protected]/
Cc: [email protected] # 6.9.x
Signed-off-by: Bitterblue Smith <[email protected]>
Acked-by: Ping-Ke Shih <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
'brcmf_pcie_core_info' was added in
commit 9e37f045d5e7 ("brcmfmac: Adding PCIe bus layer support.")
but never used.
'brcms_c_bit_desc' last use was removed in
commit cdf4352f5c59 ("brcmsmac: Improve tx trace and debug support").
Remove them.
Signed-off-by: Dr. David Alan Gilbert <[email protected]>
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
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.
Acked-by: Arend van Spriel <[email protected]>
Signed-off-by: Erick Archer <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/AS8PR02MB7237FF1C2E880D1231684D708BF02@AS8PR02MB7237.eurprd02.prod.outlook.com
|
|
Here's another one I missed during the initial conversion,
fix that.
Cc: [email protected]
Reported-by: Rene Petersen <[email protected]>
Fixes: 0a44dfc07074 ("wifi: mac80211: simplify non-chanctx drivers")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218895
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/20240528142308.3f7db1821e68.I531135d7ad76331a50244d6d5288e14aa9668390@changeid
|
|
Commit f236464f1db7 ("wifi: wilc1000: convert list management to RCU")
attempted to convert SRCU to RCU usage, assuming it was not really needed.
The runtime issues that arose after merging it showed that there are code
paths involving sleeping functions, and removing those would need some
heavier driver rework.
Add some documentation about SRCU need to make sure that any future
developer do not miss some use cases if tempted to convert back again to
RCU.
Signed-off-by: Alexis Lothoré <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
This reverts commit 35aee01ff43d7eb6c2caa0b94e7cc6c45baeeab7
Commit 35aee01ff43d ("wifi: wilc1000: set atomic flag on kmemdup in srcu
critical section") was preparatory to the SRCU to RCU conversion done by
commit f236464f1db7 ("wifi: wilc1000: convert list management to RCU").
This conversion brought issues and so has been reverted, so the atomic flag
is not needed anymore.
Signed-off-by: Alexis Lothoré <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
This reverts commit f236464f1db7bea80075e6e31ac70dc6eb80547f
Commit f236464f1db7 ("wifi: wilc1000: convert list management to RCU")
replaced SRCU with RCU, aiming to simplify RCU usage in the driver. No
documentation or commit history hinted about why SRCU has been preferred
in original design, so it has been assumed to be safe to do this
conversion.
Unfortunately, some static analyzers raised warnings, confirmed by runtime
checker, not long after the merge. At least three different issues arose
when switching to RCU:
- wilc_wlan_txq_filter_dup_tcp_ack is executed in a RCU read critical
section yet calls wait_for_completion_timeout
- wilc_wfi_init_mon_interface calls kmalloc and register_netdevice while
manipulating a vif retrieved from vif list
- set_channel sends command to chip (and so, also waits for a completion)
while holding a vif retrieved from vif list (so, in RCU read critical
section)
Some of those issues are not trivial to fix and would need bigger driver
rework. Fix those issues by reverting the SRCU to RCU conversion commit
Reported-by: Dan Carpenter <[email protected]>
Closes: https://lore.kernel.org/linux-wireless/[email protected]/
Fixes: f236464f1db7 ("wifi: wilc1000: convert list management to RCU")
Signed-off-by: Alexis Lothoré <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath
Merge ath-current from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
ath.git fixes for 6.10. Two fixes for user reported regressions in
ath11k. One dependency fix and one error path fix.
|
|
Currently we do reset for each RDDM event from MHI, however there are
cases, see below log, that we get two or more consecutive events, and
it is pointless to do reset for the subsequent ones. What's more, it
makes reset process more likely to fail.
[ 103.289864] mhi mhi0: System error detected
[ 103.289871] ath12k_pci 0000:03:00.0: mhi notify status reason MHI_CB_EE_RDDM
[ 103.293144] mhi mhi0: System error detected
[ 103.293150] ath12k_pci 0000:03:00.0: mhi notify status reason MHI_CB_EE_RDDM
Add a check to avoid reset again and again. This is done by tracking previous
MHI status: if we receive a new RDDM event while the previous event is
also the same, we treat it as duplicate and ignore it, because normally
we should at least receive a MHI_CB_EE_MISSION_MODE event between them.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Signed-off-by: Baochen Qiang <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
Currently the resource allocated by crypto_alloc_shash() is not
freed in case ath12k_peer_find() fails, resulting in memory leak.
Add crypto_free_shash() to fix it.
This is found during code review, compile tested only.
Signed-off-by: Baochen Qiang <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
|
|
Handle error code to cause failed to USB probe result from unexpected
USB EP number, otherwise when USB disconnect skb_dequeue() an uninitialized
skb list and cause warnings below.
usb 2-1: USB disconnect, device number 76
INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 PID: 54060 Comm: kworker/0:1 Not tainted 6.9.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014
Workqueue: usb_hub_wq hub_event
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:114
assign_lock_key kernel/locking/lockdep.c:976 [inline]
register_lock_class+0xc18/0xfa0 kernel/locking/lockdep.c:1289
__lock_acquire+0x108/0x3bc0 kernel/locking/lockdep.c:5014
lock_acquire kernel/locking/lockdep.c:5754 [inline]
lock_acquire+0x1b0/0x550 kernel/locking/lockdep.c:5719
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x3d/0x60 kernel/locking/spinlock.c:162
skb_dequeue+0x20/0x180 net/core/skbuff.c:3846
rtl_usb_cleanup drivers/net/wireless/realtek/rtlwifi/usb.c:706 [inline]
rtl_usb_deinit drivers/net/wireless/realtek/rtlwifi/usb.c:721 [inline]
rtl_usb_disconnect+0x4a4/0x850 drivers/net/wireless/realtek/rtlwifi/usb.c:1051
usb_unbind_interface+0x1e8/0x980 drivers/usb/core/driver.c:461
device_remove drivers/base/dd.c:568 [inline]
device_remove+0x122/0x170 drivers/base/dd.c:560
__device_release_driver drivers/base/dd.c:1270 [inline]
device_release_driver_internal+0x443/0x620 drivers/base/dd.c:1293
bus_remove_device+0x22f/0x420 drivers/base/bus.c:574
device_del+0x395/0x9f0 drivers/base/core.c:3909
usb_disable_device+0x360/0x7b0 drivers/usb/core/message.c:1418
usb_disconnect+0x2db/0x930 drivers/usb/core/hub.c:2305
hub_port_connect drivers/usb/core/hub.c:5362 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5662 [inline]
port_event drivers/usb/core/hub.c:5822 [inline]
hub_event+0x1e39/0x4ce0 drivers/usb/core/hub.c:5904
process_one_work+0x97b/0x1a90 kernel/workqueue.c:3267
process_scheduled_works kernel/workqueue.c:3348 [inline]
worker_thread+0x680/0xf00 kernel/workqueue.c:3429
kthread+0x2c7/0x3b0 kernel/kthread.c:388
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
Reported-by: Shichao Lai <[email protected]>
Closes: https://lore.kernel.org/linux-wireless/CAEk6kZuuezkH1dVRJf3EAVZK-83=OpTz62qCugkpTkswj8JF6w@mail.gmail.com/T/#u
Tested-by: Shichao Lai <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
The RTL8192DU is an older Wifi 4 dual band chip. It comes in two
flavours: single MAC single PHY (like most Realtek Wifi 4 USB devices),
and dual MAC dual PHY.
The single MAC single PHY version is 2T2R and can work either in the
2.4 GHz band or the 5 GHz band.
The dual MAC dual PHY version has two USB interfaces and appears to the
system as two separate 1T1R Wifi devices, one working in the 2.4 GHz
band, the other in the 5 GHz band.
This was tested only with a single MAC single PHY device, mostly in
station mode. The speeds in the 2.4 GHz band with 20 MHz channel width
are similar to the out-of-tree driver: 85/51 megabits/second.
Stefan Lippers-Hollmann tested the speed in the 5 GHz band with 40 MHz
channel width: 173/99 megabits/second.
It was also tested briefly in AP mode. It's emitting beacons and my
phone can connect to it.
Signed-off-by: Bitterblue Smith <[email protected]>
Tested-by: Stefan Lippers-Hollmann <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
This contains the new module's entry point.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
This allows the drivers to declare the structs rtl_hal_cfg, rtl_hal_ops,
and rtl_hal_usbint_cfg as const.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
These contain functions related to the dynamic mechanism, which runs
every two seconds to adjust to changes in the environment.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
fw.c contains a function for loading the firmware.
led.c contains a function for controlling the LED.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
These contain one RF configuration function and some functions related
to dual MAC operation.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
These contain routines related to sending frames to the chip.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
These contain mostly the calibration and channel switching routines
for RTL8192DU.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
These contain mostly hardware init/deinit routines for RTL8192DU.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
These are needed for the dual MAC version of RTL8192DU.
The two mutexes are used to avoid concurrent access to the hardware
from the two USB interfaces.
The two arrays are filled by one interface during LC calibration and
accessed by the other interface during channel switching.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
These contain the MAC, BB, RF, and AGC initialisation tables for
RTL8192DU.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
Some functions moved from rtl8192de still use the "rtl92de" prefix.
Rename them.
Signed-off-by: Bitterblue Smith <[email protected]>
Signed-off-by: Ping-Ke Shih <[email protected]>
Link: https://msgid.link/[email protected]
|
|
In case the firmware sends a notification that claims it has more data
than it has, we will read past that was allocated for the notification.
Remove the print of the buffer, we won't see it by default. If needed,
we can see the content with tracing.
This was reported by KFENCE.
Fixes: bdccdb854f2f ("iwlwifi: mvm: support MFUART dump in case of MFUART assert")
Signed-off-by: Emmanuel Grumbach <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240513132416.ba82a01a559e.Ia91dd20f5e1ca1ad380b95e68aebf2794f553d9b@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
When HW rfkill is toggled to disable the RF, the flow to stop scan is
called. When trying to send the command to abort the scan, since
HW rfkill is toggled, the command is not sent due to rfkill being
asserted, and -ERFKILL is returned from iwl_trans_send_cmd(), but this
is silently ignored in iwl_mvm_send_cmd() and thus the scan abort flow
continues to wait for scan complete notification and fails. Since it
fails, the UID to type mapping is not cleared, and thus a warning is
later fired when trying to stop the interface.
To fix this, modify the UMAC scan abort flow to force sending the
scan abort command even when in rfkill, so stop the FW from accessing
the radio etc.
Signed-off-by: Ilan Peer <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240513132416.8cbe2f8c1a97.Iffe235c12a919dafec88eef399eb1f7bae2c5bdb@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
In some versions of cfg80211, the ssids poinet might be a valid one even
though n_ssids is 0. Accessing the pointer in this case will cuase an
out-of-bound access. Fix this by checking n_ssids first.
Fixes: c1a7515393e4 ("iwlwifi: mvm: add adaptive dwell support")
Signed-off-by: Miri Korenblit <[email protected]>
Reviewed-by: Ilan Peer <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Link: https://msgid.link/20240513132416.6e4d1762bf0d.I5a0e6cc8f02050a766db704d15594c61fe583d45@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
Ensure that the 6 GHz channel is configured with a valid direct BSSID,
avoiding any invalid or multicast BSSID addresses.
Signed-off-by: Ayala Beker <[email protected]>
Reviewed-by: Ilan Peer <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240513132416.91a631a0fe60.I2ea2616af9b8a2eaf959b156c69cf65a2f1204d4@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
When entering RF-kill, mac80211 tears down BA sessions, but
due to RF-kill the commands aren't sent to the device. As a
result, there can be frames pending on the reorder buffer or
perhaps even received while doing so, leading to warnings.
Avoid the warnings by doing the BA session teardown normally
even in RF-kill, which also requires queue sync.
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240513132416.0762cd80fb3d.I43c5877f3b546159b2db4f36d6d956b333c41cf0@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
The BIGTK cipher field was added to the kek_kck_material_cmd
but wasn't assigned. Fix that by differentiating between the
IGTK/BIGTK keys and assign the ciphers fields accordingly.
Signed-off-by: Yedidya Benshimol <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240513132416.7fd0b22b7267.Ie9b581652b74bd7806980364d59e1b2e78e682c0@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
If pre-recovery mac80211 tried to disable a link but this disablement
failed, then there might be a mismatch between mac80211 assuming the
link has been disabled and the driver still having the data around.
During recover itself, that is not a problem, but should the link be
activated again at a later point, iwlwifi will refuse the activation as
it detects the inconsistent state.
Solve this corner-case by iterating the station in the restart cleanup
handler.
Signed-off-by: Benjamin Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240513132416.d2fd60338055.I840d4fdce5fd49fe69896d928b071067e3730259@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
The driver should call iwl_dbg_tlv_free even if debugfs is not defined
since ini mode does not depend on debugfs ifdef.
Fixes: 68f6f492c4fa ("iwlwifi: trans: support loading ini TLVs from external file")
Signed-off-by: Shahar S Matityahu <[email protected]>
Reviewed-by: Luciano Coelho <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240510170500.c8e3723f55b0.I5e805732b0be31ee6b83c642ec652a34e974ff10@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
In the driver we only use skb_put* for adding data to the skb, hence data
never moves and skb_reset_mac_haeder would set mac_header to the first
time data was added and not to mac80211 header, fix this my using the
actual len of bytes added for setting the mac header.
Fixes: 3f7a9d577d47 ("wifi: iwlwifi: mvm: simplify by using SKB MAC header pointer")
Signed-off-by: Mordechay Goodstein <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240510170500.12f2de2909c3.I72a819b96f2fe55bde192a8fd31a4b96c301aa73@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
We don't actually support >64 even for HE devices, so revert
back to 64. This fixes an issue where the session is refused
because the queue is configured differently from the actual
session later.
Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax")
Signed-off-by: Johannes Berg <[email protected]>
Reviewed-by: Liad Kaufman <[email protected]>
Reviewed-by: Luciano Coelho <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240510170500.52f7b4cf83aa.If47e43adddf7fe250ed7f5571fbb35d8221c7c47@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
After moving from commands to notificaitons in the d3 resume flow,
removing the WOWLAN_GET_STATUSES and REPLY_OFFLOADS_QUERY_CMD causes
the return of the default value when looking up their version.
Returning zero here results in the driver sending the not supported
NON_QOS_TX_COUNTER_CMD.
Signed-off-by: Yedidya Benshimol <[email protected]>
Reviewed-by: Gregory Greenman <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240510170500.8cabfd580614.If3a0db9851f56041f8f5360959354abd5379224a@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
Since IWL_FW_CMD_VER_UNKNOWN = 99, then my change to consider
cmd_ver >= 7 instead of cmd_ver = 7 included also firmwares that don't
advertise the command version at all. This made us send a command with a
bad size and because of that, the firmware hit a BAD_COMMAND immediately
after handling the REDUCE_TX_POWER_CMD command.
Fixes: 8f892e225f41 ("wifi: iwlwifi: mvm: support iwl_dev_tx_power_cmd_v8")
Signed-off-by: Emmanuel Grumbach <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240512072733.eb20ff5050d3.Ie4fc6f5496cd296fd6ff20d15e98676f28a3cccd@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
In beacon template version 14, make sure to always set
the TWT IE offset before sending the beacon template command,
also in the debugfs inject_beacon_ie path.
If the TWT IE does not exist, the offset will be set to zero.
Fixes: bf0212fd8faa ("wifi: iwlwifi: mvm: add beacon template version 14")
Signed-off-by: Shaul Triebitz <[email protected]>
Signed-off-by: Miri Korenblit <[email protected]>
Link: https://msgid.link/20240512152312.eb27175c345a.If30ef24aba10fe47fd42a7a9703eb8903035e294@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
The initialization of this worker moved to iwl_mvm_mac_init_mvmvif
but we removed only from the pre-MLD version of the add_interface
callback. Remove it also from the MLD version.
Fixes: 0bcc2155983e ("wifi: iwlwifi: mvm: init vif works only once")
Signed-off-by: Miri Korenblit <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Link: https://msgid.link/20240512152312.4f15b41604f0.Iec912158e5a706175531d3736d77d25adf02fba4@changeid
Signed-off-by: Johannes Berg <[email protected]>
|
|
The iwl_dev_info entries for these devices were incorrectly positioned
within the array, out of chronological order. Move them arround.
Signed-off-by: Miri Korenblit <[email protected]>
Reviewed-by: Johannes Berg <[email protected]>
Reviewed-by: Emmanuel Grumbach <[email protected]>
Link: https://msgid.link/20240527190228.a75e9a1eb86c.I003980f8ca60a96019657e396e848a07df6b92a4@changeid
Signed-off-by: Johannes Berg <[email protected]>
|