Sarika Sharma [Thu, 13 Feb 2025 17:16:22 +0000 (22:46 +0530)]
wifi: mac80211: refactor populating mesh related fields in sinfo
Introduce the sta_set_mesh_sinfo() to populate mesh related
fields in sinfo structure for station statistics.
This will allow for the simplified population of other fields in the
sinfo structure for link level in a subsequent patch to add support
for MLO station statistics.
No functionality changes added.
Sarika Sharma [Thu, 13 Feb 2025 17:16:21 +0000 (22:46 +0530)]
wifi: cfg80211: reorg sinfo structure elements for mesh
Currently, as multi-link operation(MLO) is not supported for mesh,
reorganize the sinfo structure for mesh-specific fields and embed
mesh related NL attributes together in organized view.
This will allow for the simplified reorganization of sinfo structure
for link level in a subsequent patch to add support for MLO station
statistics.
No functionality changes added.
Pahole summary before the reorg of sinfo structure:
- size: 256, cachelines: 4, members: 50
- sum members: 239, holes: 4, sum holes: 17
- paddings: 2, sum paddings: 2
- forced alignments: 1, forced holes: 1, sum forced holes: 1
Pahole summary after the reorg of sinfo structure:
- size: 248, cachelines: 4, members: 50
- sum members: 239, holes: 4, sum holes: 9
- paddings: 2, sum paddings: 2
- forced alignments: 1, last cacheline: 56 bytes
Emmanuel Grumbach [Wed, 12 Feb 2025 05:43:27 +0000 (07:43 +0200)]
wifi: iwlwifi: add support for external 32 KHz clock
In case the BIOS allows it, instruct the firmware to use the external 32
KHz clock.
The op mode specific implementation (i.e. reading the BIOS table) will
come in a later patch.
Miri Korenblit [Wed, 12 Feb 2025 05:43:26 +0000 (07:43 +0200)]
wifi: iwlwifi: mld: add a debug level for EHT prints
This is required for EHT related debug prints.
As there are no more available debug levels, delete IWL_DL_EXTERNAL,
which is not used, and replace it with IWL_DL_EHT.
Avraham Stern [Wed, 12 Feb 2025 05:43:22 +0000 (07:43 +0200)]
wifi: iwlwifi: location api cleanup
Remove the version suffix from the latest version of the range
request command structs and the range response notification structs.
In addition, don't use MVM in the API file as it is not MVM specific.
Benjamin Berg [Wed, 12 Feb 2025 06:22:58 +0000 (08:22 +0200)]
wifi: cfg80211: expose update timestamp to drivers
This information is exposed to userspace but not drivers. Make this
field public so that drivers are also able to access it. The information
is for example useful for link selection to determine whether the BSS
corresponding to an MLO link has been seen in a recent scan.
Gavrilov Ilia [Wed, 12 Feb 2025 08:21:25 +0000 (08:21 +0000)]
wifi: mac80211: fix integer overflow in hwmp_route_info_get()
Since the new_metric and last_hop_metric variables can reach
the MAX_METRIC(0xffffffff) value, an integer overflow may occur
when multiplying them by 10/9. It can lead to incorrect behavior.
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with SVACE.
Fixes: a8d418d9ac25 ("mac80211: mesh: only switch path when new metric is at least 10% better") Cc: stable@vger.kernel.org Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov@infotecs.ru> Link: https://patch.msgid.link/20250212082124.4078236-1-Ilia.Gavrilov@infotecs.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Ilan Peer [Fri, 14 Feb 2025 07:47:21 +0000 (09:47 +0200)]
wifi: mac80211: Fix possible integer promotion issue
Fix a possible integer promotion issue in mac80211 in ieee80211_ml_epcs()
Fixes: de86c5f60839 ("wifi: mac80211: Add support for EPCS configuration") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20250214074721.1613549-1-ilan.peer@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Easwar Hariharan [Wed, 19 Feb 2025 20:32:40 +0000 (20:32 +0000)]
wifi: cfg80211: convert timeouts to secs_to_jiffies()
Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies(). As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:
Alexander Wetzel [Thu, 20 Feb 2025 09:41:39 +0000 (10:41 +0100)]
wifi: mac80211: Add counter for all monitor interfaces
Count open monitor interfaces regardless of the monitor interface type.
The new counter virt_monitors takes over counting interfaces depending
on the virtual monitor interface while monitors is used for all active
monitor interfaces.
This fixes monitor packet mirroring when using MONITOR_FLAG_ACTIVE or
NO_VIRTUAL_MONITOR interfaces.
Fixes: 286e69677065 ("wifi: mac80211: Drop cooked monitor support") Reported-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Closes: https://lore.kernel.org/r/cc715114-4e3b-619a-49dc-a4878075e1dc@quicinc.com Signed-off-by: Alexander Wetzel <Alexander@wetzel-home.de> Tested-by: Karthikeyan Periyasamy <quic_periyasa@quicinc.com> Link: https://patch.msgid.link/20250220094139.61459-1-Alexander@wetzel-home.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johannes Berg [Wed, 5 Feb 2025 12:55:48 +0000 (14:55 +0200)]
wifi: iwlwifi: implement dump region split
Due to hardware design constraints, a reset handshake may be
necessary even when the firmware has already crashed, with
the dump descriptions indicating which parts should be done
before/after the handshake, if needed. Implement that.
Emmanuel Grumbach [Wed, 5 Feb 2025 12:55:42 +0000 (14:55 +0200)]
wifi: iwlwifi: make no_160 more generic
We'll have devices that are EHT capable but don't support 320 MHz and
those devices look like the 320 MHz capable devices, but have distinct
subsystem ID.
We already had the same type of differentiation for HE devices that
support 160 MHz or not.
Enhance that mechanism and now the _IWL_DEV_INFO macro gets an
indication whether the bandwidth should be limited for that specific
device.
The subsystem ID gives a binary answer about the bandwidth limitation
and iwl_pci_find_dev_info() compares this to the list of _IWL_DEV_INFO
entries.
Emmanuel Grumbach [Wed, 5 Feb 2025 12:55:41 +0000 (14:55 +0200)]
wifi: iwlwifi: be less aggressive with re-probe
Re-probing if we had 2 firmware crash within 3 minutes is really too
aggressive. Drastically reduce the threshold to 7 seconds.
After 7 seconds, a new firmware crash will be considered "new" and not
cause a PCI re-probe.
This allows to pass tests that cause a firmware crash every 10 seconds
and expect to see no impact on the traffic.
Johannes Berg [Wed, 5 Feb 2025 12:55:37 +0000 (14:55 +0200)]
wifi: iwlwifi: cfg: separate 22000/BZ family HT params
We're adding a new IWLMLD opmode for just BZ and later
devices. If that's enabled but IWLMVM isn't, the build
fails because 22000 family configs aren't built but BZ
and later refer to it. Rather than trying to make some
new file to build it in all cases, just copy the small
struct.
Johannes Berg [Wed, 5 Feb 2025 12:55:36 +0000 (14:55 +0200)]
wifi: iwlwifi: enable 320 MHz on slow PCIe links
Despite not being able to sustain the full 320 MHz throughput
even at MCS 9, enable 320 MHz on slow PCIe links. This may in
some cases result in frames being dropped (on the air) by the
firmware if they cannot be delivered to the host, but it can
still be better to use 320 MHz.
Miri Korenblit [Wed, 5 Feb 2025 12:55:35 +0000 (14:55 +0200)]
wifi: iwlwifi: don't warn during reprobe
During reprobe, the sw state is being destroyd, and so is the
connection. When the peer STA is being removed, the opmode sends a
command to flush the TXQs of the STA and uses iwl_trans_wait_txq_empty.
This one warns if the FW is not alive, but it really shouldn't if
there is a FW error - and return silently instead, just like we do when
sending a hcmd.
Anjaneyulu [Wed, 5 Feb 2025 12:55:34 +0000 (14:55 +0200)]
wifi: iwlwifi: Unify TAS block list handling in regulatory.c
Created a common function iwl_add_mcc_to_tas_block_list() to handle the
operations previously performed by iwl_mld_add_to_tas_block_list() and
iwl_mvm_add_to_tas_block_list(). moved this new function to regulatory.c
to better reflect its purpose and improve code organization.
Anjaneyulu [Wed, 5 Feb 2025 12:55:33 +0000 (14:55 +0200)]
wifi: iwlwifi: mvm: rename and move iwl_mvm_eval_dsm_rfi() to iwl_rfi_is_enabled_in_bios()
Renamed iwl_mvm_eval_dsm_rfi() to iwl_rfi_is_enabled_in_bios() to better
reflect the function's operation. Additionally, moved the function to the
regulatory.c file for better organization. optimize local variable
usage in it.
Salvatore Bonaccorso [Wed, 5 Feb 2025 11:06:14 +0000 (12:06 +0100)]
wifi: b43: Replace outdated firmware URL
https://wireless.wiki.kernel.org site now redirects to
https://wireless.docs.kernel.org/en/latest/ making the reference
information for the b43 firmware inaccessible. Update the URL to the
current location.
Emmanuel Grumbach [Wed, 5 Feb 2025 09:39:27 +0000 (11:39 +0200)]
wifi: mac80211: rework the Tx of the deauth in ieee80211_set_disassoc()
When we disassociate we may need to send a deauth frame.
Regardless of this decision, we need to flush the queues to drop all the
packets on the Tx queues.
The flow looks like this:
1) Flush packets waiting on the queues (drop=true)
2) Prepare Tx to send the deauth
3) Build the deauth header
4) send the deauth
5) Flush the deauth packet (drop=false)
6) Complete_tx
Step 3 and 4 are done in ieee80211_send_deauth_disassoc() and that
function must be called even if we decide not to send the deauth
frame because we need step 3 for cfg80211.
This means that if we want to send the deauth frame, we need all the
steps, but if we don't want to send the deauth frame we still want step
1 and 3.
Change the code to do that.
Also, prevent sending the deauth frame if we are in the middle of a CSA
with mode=1 in which case we won't be able to send the frame anyway.
This caused issues in iwlwifi at step 5 since the firmware wouldn't
send the frame and we'd be stuck flushing with drop=false.
Implement this in ieee80211_set_disassoc() which has many callers.
Miri Korenblit [Wed, 5 Feb 2025 09:39:26 +0000 (11:39 +0200)]
wifi: mac80211: ensure sdata->work is canceled before initialized.
This wiphy work is canceled when the iface is stopped,
and shouldn't be queued for a non-running iface.
If it happens to be queued for a non-running iface (due to a bug)
it can cause a corruption of wiphy_work_list when ieee80211_setup_sdata
is called. Make sure to cancel it in this case and warn on.
Johannes Berg [Wed, 5 Feb 2025 09:39:25 +0000 (11:39 +0200)]
wifi: mac80211: enable removing assoc link
With the previous patch to no longer access deflink for aggregation
it seems we no longer access the deflink for MLO stations (MLDs) so
we can allow removing the assoc link.
Johannes Berg [Wed, 5 Feb 2025 09:39:24 +0000 (11:39 +0200)]
wifi: mac80211: aggregation: remove deflink accesses for MLO
If a station has connected with MLO (as indicated by valid_links
being non-zero, even if that may have just a single bit set), it
necessarily supports EHT/aggregation, so we don't need to check
the deflink for those cases.
Add conditions so we can support removing the link it/we used to
associate on.
Note that we still use the statistics in the deflink, but that's
a whole different story we will need to address separately.
In the original commit 15fae3410f1d ("mac80211: notify driver on
mgd TX completion") I evidently made a mistake and placed the
call in the "associated" if, rather than the "assoc_data". Later
I noticed the missing call and placed it in commit c042600c17d8
("wifi: mac80211: adding missing drv_mgd_complete_tx() call"),
but didn't remove the wrong one. Remove it now.
Emmanuel Grumbach [Wed, 5 Feb 2025 09:39:20 +0000 (11:39 +0200)]
wifi: mac80211: set ieee80211_prep_tx_info::link_id upon Auth Rx
This will be used by the low level driver.
Note that link_id will be 0 in case of a non-MLO authentication.
Also fix a call-site of mgd_prepare_tx() where the link_id was not
populated.
Update the documentation to reflect the current state
ieee80211_prep_tx_info::link_id is also available in mgd_complete_tx().
Benjamin Berg [Wed, 5 Feb 2025 09:39:19 +0000 (11:39 +0200)]
wifi: mac80211: tests: add tests for ieee80211_determine_chan_mode
Add a few tests for ieee80211_determine_chan_mode that check that
mac80211 will not try to connect to an AP if an advertised basic rate is
not supported.
Benjamin Berg [Wed, 5 Feb 2025 09:39:18 +0000 (11:39 +0200)]
wifi: mac80211: add HT and VHT basic set verification
So far we did not verify the HT and VHT basic MCS set. However, in
P802.11REVme/D7.0 (6.5.4.2.4) says that the MLME-JOIN.request shall
return an error if the VHT and HT basic set requirements are not met.
Given broken APs, apply VHT basic MCS/NSS set checks only in
strict mode.
Add a strict mode where we disable certain workarounds and have
additional checks such as, for now, that VHT capabilities from
association response match those from beacon/probe response. We
can extend the checks in the future.
Make it an opt-in setting by the driver so it can be set there
in some driver-specific way, for example. Also allow setting
this one hw flag through the hwflags debugfs, by writing a new
strict=0 or strict=1 value.
Ilan Peer [Wed, 5 Feb 2025 09:39:13 +0000 (11:39 +0200)]
wifi: mac80211: Add support for EPCS configuration
Add support for configuring EPCS state:
- When EPCS is enabled, send an EPCS enable request action frame
to the AP. When the AP replies with EPCS enable response, enable
EPCS by applying the QoS parameters provided by the AP. Do so for
all the valid MLD links. Once EPCS is enabled, support processing
of unsolicited EPCS enable response frames.
- When EPCS is disabled, send an EPCS teardown request to the AP
and apply the QoS parameters as obtained from the last received
beacons. Do so for all the valid links.
The function first updates the link configuration and then
calls the driver to set the link parameters. Since the call
to the driver might sleep, split the function such that
the link configuration could be done without calling the
driver. This would be useful in cases that WMM parameters
need to be configured, but the current locking doesn't allow
to call the driver.
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
So, in order to avoid ending up with a flexible-array member in the
middle of other structs, we use the `__struct_group()` helper to
create a new tagged `struct qlink_tlv_hdr_fixed`. This structure
groups together all the members of the flexible `struct qlink_tlv_hdr`
except the flexible array.
As a result, the array is effectively separated from the rest of the
members without modifying the memory layout of the flexible structure.
We then change the type of the middle struct member currently causing
trouble from `struct qlink_tlv_hdr` to `struct qlink_tlv_hdr_fixed`.
We also want to ensure that when new members need to be added to the
flexible structure, they are always included within the newly created
tagged struct. For this, we use `static_assert()`. This ensures that
the memory layout for both the flexible structure and the new tagged
struct is the same after any changes.
This approach avoids having to implement `struct qlink_tlv_hdr_fixed`
as a completely separate structure, thus preventing having to maintain
two independent but basically identical structures, closing the door
to potential bugs in the future.
So, with this changes, fix 66 of the following warnings:
drivers/net/wireless/quantenna/qtnfmac/qlink.h:1681:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/quantenna/qtnfmac/qlink.h:1660:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/quantenna/qtnfmac/qlink.h:1646:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/quantenna/qtnfmac/qlink.h:1621:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/quantenna/qtnfmac/qlink.h:1609:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
drivers/net/wireless/quantenna/qtnfmac/qlink.h:1570:30: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Alexander Wetzel [Tue, 4 Feb 2025 11:13:52 +0000 (12:13 +0100)]
wifi: mac80211: Drop cooked monitor support
Hostapd switched from cooked monitor interfaces to nl80211 Dec 2011.
Drop support for the outdated cooked monitor interfaces and fix
creating the virtual monitor interfaces in the following cases:
1) We have one non-monitor and one monitor interface with
%MONITOR_FLAG_ACTIVE enabled and then delete the non-monitor
interface.
2) We only have monitor interfaces enabled on resume while at least one
has %MONITOR_FLAG_ACTIVE set.
Unconditionally start to refuse creating cooked monitor interfaces to
phase them out.
There is no feature flag for drivers to opt-in for cooked monitor and
all known users are using/preferring the modern API since the hostapd
release 1.0 in May 2012.
Catalin Popescu [Thu, 16 Jan 2025 08:47:02 +0000 (09:47 +0100)]
net: rfkill: gpio: allow booting in blocked state
By default, rfkill state is unblocked and this behavior is not
configurable. Add support for booting in blocked state based on the
presence of a devicetree property.
Dr. David Alan Gilbert [Mon, 23 Dec 2024 01:32:02 +0000 (01:32 +0000)]
wifi: iwlwifi: Remove old device data
The last use of iwl_ax204_name[], iwl_ax221_name[] and iwl_cfg_so_a0_ms_a0
was removed by
commit f473a7fd6d60 ("wifi: iwlwifi: remove devices that never came out")
iwl_mvm_ftm_add_pasn_sta() was added in 2020 by
commit 0739a7d70e00 ("iwlwifi: mvm: initiator: add option for adding a
PASN responder")
but hasn't been used.
Remove it.
That was the only caller of iwl_mvm_ftm_remove_pasn_sta().
iwl_mvm_ftm_respoder_add_pasn_sta() and
iwl_mvm_ftm_resp_remove_pasn_sta() were added in 2020 by
commit be82ecd3a5c8 ("iwlwifi: mvm: add an option to add PASN station")
but have remained unused.
Remove them.
After that removal iwl_mvm_add_pasn_sta() is now unused.
Remove it.
Ping-Ke Shih [Mon, 10 Feb 2025 12:31:05 +0000 (20:31 +0800)]
wifi: rtw89: debugfs depends on CFG80211's one
The wiphy_locked_debugfs_read() and wiphy_locked_debugfs_write() used
by rtw89 are defined if CFG80211_DEBUGFS enabled. Add the dependency
accordingly.
Fixes: 8fdf78f3cd5f ("wifi: rtw89: debugfs: use wiphy_locked_debugfs_{read,write}() if needed") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502101810.3CUpUL7p-lkp@intel.com/ Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250210123105.10466-1-pkshih@realtek.com
Bitterblue Smith [Tue, 4 Feb 2025 18:39:29 +0000 (20:39 +0200)]
wifi: rtw88: Extend rtw_fw_send_ra_info() for RTL8814AU
The existing code is suitable for chips with up to 2 spatial streams.
Inform the firmware about the rates it's allowed to use when
transmitting 3 spatial streams.
Bitterblue Smith [Tue, 4 Feb 2025 18:37:36 +0000 (20:37 +0200)]
wifi: rtw88: Fix download_firmware_validate() for RTL8814AU
After the firmware is uploaded, download_firmware_validate() checks some
bits in REG_MCUFW_CTRL to see if everything went okay. The
RTL8814AU power on sequence sets bits 13 and 12 to 2, which this
function does not expect, so it thinks the firmware upload failed.
Make download_firmware_validate() ignore bits 13 and 12.
Bitterblue Smith [Tue, 4 Feb 2025 18:36:56 +0000 (20:36 +0200)]
wifi: rtw88: Fix __rtw_download_firmware() for RTL8814AU
Don't call ltecoex_read_reg() and ltecoex_reg_write() when the
ltecoex_addr member of struct rtw_chip_info is NULL. The RTL8814AU
doesn't have this feature.
Ping-Ke Shih [Wed, 5 Feb 2025 01:40:51 +0000 (09:40 +0800)]
wifi: rtw89: regd: avoid using BITMAP_FROM_U64() to assign function bitmap
Since there are two function features for now, func_bitmap[] has single
one element, which BITMAP_FROM_U64() generating two elements is exceeded.
Change to assign function bitmap barely.
With i386-allmodconfig (a 32 bit system), it throws
>> include/linux/bitmap.h:736:33: warning: excess elements in array initializer
736 | ((unsigned long) ((u64)(n) >> 32))
| ^
drivers/net/wireless/realtek/rtw89/regd.c:16:34: note: in expansion of macro 'BITMAP_FROM_U64'
16 | .func_bitmap = { BITMAP_FROM_U64(_fmap), }, \
| ^~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtw89/regd.c:20:9: note: in expansion of macro 'COUNTRY_REGD'
20 | COUNTRY_REGD("00", RTW89_WW, RTW89_WW, RTW89_WW, 0x0);
| ^~~~~~~~~~~~
Fixes: 79a36fc56bea ("wifi: rtw89: regd: handle supported regulatory functions by country") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502031932.BMQ4lhJT-lkp@intel.com/ Cc: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20250205014051.13765-1-pkshih@realtek.com
The TWS(True wireless stereo) serials Bluetooth audio device need to keep
packet traffic not only with DUT, it also need to synchronize packet with
its assistant earbud. And all the BR/EDR Bluetooth device need to do page
scan to keep re-connect event sensitively between different DUT.
These behavior will make TWS Bluetooth device cost more time slot to keep
the good audio performance. This patch decrease half of Wi-Fi slot(from
40ms to 20ms) in a single cycle. Make the slot more flexible to prevent
audio lag. The single cycle will be shorter, then it will bring some slot
protection cost make Wi-Fi throughput decrease about 5%.
Ping-Ke Shih [Mon, 3 Feb 2025 07:29:08 +0000 (15:29 +0800)]
wifi: rtw89: call power_on ahead before selecting firmware
Driver selects firmware by hardware version, which normally can be read
from registers before selecting firmware. However, certain chips such as
RTL8851B, it needs to read hardware version from efuse while doing
power_on, but do power_on after selecting firmware in current flow.
To resolve this flow problem, move power_on out from
rtw89_mac_partial_init(), and call rtw89_mac_pwr_on() separately at
proper places to have expected flow.
Soeren Moch [Mon, 27 Jan 2025 19:48:28 +0000 (20:48 +0100)]
wifi: rtl8xxxu: retry firmware download on error
Occasionally there is an EPROTO error during firmware download.
This error is converted to EAGAIN in the download function.
But nobody tries again and so device probe fails.
Implement download retry to fix this.
This error was observed (and fix tested) on a tbs2910 board [1]
with an embedded RTL8188EU (0bda:8179) device behind a USB hub.
Bitterblue Smith [Sun, 26 Jan 2025 14:04:21 +0000 (16:04 +0200)]
wifi: rtw88: Don't use static local variable in rtw8821c_set_tx_power_index_by_rate
Some users want to plug two identical USB devices at the same time.
This static variable could theoretically cause them to use incorrect
TX power values.
Move the variable to the caller and pass a pointer to it to
rtw8821c_set_tx_power_index_by_rate().
Bitterblue Smith [Sun, 26 Jan 2025 14:03:11 +0000 (16:03 +0200)]
wifi: rtw88: Don't use static local variable in rtw8822b_set_tx_power_index_by_rate
Some users want to plug two identical USB devices at the same time.
This static variable could theoretically cause them to use incorrect
TX power values.
Move the variable to the caller and pass a pointer to it to
rtw8822b_set_tx_power_index_by_rate().
Ezra Buehler [Wed, 22 Jan 2025 07:15:11 +0000 (15:15 +0800)]
wifi: rtl8xxxu: Enable AP mode for RTL8192CU (RTL8188CUS)
This allows the driver to be used in wireless access point mode on the
AT91SAM9G25-based GARDENA smart Gateway.
Unfortunately, the data throughput in AP mode appears to be lower than
with the vendor driver (or in STA mode). Especially when sending, the
data rate is significantly lower. My measurements performed with iperf3
and an Edimax EW-7811Un (VID: 7392, PID: 7811) showed a maximum TX rate
of about 4 Mbits/sec compared to the ~24 Mbits/sec measured with the
rtl8192cu driver.
Although the performance might be good enough for our use case, this is
something that should be further looked into.
Ping-Ke Shih [Wed, 22 Jan 2025 06:03:10 +0000 (14:03 +0800)]
wifi: rtw89: pci: not assert wiphy_lock to free early_h2c for PCI probe/remove
Except probe/remove flow, the consumers of early_h2c list are interface
start and debugfs. There must be no race between probe/remove flow and
interface start. The failed probe flow is to free early_h2c list as well
as remove flow, at these two moments debugfs doesn't present. Thus, it is
safe to free early_h2c list without held wiphy_lock in these situations.
projects / users / jedix / linux-maple.git / log