Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260309083336.16397-1-johan@kernel.org
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260306093206.21081-1-johan@kernel.org
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260306085144.12064-18-johan@kernel.org
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260306085144.12064-17-johan@kernel.org
The local variables 'mcs' and 'nss' in rtl8xxxu_update_ra_report() are
passed to rtl8xxxu_desc_to_mcsrate() as output parameters. If the helper
function encounters an unhandled rate index, it may return without setting
these values, leading to the use of uninitialized stack data.
Remove the helper rtl8xxxu_desc_to_mcsrate() and inline the logic into
rtl8xxxu_update_ra_report(). This fixes the use of uninitialized 'mcs'
and 'nss' variables for legacy rates.
The new implementation explicitly handles:
- Legacy rates: Set bitrate only.
- HT rates (MCS0-15): Set MCS flags, index, and NSS (1 or 2) directly.
- Invalid rates: Return early.
Fixes: 7de16123d9 ("wifi: rtl8xxxu: Introduce rtl8xxxu_update_ra_report")
Cc: stable@vger.kernel.org
Suggested-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Yi Cong <yicong@kylinos.cn>
Link: https://lore.kernel.org/all/96e31963da0c42dcb52ce44f818963d7@realtek.com/
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260306071627.56501-1-cong.yi@linux.dev
The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and
scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware.
But it is never killed in rtl_pci_deinit(). When the rtlwifi card
probe fails or is being detached, the ieee80211_hw is deallocated.
However, irq_prepare_bcn_tasklet may still be running or pending,
leading to use-after-free when the freed ieee80211_hw is accessed
in _rtl_pci_prepare_bcn_tasklet().
Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to
ensure that irq_prepare_bcn_tasklet is properly terminated before
the ieee80211_hw is released.
The issue was identified through static analysis.
Fixes: 0c8173385e ("rtl8192ce: Add new driver")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260223045522.48377-1-duoming@zju.edu.cn
pci_upstream_bridge() returns NULL if the device is on a root bus. If
8821CE is installed in the system with such a PCI topology, the probing
routine will crash. This has probably been unnoticed as 8821CE is mostly
supplied in laptops where there is a PCI-to-PCI bridge located upstream
from the device. However the card might be installed on a system with
different configuration.
Check if the bridge does exist for the specific workaround to be applied.
Found by Linux Verification Center (linuxtesting.org) with Svace static
analysis tool.
Fixes: 24f5e38a13 ("rtw88: Disable PCIe ASPM while doing NAPI poll on 8821CE")
Cc: stable@vger.kernel.org
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260220094730.49791-1-pchelkin@ispras.ru
If entering LPS during SER (system error recovery), IMR might fail to
be re-enabled after SER. Then, the next SER would not be noticed well.
After FW v0.35.100.0, Wi-Fi 7 chipsets adjust the order in which SER
recovers DMAC state to prevent LPS from being in the middle of SER.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260213061552.29997-13-pkshih@realtek.com
Some chipsets, e.g. Wi-Fi 7, will not record SER (system error recovery),
which are triggered by simulations, in the HW counters. Their HW counters
only record the SER happen in field. However for verification, it's still
needed to check if simulations are triggered. So, add SW counters to count
any causes that SER happen. But, SW can only count L1 and L2. SW does not
involve L0 SER, so SW cannot count it.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260213061552.29997-11-pkshih@realtek.com
More data will be included in Firmware file and loaded via FW elements.
Unlike other chips, for RF radio, RTL8852A uses rtw89_phy_config_rf_reg
instead of v1, so update loading handling of corresponding FW element.
And then, increase RTL8852A FW format to 1 to prevent old driver from
misusing the data in FW elements.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260213061552.29997-7-pkshih@realtek.com
Now, most of PHY parameter tables in driver can be loaded via FW elements.
Plan to generate the corresponding FW elements for 8852A PHY tables. Then,
after FW elements work for a enough time, rtw8852a_table.c can be cleaned
up. However, DIG (dynamic initial gain) tables are legacy for 8852A only,
so FW element doesn't support. Their sizes are not very big, so move them
to rtw8852a.c and keep rtw8852a_table.c for PHY tables which are supported
by FW elements.
No logic is changed.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260213061552.29997-6-pkshih@realtek.com
Module firmware string depends on max format of the firmware. When max
format is 0, the module firmware string will be like XYZ.bin. However,
when max format N > 0, the module firmware string will become XYZ-N.bin.
Originally, when one chip updated its max firmware format from 0 to 1,
the module firmware string also needed to be changed. However, did not
need to do for other cases, e.g. from 1 to 2. It's a bit inconvenient
to always remember that from 0 to 1 is a special case.
So, add a general macro to generate the corresponding module firmware
string based on max firmware format.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260213061552.29997-4-pkshih@realtek.com
When Wi-Fi enters power save, the register value can not be read
correctly. If mechanism take the wrong information to make decision,
it will run with wrong parameters. It leads Bluetooth low-energy
HID lag. Add logic to isolate the wrong register state.
BTCOEX Version: 26020420-2020
Desired_BT_Coex_Ver: 0x20
Desired_WL_FW_Ver: 9.9.X
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260213053445.19384-1-pkshih@realtek.com
RTL8851BU and RTL8852BU currently have much lower TX speed than
expected, ~100 and ~300 Mbps, respectively. This is because part of the
chip's memory is allocated for some unknown firmware features instead of
the TX buffers.
The vendor drivers have a module parameter called "rtw_quota_turbo_en",
which can be used to choose between full TX speed or the unknown
firmware features. It is on by default.
Change the relevant chip parameters to implement the turbo mode. Do it
only for USB because PCI is already fast even without the turbo mode.
It's unclear if SDIO will need it or not.
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/88cce107-ff52-496f-bb77-b930e4182b67@gmail.com
Advertise support for IEEE 802.1X authentication protocol directly from
mac80211, without depending on driver indication of (Re)Association
frame encryption capability.
As specified in "IEEE P802.11bi/D4.0, clauses 12.16.5 and 12.16.8.2",
IEEE 802.1X authentication can operate with or without (Re)Association
frame encryption support. Therefore, mac80211 can safely advertise
802.1X support independently of driver capabilities.
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
Link: https://patch.msgid.link/20260226185553.1516290-6-kavita.kavita@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for the IEEE 802.1X authentication protocol in non-AP STA
mode, as specified in "IEEE P802.11bi/D4.0, 12.16.5".
IEEE 802.1X authentication involves multiple Authentication frame
exchanges, with the non-AP STA and AP alternating transaction
sequence numbers. The number of Authentication frame exchanges
depends on the EAP method in use. For IEEE 802.1X authentication,
process only Authentication frames with the expected transaction
sequence number.
For IEEE 802.1X Authentication, Table 9-71 specifies that the
Encapsulation Length field as specified in Clause 9.4.1.82 shall be
present in all IEEE 802.1X Authentication frames. Drop the frame in
the mac80211 if the Encapsulation Length field is missing.
After receiving the final Authentication frame with status code
WLAN_STATUS_8021X_AUTH_SUCCESS from the AP, mac80211 marks the state
as authenticated, as it indicates the EAP handshake has completed
successfully over the Authentication frames as specified in
Clause 12.16.5.
In the PMKSA caching case, only two Authentication frames are
exchanged if the AP identifies a valid PMKSA, then as specified
in Clause 12.16.8.3, the AP shall set the Status Code to
WLAN_STATUS_SUCCESS in the final Authentication frame and must not
include an encapsulated EAPOL PDU. This frame will be the final
Authentication frame from the AP when PMKSA caching is enabled,
and mac80211 marks the state as authenticated.
In case of authentication success or failure, forward the
Authentication frame to userspace(e.g. wpa_supplicant), and let
userspace validate the Authentication frame from the AP as per the
specification.
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
Link: https://patch.msgid.link/20260226185553.1516290-5-kavita.kavita@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add an extended feature flag NL80211_EXT_FEATURE_IEEE8021X_AUTH to
allow a driver to indicate support for the IEEE 802.1X authentication
protocol in non-AP STA mode, as defined in
"IEEE P802.11bi/D4.0, 12.16.5".
In case of SME in userspace, the Authentication frame body is prepared
in userspace while the driver finalizes the Authentication frame once
it receives the required fields and elements. The driver indicates
support for IEEE 802.1X authentication using the extended feature flag
so that userspace can initiate IEEE 802.1X authentication.
When the feature flag is set, process IEEE 802.1X Authentication frames
from userspace in non-AP STA mode. If the flag is not set, reject
IEEE 802.1X Authentication frames.
Define a new authentication type NL80211_AUTHTYPE_IEEE8021X for
IEEE 802.1X authentication.
Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com>
Link: https://patch.msgid.link/20260226185553.1516290-4-kavita.kavita@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Per IEEE Std 802.11be-2024, 12.5.2.3.3, if the MPDU is an
individually addressed Data frame between an AP MLD and a
non-AP MLD associated with the AP MLD, then A1/A2/A3
will be MLD MAC addresses. Otherwise, Al/A2/A3 will be
over-the-air link MAC addresses.
Currently, during AAD and Nonce computation for software based
encryption/decryption cases, mac80211 directly uses the addresses it
receives in the skb frame header. However, after the first
authentication, management frame addresses for non-AP MLD stations
are translated to MLD addresses from over the air link addresses in
software. This means that the skb header could contain translated MLD
addresses, which when used as is, can lead to incorrect AAD/Nonce
computation.
In the following manner, ensure that the right set of addresses are used:
In the receive path, stash the pre-translated link addresses in
ieee80211_rx_data and use them for the AAD/Nonce computations
when required.
In the transmit path, offload the encryption for a CCMP/GCMP key
to the hwsim driver that can then ensure that encryption and hence
the AAD/Nonce computations are performed on the frame containing the
right set of addresses, i.e, MLD addresses if unicast data frame and
link addresses otherwise.
To do so, register the set key handler in hwsim driver so mac80211 is
aware that it is the driver that would take care of encrypting the
frame. Offload encryption for a CCMP/GCMP key, while keeping the
encryption for WEP/TKIP and MMIE generation for a AES_CMAC or a
AES_GMAC key still at the SW crypto in mac layer
Co-developed-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com>
Signed-off-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260226042959.3766157-1-sai.magam@oss.qualcomm.com
[only store and apply link_addrs for unicast non-data
rather storing always and applying for !unicast_data]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, the unsolicited probe response template is always fetched from
the default link of a virtual interface in both Multi-Link Operation (MLO)
and non-MLO cases. However, in the MLO case there is a need to fetch the
unsolicited probe response template from a specific link instead of the
default link.
Hence, add support for fetching the unsolicited probe response template
based on the link ID from the corresponding link data.
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
Link: https://patch.msgid.link/20260220-fils-prob-by-link-v1-2-a2746a853f75@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The sequence of operations that needs to be done in wiphy_suspend is
identical for the case where there is no wowlan configured, and for the
case that it is but the driver refused to do wowlan (by returning 1 from
rdev_suspend).
The current code duplicates this set of operations for each one of the
cases.
In particular, next patch will change the locking of cfg80211_leave_all to
not hold the wiphy lock, which will be easier to do if it is not called
twice.
Change the code to handle first the case that wowlan is configured, and
then handle both cases (driver refused to do wowlan and no wowlan
configured) in one place.
Note that this changes the behaviour to set suspended=true also when
we were not registered yet, but that makes sense anyway, as wiphy works
can be queued also before registration.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260108102921.00336669ac32.Id76f272662e1315cd93a628808cc2d1625036b00@changeid
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://patch.msgid.link/20260219094725.3846371-2-miriam.rachel.korenblit@intel.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
-Wflex-array-member-not-at-end was introduced in GCC-14, and we are
getting ready to enable it, globally.
Move the conflicting declarations (which in a couple of cases happen
to be in a union, so the entire unions are moved) to the end of the
corresponding structures, struct il_frame, and struct il3945_frame.
Notice that `struct il_tx_beacon_cmd`, `struct il4965_tx_resp`, and
`struct il3945_tx_beacon_cmd` are flexible structures, this is
structures that contain a flexible-array member.
The case for struct il4965_beacon_notif is different. Since this
structure is defined by hardware, we create the new `struct
il4965_tx_resp_hdr` type. We then use this newly created type to
replace the object type causing trouble in struct il4965_beacon_notif,
namely `struct il4965_tx_resp`.
Also, once -fms-extensions is enabled, we can use transparent struct
members in struct il4965_tx_resp.
Notice that the newly created type does not contain the flex-array
member `agg_status`, which is the object causing the -Wfamnae warnings.
This object is currently in a union along with `__le32 status`, so
anything using struct il4965_beacon_notif needs to have its own view
of `status`. To preserve the memory layout, we therefore add member
`__le32 beacon_tx_status` to struct il4965_beacon_notif.
After these changes, the size of struct il4965_beacon_notif along
with its member's offsets remain the same, hence the memory layout
doesn't change:
Before changes:
struct il4965_beacon_notif {
struct il4965_tx_resp beacon_notify_hdr; /* 0 24 */
__le32 low_tsf; /* 24 4 */
__le32 high_tsf; /* 28 4 */
__le32 ibss_mgr_status; /* 32 4 */
/* size: 36, cachelines: 1, members: 4 */
/* last cacheline: 36 bytes */
};
After changes:
struct il4965_beacon_notif {
struct il4965_tx_resp_hdr beacon_notify_hdr; /* 0 20 */
__le32 beacon_tx_status; /* 20 4 */
__le32 low_tsf; /* 24 4 */
__le32 high_tsf; /* 28 4 */
__le32 ibss_mgr_status; /* 32 4 */
/* size: 36, cachelines: 1, members: 5 */
/* last cacheline: 36 bytes */
};
Lastly, adjust the rest of the code, accordingly.
With these changes fix the following warnings:
11 drivers/net/wireless/intel/iwlegacy/common.h:526:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
11 drivers/net/wireless/intel/iwlegacy/commands.h:2667:31: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
4 drivers/net/wireless/intel/iwlegacy/3945.h:131:11: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/aZLienEatf9KC6Rx@kspp
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, when sending a NULL frame to probe a station, the band
information is derived from the chanctx_conf in the mac80211 vif's
bss_conf. However, for AP MLD, chanctx_conf is not assigned to the
vif's bss_conf; instead it is assigned on a per-link basis. As a result,
for AP MLD, sending a NULL packet to probe will trigger a warning.
WARNING: net/mac80211/cfg.c:4635 at ieee80211_probe_client+0x1a8/0x1d8 [mac80211], CPU#2: hostapd/244
Call trace:
ieee80211_probe_client+0x1a8/0x1d8 [mac80211] (P)
nl80211_probe_client+0xac/0x170 [cfg80211]
genl_family_rcv_msg_doit+0xc8/0x134
genl_rcv_msg+0x200/0x280
netlink_rcv_skb+0x38/0xf0
genl_rcv+0x34/0x48
netlink_unicast+0x314/0x3a0
netlink_sendmsg+0x150/0x390
____sys_sendmsg+0x1f4/0x21c
___sys_sendmsg+0x98/0xc0
__sys_sendmsg+0x74/0xcc
__arm64_sys_sendmsg+0x20/0x34
invoke_syscall.constprop.0+0x4c/0xd0
do_el0_svc+0x3c/0xd0
el0_svc+0x28/0xc0
el0t_64_sync_handler+0x98/0xdc
el0t_64_sync+0x154/0x158
---[ end trace 0000000000000000 ]---
For NULL packets sent to probe stations, set the band information only
for non-MLD, since MLD transmissions does not rely on band.
Signed-off-by: Suraj P Kizhakkethil <suraj.kizhakkethil@oss.qualcomm.com>
Link: https://patch.msgid.link/20260213100126.1414398-2-suraj.kizhakkethil@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The mwifiex_adapter_cleanup() function uses timer_delete()
(non-synchronous) for the wakeup_timer before the adapter structure is
freed. This is incorrect because timer_delete() does not wait for any
running timer callback to complete.
If the wakeup_timer callback (wakeup_timer_fn) is executing when
mwifiex_adapter_cleanup() is called, the callback will continue to
access adapter fields (adapter->hw_status, adapter->if_ops.card_reset,
etc.) which may be freed by mwifiex_free_adapter() called later in the
mwifiex_remove_card() path.
Use timer_delete_sync() instead to ensure any running timer callback has
completed before returning.
Fixes: 4636187da6 ("mwifiex: add wakeup timer based recovery mechanism")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Hodges <git@danielhodges.dev>
Link: https://patch.msgid.link/20260206194401.2346-1-git@danielhodges.dev
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix:
- Send CAC_ABORT event when background CAC is canceled
- Cancel CAC done workqueue when radar is detected
- Release background wdev ownership when CAC is aborted or passed
- Clean lower layer background radar state when CAC is aborted or passed
- Prevent sending abort event when radar event is sent
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Link: https://patch.msgid.link/20260206171830.553879-2-janusz.dziedzic@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In mwifiex_11n_aggregate_pkt(), skb_aggr is allocated via
mwifiex_alloc_dma_align_buf(). If mwifiex_is_ralist_valid() returns false,
the function currently returns -1 immediately without freeing the
previously allocated skb_aggr, causing a memory leak.
Since skb_aggr has not yet been queued via skb_queue_tail(), no other
references to this memory exist. Therefore, it has to be freed locally
before returning the error.
Fix this by calling mwifiex_write_data_complete() to free skb_aggr before
returning the error status.
Compile tested only. Issue found using a prototype static analysis tool
and code review.
Fixes: 5e6e3a92b9 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Reviewed-by: Jeff Chen <jeff.chen_1@nxp.com>
Link: https://patch.msgid.link/20260119092625.1349934-1-zilin@seu.edu.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
