Erick Archer [Mon, 27 May 2024 17:34:25 +0000 (19:34 +0200)]
wifi: brcm80211: use sizeof(*pointer) instead of sizeof(type)
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.
Ping-Ke Shih [Fri, 24 May 2024 00:32:48 +0000 (08:32 +0800)]
wifi: rtlwifi: handle return value of usb init TX/RX
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 <shichaorai@gmail.com> Closes: https://lore.kernel.org/linux-wireless/CAEk6kZuuezkH1dVRJf3EAVZK-83=OpTz62qCugkpTkswj8JF6w@mail.gmail.com/T/#u Tested-by: Shichao Lai <shichaorai@gmail.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://msgid.link/20240524003248.5952-1-pkshih@realtek.com
Bitterblue Smith [Thu, 23 May 2024 14:49:00 +0000 (17:49 +0300)]
wifi: rtlwifi: Enable the new rtl8192du driver
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.
Johannes Berg [Thu, 23 May 2024 10:03:52 +0000 (12:03 +0200)]
wifi: mac80211: handle HW restart during ROC
If we have a HW restart in the middle of a ROC period,
then there are two cases:
- if it's a software ROC, we really don't need to do
anything, since the ROC work will still be queued
and will run later, albeit with the interruption
due to the restart;
- if it's a hardware ROC, then it may have begun or
not, if it did begin already we can only remove it
and tell userspace about that.
In both cases, this fixes the warning that would appear
in ieee80211_start_next_roc() in this case.
In the case of some drivers such as iwlwifi, the part of
restarting is never going to happen since the driver will
cancel the ROC, but flushing the work to ensure nothing
is pending here will also result in no longer being able
to trigger the warning in this case.
Miri Korenblit [Mon, 27 May 2024 16:06:14 +0000 (19:06 +0300)]
wifi: iwlwifi: move amsdu_size parsing to iwlwifi
The code that is parsing the amsdu_size module parameter and mapping it
to the corresponding Rx buffer size is common to all opmodes.
Move it into a function in iwlwifi, as preparation to a new op mode we
are working on.
Miri Korenblit [Mon, 27 May 2024 16:06:13 +0000 (19:06 +0300)]
wifi: iwlwifi: remove redundant prints
Upon start, the different opmodes are currently printing:
1. HW rev, which is already print by iwlwifi
2. The HW name (e.g. "Intel(R) Wi-Fi 7 BE201 320MHz")
cleanup things such as the hw rev won't be printed again, the HW name will
be printed by iwlwifi instead of each opmode.
Johannes Berg [Mon, 27 May 2024 16:06:10 +0000 (19:06 +0300)]
wifi: iwlwifi: mvm: show full firmware ID in debugfs
The firmware prefix is unused today, but it might still be
useful to have some information. Since the prefix will get
the intel/ directory in some cases, replace the prefix by
the full FW id which has all the information.
Johannes Berg [Mon, 27 May 2024 16:06:08 +0000 (19:06 +0300)]
wifi: iwlwifi: mvm: use only beacon BSS load for active links
For active links, don't take information that may have been
received in probe responses, as those are not protected. For
inactive links, there may not be a choice.
Modify iwl_mvm_ftm_set_secured_ranging() parameters to support
multiple versions of the target struct.
This is done as preparation for moving to the new range request
version.
Avraham Stern [Mon, 27 May 2024 16:06:04 +0000 (19:06 +0300)]
wifi: iwlwifi: mvm: initiator: move setting the sta_id into a function
Move setting the target's sta_id (and related flags) into a function
to support different versions of the target struct.
This is done as preparation for moving to the new range request
version.
Avraham Stern [Mon, 27 May 2024 16:06:02 +0000 (19:06 +0300)]
wifi: iwlwifi: mvm: initiator: move setting target flags into a function
Move setting the target flags into a dedicated function to support
different versions of the target struct.
This is done as preparation for moving to the new range request
version.
Johannes Berg [Mon, 27 May 2024 16:06:01 +0000 (19:06 +0300)]
wifi: iwlwifi: mvm: handle TPE advertised by AP
6 GHz BSS SP client shall respect TX power limits advertised
by the AP in TPE elements, send the data to the firmware using
the AP_TX_POWER_CONSTRAINTS_CMD command, so do that.
Use the new RX_FLAG_MACTIME_IS_RTAP_TS64 in mac80211 to report
a 64-bit timestamp in the mactime for radiotap only, in case we
report the synchronized PTP clock timestamp (otherwise we really
only have 32 bits anyway).
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Gregory Greenman <gregory.greenman@intel.com> Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240527190228.4fc44356e7df.Ic8642d35f1090a415e09299a1bd409f51dfb6351@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Avraham Stern [Mon, 27 May 2024 16:05:56 +0000 (19:05 +0300)]
wifi: iwlwifi: mvm: add an option to use ptp clock for rx timestamp
Add a debugfs option to use the ptp clock time for rx device
timestamps. This can be useful to e.g. synchronize multiple NICs or
reporting the timestamp in the system clock instead of gp2.
Ping-Ke Shih [Wed, 22 May 2024 02:38:29 +0000 (10:38 +0800)]
wifi: rtw89: fill STBC and LDPC capabilities to TX descriptor
Fill STBC and LDPC fields to get better performance when transmitting under
noisy environment. Old chips like 8852AE use firmware command to enable
these two capabilities, but newer chips must use TX descriptor.
Ping-Ke Shih [Tue, 21 May 2024 04:01:39 +0000 (12:01 +0800)]
wifi: rtw89: 8852c: correct logic and restore PCI PHY EQ after device resume
PCI PHY EQ value is missing after card off/on, so update the value after
device resume. The original commit only updates once at probe stage, which
could lead problem after suspend/resume.
The logic should be read a value from one register and write to another
register with a mask to avoid affecting unrelated bits.
Johannes Berg [Fri, 10 May 2024 09:26:02 +0000 (11:26 +0200)]
wifi: mac80211: send DelBA with correct BSSID
In MLO, the deflink BSSID is clearly invalid. Since we fill
the addresses as MLD addresses and translate later, use the
AP address here instead.
This fixes an issue that happens with HW restart, where the
DelBA frame is transmitted, but not processed correctly due
to the wrong BSSID (or even just discarded entirely). As a
result, the BA sessions are kept alive; however, as other
state is reset during HW restart, this then fails (reorder,
etc.) and data doesn't go through until new BA sessions are
established.
Dmitry Antipov [Fri, 17 May 2024 15:33:31 +0000 (18:33 +0300)]
wifi: cfg80211: use __counted_by where appropriate
Annotate 'sub_specs' of 'struct cfg80211_sar_specs', 'channels'
of 'struct cfg80211_sched_scan_request', 'channels' of 'struct
cfg80211_wowlan_nd_match', and 'matches' of 'struct
cfg80211_wowlan_nd_info' with '__counted_by' attribute. Briefly
tested with clang 18.1.1 and CONFIG_UBSAN_BOUNDS running iwlwifi.
Johannes Berg [Mon, 6 May 2024 19:54:52 +0000 (21:54 +0200)]
wifi: mac80211: refactor chanreq.ap setting
There are now three places setting up chanreq.ap which always
depends on the mode (EHT being used or not) and override flag.
Refactor that code into a common function with a comment, to
make that clearer.
Johannes Berg [Mon, 6 May 2024 19:54:50 +0000 (21:54 +0200)]
wifi: mac80211: handle wider bandwidth OFDMA during CSA
During channel switch, track the AP configuration in the
chanreq, so that wider bandwidth OFDMA is taken into
account correctly, since multiple channel contexts may
be needed due to sharing not being possible due to
wider bandwidth OFDMA.
Johannes Berg [Mon, 6 May 2024 19:54:49 +0000 (21:54 +0200)]
wifi: mac80211: collect some CSA data into sub-structs
Collect the CSA data in ieee80211_link_data_managed and
ieee80211_link_data into a csa sub-struct to clean up a
bit and make adding new things more obvious.
Johannes Berg [Mon, 15 Apr 2024 08:27:11 +0000 (11:27 +0300)]
wifi: mac80211: mlme: handle cross-link CSA
If we see a channel switch announcement on one link for
another, handle that case and start the CSA. The driver
can react to this in whatever way it needs. The stack
will have the ability to track it via the RNR/MLE in the
reporting link's beacon if it sees it for inactive links
and adjust everything accordingly.
Note that currently the timings for the CSA aren't set,
the values are only used by the Intel drivers, and they
don't need this for newer devices that support MLO, so
I've left it out for now.
Johannes Berg [Mon, 6 May 2024 19:11:59 +0000 (21:11 +0200)]
wifi: cfg80211: restrict operation during radar detection
Just like it's not currently possible to start radar
detection while already operating, it shouldn't be
possible to start operating while radar detection is
running. Fix that.
Also, improve the check whether operating (carrier
might not be up if e.g. attempting to join IBSS).
Johannes Berg [Mon, 6 May 2024 19:13:12 +0000 (21:13 +0200)]
wifi: mac80211: move radar detect work to sdata
At some point we thought perhaps this could be per link, but
really that didn't happen, and it's confusing. Radar detection
still uses the deflink to allocate the channel, but the work
need not be there. Move it back.
Miri Korenblit [Sun, 12 May 2024 12:24:59 +0000 (15:24 +0300)]
wifi: iwlwifi: mvm: don't skip link selection
If we exit EMLSR due to a IWL_MVM_ESR_EXIT*, a MLO scan followed by a
link selection is scheduled with a delay of 30 seconds.
If during that 30 seconds EMLSR was blocked and unblocked
(IWL_MVM_ESR_BLOCKED*), we would still want to get the needed data from
the MLO scan and select link accordingly, and not return immediately to
EMLSR.
Johannes Berg [Sun, 12 May 2024 12:24:56 +0000 (15:24 +0300)]
wifi: iwlwifi: tracing: fix condition to allocate buf1
There's no need to allocate buf1 if we're not going to
write anything to it, and the condition for writing is
(correctly) "hdr_len > 0 && !iwl_trace_data()". Also
allocate the event space only under the same condition.
Emmanuel Grumbach [Sun, 12 May 2024 04:58:57 +0000 (07:58 +0300)]
wifi: iwlwifi: mvm: leave a print in the logs when we call fw_nmi()
When we crash the firmware, we need to know why we decided to do so.
Almost all the callsites of iwl_force_nmi() print something in the logs
that explain why the driver decided to crash the firmware.
Debugfs doesn't print anything and it is then hard to understand why the
firmware has crashed.
Add a simple print in the debugfs hook to ease the debug.
Miri Korenblit [Sun, 12 May 2024 04:31:10 +0000 (07:31 +0300)]
wifi: iwlwifi: mvm: disable dynamic EMLSR when AUTO_EML is false
When AUTO_EML is set to false, this change ignores the exit criteria,
for testing purposes. Currently, if AUTO_EML is disabled, the
driver will not select a link or enter EMLSR, but will still exit if one
of the criteria is not fulfilled.
Johannes Berg [Sun, 12 May 2024 04:31:07 +0000 (07:31 +0300)]
wifi: iwlwifi: mvm: don't track used links separately
We track which link is using which FW link ID, so there
really isn't a need to separately track which link IDs
are in use. Remove that code and check the table when
looking for a new link ID to use.
Johannes Berg [Sun, 12 May 2024 04:31:03 +0000 (07:31 +0300)]
wifi: iwlwifi: fw: avoid bad FW config on RXQ DMA failure
In practice, iwl_trans_get_rxq_dma_data() will not fail,
it only can do that if called with the wrong arguments.
But it does have an error value and doesn't initialize
the argument when it fails, so don't use the value then.
The two versions of iwl_mei_set_power_limit() are a bit different,
and while really the const isn't all that necessary on the inline,
it's still better to have it be the same.
Johannes Berg [Sun, 12 May 2024 04:30:59 +0000 (07:30 +0300)]
wifi: iwlwifi: mvm: mark bad no-data RX as having bad PLCP
Just like with any other frame, mac80211 will do sanity checks
on no-data RX (representing e.g. sounding PPDUs), and if e.g.
the NSS is wrong, it will warn. This isn't a good idea if we
already know the frame wasn't received well, e.g. has bad PLCP.
Unless the firmware reports "no error", set the bad PLCP flag
to skip checks in mac80211.
Also, since we're now extracting two different values from the
info field, use le32_get_bits() for both.
Shahar S Matityahu [Fri, 10 May 2024 14:06:40 +0000 (17:06 +0300)]
wifi: iwlwifi: remove fw_running op
fw_running assumes that memory can be retrieved only after alive.
This assumption is no longer true as we support dump before alive.
To avoid invalid access to the NIC, check that STATUS_DEVICE_ENABLED
bit in trans status is set before dumping instead of the prior check.
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com> Reviewed-by: Luciano Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://msgid.link/20240510170500.ca07138cedeb.I090e31d3eaeb4ba19f5f84aba997ccd36927e9ac@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Andrei Otcheretianski [Fri, 10 May 2024 14:06:38 +0000 (17:06 +0300)]
wifi: iwlwifi: mvm: Don't set NO_HT40+/- flags on 6 GHz band
These flags are not needed on 6 GHz channels, and anyway they were set
incorrectly.
This in turn resulted in alternating channel flags, preventing reg domain
rules to be merged together, so cfg80211 couldn't even send them to the
user space, as the regulatory domain was too large.
Fix it.
Emmanuel Grumbach [Fri, 10 May 2024 14:06:30 +0000 (17:06 +0300)]
wifi: iwlwifi: mvm: simplify the uAPSD coexistence limitation code
uAPSD can't be enabled on BSS or P2P Client if there is
another active interface (e.g. associated client). Allow
the code that apply those limitations to run on BSS as well.
Also forbid uAPSD if we have an IBSS or NAN interface in
the system.
Since we are now forbidding uAPSD in any concurrency
scenario, we don't need to check the number of PHY
contexts.
Johannes Berg [Fri, 10 May 2024 14:06:28 +0000 (17:06 +0300)]
wifi: iwlwifi: dvm: clean up rs_get_rate() logic
The logic here is rather convoluted - we cannot get here with
lq_sta being NULL as mac80211 will (no longer) call us like
that, and since I removed the rate_control_send_low() call in
this function there's no longer any point in setting priv_sta
to NULL either.
So the only thing that remains to check is if we have actually
initialized our lq_sta->drv pointer, and exit if we didn't in
which case we'll use the data mac80211 already set up for the
low rate usage.
Johannes Berg [Mon, 6 May 2024 19:37:56 +0000 (21:37 +0200)]
wifi: mac80211: pass parsed TPE data to drivers
Instead of passing the full TPE elements, in all their glory
and mixed up data formats for HE backward compatibility, parse
them fully into the right values, and pass that to the drivers.
Also introduce proper validation already in mac80211, so that
drivers don't need to do it, and parse the EHT portions.
The code now passes the values in the right order according to
the channel used by an interface, which could also be a subset
of the data advertised by the AP, if we couldn't connect with
the full bandwidth (for whatever reason.)
Also add kunit tests for the more complicated bits of it.
Johannes Berg [Mon, 6 May 2024 19:37:55 +0000 (21:37 +0200)]
wifi: ath11k: fix TPE power levels
The chanctx can be shared, but it seems like the TPE values for
this vif should only reflect the channel that the vif uses, which
is captured in bss_conf->chanreq.oper rather than the chanctx.
Use that when calculating defaults, a similar issue is where the
data from the AP is processed, but I'm moving that to mac80211.
The define IEEE80211_MAX_NUM_PWR_LEVEL doesn't make much
sense. Yes, that table has a maximum value of 8, and the
table will actually remain that way, but EHT introduced
a way to encode more levels for 320 MHz channels.
Remove IEEE80211_MAX_NUM_PWR_LEVEL and, for ath11k being
the only user, add ATH11K_NUM_PWR_LEVELS, where it makes
sense since it cannot support 320 MHz channels.
Mukesh Sisodiya [Mon, 6 May 2024 19:37:53 +0000 (21:37 +0200)]
wifi: mac80211: update 6 GHz AP power type before association
6 GHz AP power type details are required to set proper tx power
used to send frames.
Update AP power type received in beacon while preparing
for connection instead of after association so the frames
before association can use the correct tx power.
Johannes Berg [Mon, 6 May 2024 19:00:03 +0000 (21:00 +0200)]
wifi: cfg80211: add tracing for wiphy work
Add trace events to trace when wiphy works are queued (or
delayed ones scheduled), and other APIs are called. Also
add an event when the worker starts, before acquiring the
mutex, to be able to see potential delays due to locking.
Johannes Berg [Wed, 15 May 2024 12:16:00 +0000 (14:16 +0200)]
wifi: nl80211: disallow setting special AP channel widths
Setting the AP channel width is meant for use with the normal
20/40/... MHz channel width progression, and switching around
in S1G or narrow channels isn't supported. Disallow that.
projects / users / jedix / linux-maple.git / log