When geneve_configure() allocates a new geneve_config structure via
geneve_config_alloc() and assigns it to geneve->cfg before calling
register_netdevice(), if register_netdevice() fails early (for example,
in dev_get_valid_name() due to an invalid or duplicate interface name),
register_netdevice() exits without calling dev->priv_destructor.
The caller (e.g. rtnl_newlink()) subsequently calls free_netdev(), which
frees the net_device structure directly via kvfree() because reg_state is
NETREG_UNINITIALIZED, bypassing dev->priv_destructor (geneve_free_dev()).
As a result, the newly allocated geneve_config and its per-CPU dst_cache
are leaked.
Fix this by invoking geneve_free_dev(dev) directly on the error path of
register_netdevice(). Since geneve_free_dev() sets geneve->cfg to NULL,
this call is fully idempotent and safe even if register_netdevice()
failed on a later error path that already ran dev->priv_destructor.
Fixes: 0ba269933f ("geneve: convert config to RCU-protected pointer")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260721163950.1483019-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
There has been quite a bit of activity across the ath drivers.
Significant changes in ath12k include:
Align with new Qualcomm generic Peripheral Authentication Service (PAS).
Ongoing infrastructure changes to support the QCC2072 platform.
Ongoing infrastructure changes to support the IPQ5332 platform.
Enhance datapath statistics.
Tuning of datapath parameters.
In addition, an assortment of cleanups and minor bug fixes across ath6kl,
ath10k, ath11k, ath12k, and carl9170.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCamDp7AAKCRAsFbugiYzL
ezyJAQC6D29OEEnel7C3H4gPsLdF8oI3pszt9MHFAhKpqCh/7AEAzzuvfNVfewXU
WeP+bkfi+fLPSChX4UxWsw8xx4vVHgM=
=A8cC
-----END PGP SIGNATURE-----
Merge tag 'ath-next-20260722' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git patches for v7.3 (PR #1)
There has been quite a bit of activity across the ath drivers.
Significant changes in ath12k include:
Align with new Qualcomm generic Peripheral Authentication Service (PAS).
Ongoing infrastructure changes to support the QCC2072 platform.
Ongoing infrastructure changes to support the IPQ5332 platform.
Enhance datapath statistics.
Tuning of datapath parameters.
In addition, an assortment of cleanups and minor bug fixes across ath6kl,
ath10k, ath11k, ath12k, and carl9170.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Johan Alvarado says:
====================
net: dsa: realtek: rtl8365mb: add SGMII/HSGMII support for RTL8367S
The RTL8367S is a 5+2 port switch from the same family as the
RTL8365MB-VC already supported by this driver. Its chip info table
entry declares SGMII and HSGMII on external interface 1, but the
driver so far only implements RGMII, leaving boards that wire the
switch to the CPU over the SerDes without a working CPU port.
This series implements both modes. The configuration sequence and the
SerDes tuning parameters are derived from the GPL-licensed Realtek
rtl8367c vendor driver, as distributed in the Mercusys MR80X GPL code
drop, and cross-checked against the real register sequence captured at
runtime by chainloading a custom U-Boot ahead of the stock firmware
and logging the live SerDes accesses on hardware.
The vendor driver brings up the SerDes by loading firmware into the
switch's embedded DW8051 microcontroller. Analysis of that firmware
(by Luiz Angelo Daros de Luca) showed it only performs a SerDes
data-path reset right after the SerDes reset is deasserted, and then
runs a link-polling loop that writes the external interface force
registers -- duplicating, and racing with, the link management phylink
already performs. This series therefore keeps the DW8051 disabled and
performs the one necessary action (the data-path reset via the SerDes
BMCR register) directly in the driver, avoiding both the race and a
dependency on a redistributable firmware blob.
The SerDes is modelled as a phylink PCS: mac_select_pcs() hands the
SerDes interfaces to a phylink_pcs whose pcs_config()/pcs_link_up()
ops own the SerDes register sequence, keeping it out of the MAC
operations. In-band autonegotiation is not implemented; the link is
forced (fixed-link or conventional PHY), as for RGMII, and the PCS
reports this to phylink through pcs_inband_caps().
Patch 1 adds the SerDes indirect access helpers, the PCS and SGMII
(1 Gbps) support. Patch 2 extends the PCS to HSGMII (2.5 Gbps), which
phylink represents as 2500base-x.
Tested on a Mercusys MR80X v2.20 (RTL8367S wired to the SoC over the
SerDes), in both SGMII and HSGMII modes with a fixed-link device tree
description: link bring-up verified across cold boots, warm reboots,
module reloads and link down/up cycles, with sustained traffic and no
CRC/symbol errors. The SerDes pause enables were verified by driving
congestion toward a 100M user port and observing pause frame emission
on the CPU port (dot3OutPauseFrames) toggle with the SDS_MISC
TXFC/RXFC bits. The port 6 rate limiters were verified to be live by
lowering them to 100 Mbps at runtime and observing iperf3 throughput
across the CPU port clamp accordingly in each direction, recovering
once the maximum was restored. The HSGMII link is confirmed running
at 2.5G at the register level (SoC uniphy mode and gmac clocks);
per-direction throughput could not be pushed past ~1 Gbps on this
board because the SoC side is driven by the IPQ5018 SSDK and the
user-facing PHY is 1G, so full 2.5G line-rate throughput remains
unverified on my hardware. Independently, >1 Gbps aggregate HSGMII
throughput (~2 Gbps with multiple clients) has been observed on an
RTL8367S-based Mercusys MR85X running an OpenWrt backport of this
series with the rate limiters raised (see patch 2).
The RTL8367SB also declares SGMII and HSGMII in its chip info entry
and therefore gains both modes as well. The vendor driver drives the
two chips through the same code path, keyed only on the chip option
register (both report chip id 0x6367), so this is expected to work
there too, but I have no RTL8367SB hardware to confirm it.
====================
Link: https://patch.msgid.link/20260711-rtl8367s-sgmii-v6-0-88f7944ddca7@c127.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In addition to SGMII, the RTL8367S SerDes also supports HSGMII, which
carries 2.5 Gbps with the same signaling as SGMII at 2.5x clock rate.
The chip info table already declares HSGMII as a supported interface
mode for external interface 1.
Extend the SerDes PCS to handle HSGMII, which phylink represents as
2500base-x:
- Select the HSGMII SerDes tuning parameters and external interface
mode, and mux the SerDes to MAC8 in HSGMII mode, from pcs_config()
according to the interface. The parameters are again lifted from the
GPL-licensed Realtek rtl8367c vendor driver, and again only cover
the tuning variant for a non-zero chip option, so the mode is gated
on the option probed at setup.
- Advertise 2500base-x and MAC_2500FD on ports whose external
interface supports HSGMII.
- Accept SPEED_2500 in the forced link configuration. The MAC speed
field has no 2.5 Gbps value: the rate is determined by the HSGMII
SerDes configuration, and the vendor driver programs the 1 Gbps
value here, so do the same.
- Raise the port 6 ingress and egress rate limiters to their maximum
at setup time, as the vendor switch init does unconditionally for
the whole chip family. The chip resets them to 0x1FFFF (~1.048 Gbps
in units of 8 Kbps), which caps the aggregate HSGMII throughput at
roughly 1 Gbps. The vendor documentation describes the reset
default as disabling the limiter, but the cap is real: on an
RTL8367S-based Mercusys MR85X running an OpenWrt backport of this
series, several clients on 1 Gbps user ports were limited to about
1.02 Gbps combined across the HSGMII CPU port until these limiters
were raised, after which throughput reached about 2 Gbps [1]. The
related HSGMII scheduler line rate (LINE_RATE_HSG_H) is already set
to its maximum by the common init jam table.
Tested on a Mercusys MR80X v2.20, where the RTL8367S is connected to
the SoC over HSGMII.
Link: https://github.com/openwrt/openwrt/pull/19445#issuecomment-4505613294 [1]
Suggested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Suggested-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Johan Alvarado <contact@c127.dev>
Tested-by: Stanisław Pal <kuncy7@gmail.com>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Tested-by: Stanislaw Pal <kuncy7@gmail.com>
Link: https://patch.msgid.link/20260711-rtl8367s-sgmii-v6-2-88f7944ddca7@c127.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RTL8367S can mux its embedded SerDes to external interface 1,
which is typically used to connect the switch to a CPU port. The chip
info table already declares SGMII as a supported interface mode for
this chip, but the driver only implements RGMII so far.
Implement SGMII support as a phylink PCS, with the configuration
sequence derived from the GPL-licensed Realtek rtl8367c vendor driver
as distributed in the Mercusys MR80X GPL code drop:
- Add accessors for the SerDes indirect access registers (SDS_INDACS),
through which the SerDes internal registers are reached.
- Register a phylink_pcs for the SerDes, selected from mac_select_pcs
for the SGMII interface, so the SerDes handling lives in the PCS
operations rather than in the MAC operations.
- Probe the SerDes tuning variant from the chip option register once
at setup. The vendor driver keeps two sets of SerDes tuning
parameters and selects between them based on this option; only the
variant for a non-zero option (which all RTL8367S parts seen so far
report) has been validated on hardware, so the SerDes interface
modes are only advertised in that case. An unsupported variant thus
fails at phylink validation time instead of at link configuration
time.
- Keep the embedded DW8051 microcontroller in reset and disabled. The
vendor driver loads firmware into it to manage the SerDes link, but
analysis of that firmware shows it only duplicates the link
management phylink already performs: it polls the port status and
writes the external interface force registers behind the driver's
back.
- Clear the line rate bypass bit for the external interface, tune the
SerDes with the vendor-prescribed parameters, mux the SerDes to MAC8
in SGMII mode and only then take the SerDes out of reset, as the
vendor driver does.
- After deasserting the SerDes reset, reset the SerDes data path via
the SerDes BMCR register to flush the FIFOs and resync the PLL.
This mirrors what the vendor firmware does right after deasserting
the SerDes reset, and ensures a clean link state from cold boot.
- Force the SGMII link parameters (link, speed, duplex) in the SDS_MISC
register from pcs_link_up(). SGMII in-band autonegotiation is not
implemented, so only fixed-link and conventional PHY setups are
supported, just like RGMII. This is reported to phylink through
pcs_inband_caps() returning LINK_INBAND_DISABLE, so phylink never
selects an in-band-enabled negotiation mode for this PCS.
- Program the SerDes pause enables in SDS_MISC from the resolved
pause modes when forcing the MAC external interface in mac_link_up,
as the vendor driver does, rather than leaving whatever state the
boot firmware left there. Flow control testing shows these bits,
not the MAC force pause bits, gate pause on the SerDes external
interface. This is done in the MAC layer because pcs_link_up()
carries no pause information.
- Implement pcs_get_state() by reading the link status from the
SerDes, with the forced speed and duplex read back from SDS_MISC.
Although the supported fixed-link and conventional PHY setups do not
use it, the PCS owns the SerDes link state, and phylink consults
pcs_get_state() to track the physical link when operating in in-band
mode with autonegotiation disabled. The SerDes has no link interrupt
wired up, so the PCS sets its poll flag.
Tested on a Mercusys MR80X v2.20, where the RTL8367S is connected to
the SoC over SGMII.
Suggested-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Suggested-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Signed-off-by: Johan Alvarado <contact@c127.dev>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
Reviewed-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Tested-by: Stanislaw Pal <kuncy7@gmail.com>
Link: https://patch.msgid.link/20260711-rtl8367s-sgmii-v6-1-88f7944ddca7@c127.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add purwa-iot-evk and qcs6490-rb3gen2 platform support to the
usecase firmware lookup table for WCN6855 hw2.1.
These platforms use the nfa765 firmware path for usecase-based
firmware selection.
Also reorder the table entries by compatible string.
Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04685-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260713020359.3618193-1-miaoqing.pan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, in ath11k_wmi_tlv_op_rx(), the firmware buffer is read
without first verifying that the buffer has enough data to hold a
header. This could result in a buffer overread.
Add an upfront length check before dereferencing skb->data as a
wmi_cmd_hdr. The check is placed before the trace_ath11k_wmi_event()
call to preserve the existing trace semantics (tracing the full raw
WMI event including the header), unlike the analogous ath12k fix which
could use skb_pull_data() directly.
Compile tested only.
Fixes: d5c65159f2 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Assisted-by: Claude:claude-sonnet-4-6
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-ath11k_wmi_tlv_op_rx-overread-v1-1-0b972b3f1368@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, in ath12k_wmi_op_rx(), the firmware buffer is read without
first verifying that the buffer has enough data to hold a header. This
could result in a buffer overread.
Update the logic to verify the buffer contains at least enough data to
hold a wmi_cmd_hdr before reading from the buffer.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
Fixes: d889913205 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Assisted-by: Claude:claude-sonnet-4-6
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260716-ath12k_wmi_op_rx-overread-v1-1-327a4b1c2372@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
When running 'iw dev wlan0 survey dump' the values for the channel busy
time have the same sequence across bands. This is caused by indexing
into the ath12k survey array using a band-local index rather than the
global index passed by mac80211. This results in surveys for 5 GHz and 6
GHz channels returning values from 2.4 GHz slots, making the survey
unusable on those bands. Further, there are redundant survey slots for
multi-radio/single-phy instances.
Fix by moving the survey data into ath12k_hw so multiple radios under a
single wiphy share one table, and index into it using the global
mac80211 index. A new spinlock in ath12k_hw serialises access to the
survey array, which is now shared across all radios under a single hw.
Band busy-times Before this fix:
2.4 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5
5 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5
6 GHz: 9, 2, 2, 2, 4, 2, 10, 16, 4, 12, 5
After this fix, times are independent:
2.4 GHz: 23, 5, 5, 12, 2, 12, 26, 5, 3, 1, 27
5 GHz: 30, 40, 29, 27, 118, 118, 112, 120, 11, 11, 11
6 GHz: 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1
Tested-on: wcn7850 hw2.0 PCI WLAN.IOE_HMT.1.1-00018-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1
Fixes: 4f242b1d69 ("wifi: ath12k: support get_survey mac op for single wiphy")
Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260703-ath12-survey-band-fix-v3-1-2fb050c2505a@collabora.com
[fixed ath12k-check issues]
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
'struct cfg80211_ops' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increases overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
143726 34579 192 178497 2b941 drivers/net/wireless/ath/ath6kl/cfg80211.o
After:
=====
text data bss dec hex filename
144814 33491 192 178497 2b941 drivers/net/wireless/ath/ath6kl/cfg80211.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/5aace954b6ef5c42017b83a1bffb859618e9498a.1784013180.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, the station always follows the listen interval regardless of
the DTIM value. The DTIM function does not work as expected. The default
value of the listen interval is 5 so that the STA wakes up every 500ms
when power save is on. This can cause a data transmission delay.
Set the DTIM policy to DTIM stick mode so that the station follows the AP
DTIM interval rather than the listen interval, which is set in the peer
assoc command. DTIM stick mode is preferable per the firmware team's request.
Apply this only for STA vdevs and only when STA power save is supported, to
avoid affecting unsupported targets and P2P client vdevs.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
Signed-off-by: Daizhuang Bai <daizhuang.bai@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260717014302.284034-1-daizhuang.bai@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Register read/write failures during deauth/teardown transitions are
harmless — mac80211 tries to read survey stats or write slot_time
while the firmware is in a transitional state. The command times
out with -EIO but the adapter recovers and re-authenticates normally.
Downgrade both "writing reg ... failed" and "reading regs failed"
from wiphy_err to wiphy_dbg to reduce dmesg noise. The errors are
still visible with dynamic debug enabled for investigation.
Signed-off-by: Masi Osmani <mas-i@hotmail.de>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Link: https://patch.msgid.link/AM7PPF5613FA0B67FB95CB5305CEF9DAA209441A@AM7PPF5613FA0B6.EURP251.PROD.OUTLOOK.COM
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Count PHY errors reported by the hardware in the RX status and
expose the counter through debugfs as rx_phy_errors. Previously,
PHY errors from ar9170_rx_phystatus were silently ignored (marked
with a TODO comment).
The counter helps diagnose RF environment issues (interference,
multipath, low SNR) without requiring monitor mode or additional
tooling.
Signed-off-by: Masi Osmani <mas-i@hotmail.de>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Link: https://patch.msgid.link/AM7PPF5613FA0B6B42814E38096301FE9429444A@AM7PPF5613FA0B6.EURP251.PROD.OUTLOOK.COM
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Replace the bare TODO comment in the SMPS configuration handler
with documentation explaining why the driver accepts but does not
act on SMPS mode changes.
The AR9170 advertises SM_PS disabled (both chains always active)
in its HT capabilities. While mac80211 may still send SMPS
configuration requests, implementing static or dynamic SMPS would
require firmware support for per-chain enable/disable that the
AR9170 firmware (v1.9.9) does not provide.
Signed-off-by: Masi Osmani <mas-i@hotmail.de>
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Link: https://patch.msgid.link/AM7PPF5613FA0B6B76223A73FFC756A19A99444A@AM7PPF5613FA0B6.EURP251.PROD.OUTLOOK.COM
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
'struct ath12k_dp_arch_ops' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increases overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
6318 3384 0 9702 25e6 drivers/net/wireless/ath/ath12k/wifi7/dp.o
After:
=====
text data bss dec hex filename
6478 3224 0 9702 25e6 drivers/net/wireless/ath/ath12k/wifi7/dp.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/969d732e2c6f169e1aa5e89c7e01743a1adb55df.1784010931.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath12k_wmi_scan_req_arg stores scan parameters in CPU-native byte order,
while ath12k_wmi_send_scan_start_cmd() writes them into a WMI command
buffer whose contents must be in little-endian format. The existing code
copies the channel list and writes s_ssid and hint_bssid related values to
the command buffer without endian conversion. As a result, scan requests
contain invalid parameters on big-endian systems and fail.
Convert the channel list as well as the s_ssid and hint_bssid related
values to little-endian before writing them to the WMI command buffer. This
preserves the existing behaviour on little-endian systems while fixing scan
requests on big-endian architectures.
Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260703-fix-channel-list-copy-v2-1-372c39306d79@westermo.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, in ath11k_wmi_send_scan_start_cmd(), the logic to populate
the hint_bssid copies the BSSID in the wrong direction, from the
firmware message to the argument buffer. Swap the parameters so that
the BSSID is correctly populated in the firmware message from the
argument buffer.
This issue was reported on ath12k, but exists in ath11k as well.
Compile tested only.
Reported-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Closes: https://lore.kernel.org/linux-wireless/afbff608-a005-43c4-af76-968a58bf0cc3@oss.qualcomm.com/
Fixes: 74601ecfef ("ath11k: Add support for 6g scan hint")
Assisted-by: Claude:claude-sonnet-4-6
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260713-ath12k_wmi_send_scan_start_cmd-bad-hint_bssid-v1-2-4ffc4a472992@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, in ath12k_wmi_send_scan_start_cmd(), the logic to populate
the hint_bssid copies the BSSID in the wrong direction, from the
firmware message to the argument buffer. Swap the parameters so that
the BSSID is correctly populated in the firmware message from the
argument buffer.
Compile tested only.
Reported-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Closes: https://lore.kernel.org/linux-wireless/afbff608-a005-43c4-af76-968a58bf0cc3@oss.qualcomm.com/
Fixes: d889913205 ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices")
Assisted-by: Claude:claude-sonnet-4-6
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260713-ath12k_wmi_send_scan_start_cmd-bad-hint_bssid-v1-1-4ffc4a472992@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, the Q6 region contains a read-only firmware region along with
the BDF_MEM_REGION_TYPE and HOST_DDR_REGION_TYPE memory areas. The firmware
expects these writable memory regions to be assigned after the Q6 read-only
section.
However, the ath12k driver currently allocates the HOST_DDR_REGION_TYPE
starting from the base of the Q6 region, which includes the read-only
firmware area. As a result, the allocated memory regions overlap with the
read-only section, causing the firmware to assert during QMI memory
allocation. The Q6 memory region layout is as follows:
Q6 Reserved Memory
+--------------------------------------+
| |
| Read-only Firmware Region |
| (Q6 RO Region) |
| |
+--------------------------------------+ <--- bdf_addr_offset
| Writable Memory Region |
| (BDF + HOST_DDR allocations) |
| |
+--------------------------------------+
Fix this by allocating the required memory regions only after the end of
the read-only region in the Q6 address space. The bdf_addr_offset parameter
indicates where the writable region starts. Both HOST_DDR and BDF regions
are allocated sequentially after this offset, with each region placed
immediately after the previous one to avoid gaps and overlaps.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Fixes: 6757079c58 ("wifi: ath12k: add support for fixed QMI firmware memory")
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Link: https://patch.msgid.link/20260630062048.1615178-4-aaradhana.sahu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath12k_qmi_assign_target_mem_chunk() uses a large switch-case to handle
both memory region identification and allocation for each memory request
type, leading to redundant allocation logic.
Refactor this by introducing ath12k_qmi_get_mem_reg_name() to map memory
request types to their corresponding reserved memory region names.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Link: https://patch.msgid.link/20260630062048.1615178-3-aaradhana.sahu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The driver currently retrieves reserved memory regions using index-based
lookup, which depends on the ordering of reserved-memory nodes in the
device tree. Since different platforms define these regions in varying
orders and combinations, this approach is not compatible and can result
in incorrect memory region access.
Switch to looking up memory regions by name instead of index so it does
not depend on node order.
Use names already defined in qcom,ipq5332-wifi.yaml, so there are no
backward compatibility issues.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Link: https://patch.msgid.link/20260630062048.1615178-2-aaradhana.sahu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently when running 128 clients UDP DL test in 5 GHz HE80 (NSS 2x2),
firmware uses the default max MSDU count (16K MSDUs). This lower limit
causes the firmware to compute a smaller TQM drop threshold, aggregate
packets at a reduced rate, and results in increased packet drops with
TQM drop threshold as the completion reason.
To fix this issue, set WMI_PDEV_PARAM_SET_CONG_CTRL_MAX_MSDUS to the TX
descriptor count using ath12k_wmi_pdev_set_param(). This increases the
TQM drop threshold, reduces drop events, and improves throughput from
~722 Mbps to ~1060 Mbps with 1200 Mbps ingress.
Add a new HW capability flag (supports_cong_ctrl_max_msdus) and enable
the WMI parameter only on supported platforms.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1
Signed-off-by: Thiraviyam Mariyappan <thiraviyam.mariyappan@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Link: https://patch.msgid.link/20260622062614.760166-1-thiraviyam.mariyappan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The following WMI event handlers currently read from the event buffer
without first verifying that the message was large enough to hold the
expected event:
ath6kl_wmi_scan_complete_rx()
ath6kl_wmi_addba_req_event_rx()
ath6kl_wmi_delba_req_event_rx()
Add length checks to prevent overread.
Fixes: bdcd817079 ("Add ath6kl cleaned up driver")
Assisted-by: Claude:claude-sonnet-4-6
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260711-ath6kl_wmi_scan_complete_rx-v2-1-22dc0f7f45e7@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
devm_clk_get() does not return NULL (only valid clock or ERR pointer),
so simplify the code to drop redundant IS_ERR_OR_NULL().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260705172405.119084-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
In the ath12k driver, the BDF_MEM_REGION_TYPE address is derived by
adding a fixed bdf_addr_offset to the WCSS Q6 region base address.
The current offset (0xC00000) works only when the Q6 region contains
the IPQ5332 ucode alone. On some IPQ5332 platform variants, additional
devices share the same WCSS Q6 processor and place their firmware
ucode in the same Q6 region. This results in multiple ucode sections
within the region, and the existing offset can cause the BDF memory
region to overlap with firmware read-only sections, which can lead to
firmware crash and driver boot failure.
Increase the bdf_addr_offset to 0x1A00000, determined by analyzing
firmware memory maps across all known IPQ5332 platform variants. This
value represents the upper bound of the largest combined firmware and
ensures all IPQ5332 variants can allocate the BDF region safely without
overlapping firmware regions.
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Signed-off-by: Aaradhana Sahu <aaradhana.sahu@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260710053534.879233-1-aaradhana.sahu@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
QCC2072 firmware interprets the MLO_LINK_ADD and MLO_START_AS_ACTIVE
flags to control the link state during MLO vdev start. MLO_LINK_ADD
indicates that a link is being added, while MLO_START_AS_ACTIVE specifies
that the link should become active during the start.
When an association link is added without setting MLO_START_AS_ACTIVE,
the firmware may transition the link into a suspended state. In this
case, authentication frames transmitted by the host can be dropped,
leading to repeated authentication retries and eventual timeout,
for example:
wlp1s0: send auth to <AP> (try 1/3)
wlp1s0: send auth to <AP> (try 2/3)
wlp1s0: send auth to <AP> (try 3/3)
wlp1s0: authentication with <AP> timed out
Avoid triggering this behavior by setting the MLO_START_AS_ACTIVE flag
when MLO_ASSOC_LINK is set, which tells the firmware that the current
vdev must not enter suspend mode
Note that this change relies on firmware behavior observed on the QCC2072
platform. The firmware on WCN7850 and QCN9274 does not use the
MLO_START_AS_ACTIVE flag, so this change is effectively a no-op on those
platforms
Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00068-QCACOLSWPL_V1_TO_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3
Fixes: d8e1f4a193 ("wifi: ath12k: enable QCC2072 support")
Signed-off-by: Miaoqing Pan <miaoqing.pan@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260704073000.3300099-1-miaoqing.pan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
ath11k_wmi_tlv_ext_hal_reg_caps() copies firmware regulatory
capability records into soc->hal_reg_cap[] using reg_cap.phy_id as
the destination index. The loop count is bounded by num_phy, but the
phy_id embedded in each record is not checked against the fixed
MAX_RADIOS-sized destination array.
Reject firmware records whose phy_id does not fit soc->hal_reg_cap[]
before copying the parsed capability.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260704011040.26233-1-pengpeng@iscas.ac.cn
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
When an error occurs during RX packet processing (e.g., MSDU done
failure), the driver sets rx_confused and drops all subsequent RX
packets until a Wi-Fi ON/OFF cycle clears the flag. This can leave
the device in a bad state where it cannot process RX data traffic.
Instead of leaving the device in such a state, trigger hardware
recovery so that such an error state can be reset and the device
can function again normally.
Tested-on: WCN3990 hw1.0 WLAN.HL.3.2.2.c10-00754-QCAHLSWMTPL-1
Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
Signed-off-by: Manikanta Pubbisetty <manikanta.pubbisetty@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260710060406.3323260-1-manikanta.pubbisetty@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Currently, IEEE80211_OFFLOAD_ENCAP_4ADDR is set when
IEEE80211_OFFLOAD_ENCAP_ENABLED is present in vif->offload_flags
at the beginning of ath12k_mac_update_vif_offload().
However, if the WMI vdev set_param for tx_encap_type fails,
IEEE80211_OFFLOAD_ENCAP_ENABLED is cleared but
IEEE80211_OFFLOAD_ENCAP_4ADDR remains set, leaving the flags in
an inconsistent state.
Fix this by setting IEEE80211_OFFLOAD_ENCAP_4ADDR only after the
tx_encap_type has been configured via the WMI vdev set parameter.
Compile tested only.
Fixes: 729cad3c3c ("wifi: ath12k: Add 4-address mode support for eth offload")
Signed-off-by: Tamizh Chelvam Raja <tamizh.raja@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260701182428.906441-1-tamizh.raja@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
The current hardware does not support TX VLAN offload for packets with
three or more VLAN tags. When such packets are transmitted with hardware
VLAN offload enabled, the hardware may malfunction or produce corrupted
frames.
Add a check in wx_features_check() to parse the VLAN depth of the
skb. If more than two VLAN tags are detected (including both the
hardware tag and in-band tags), strip NETIF_F_HW_VLAN_CTAG_TX and
NETIF_F_HW_VLAN_STAG_TX from the feature set. This forces the
kernel networking stack to handle VLAN insertion in software for
these specific packets, ensuring correct transmission.
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Link: https://patch.msgid.link/069DF89AA8029189+20260713060441.276612-1-jiawenwu@trustnetic.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When build_skb() fails in hip04_rx_poll(), the driver jumps to the
refill path without releasing the current RX buffer and its DMA mapping.
Installing a replacement buffer then overwrites the slot references and
leaks both resources.
Keep the current slot intact and return budget so NAPI retries the same
buffer. Also free a newly allocated RX fragment when dma_map_single()
fails.
This issue was found by an in-house static analysis tool.
Fixes: 701a0fd523 ("hip04_eth: fix missing error handle for build_skb failed")
Cc: stable@vger.kernel.org
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260712142729.2057636-1-fanwu01@zju.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Andrea Mayer says:
====================
seg6: add FIB table attribute for post-encap SID route lookup
After SRv6 encapsulation the kernel looks up the route for the first SID,
the outer IPv6 destination of the encapsulated packet. This post-encap SID
route lookup uses the FIB table of the current routing context. When the
encap route is installed in a VRF, the VRF's table may not have a route for
the SID, which should be handled by another table, e.g. one used for
underlay connectivity.
A new optional SEG6_IPTUNNEL_TABLE attribute selects the FIB table used for
this lookup. When set by the user, the attribute is honored on both the
input path (traffic that is received, encapsulated and forwarded) and the
output path (traffic that is locally originated and then encapsulated).
SRv6 encap routes that do not set the attribute use the current routing
context, as before.
A companion iproute2 series follows on the mailing list. The examples below
show how to use the "lookup" attribute:
# SID route installed in the underlay table 500
ip -6 route add fc00::100/128 via fd00::1 dev veth0 table 500
# encap route in vrf-100; the first SID is looked up in table 500
ip -6 route add cafe::1/128 vrf vrf-100 \
encap seg6 mode encap segs fc00::100 lookup 500 dev veth0
# or if the SID is already handled by the main table
ip -6 route add cafe::1/128 vrf vrf-100 \
encap seg6 mode encap segs fc00::100 lookup main dev veth0
This work started from a use case raised by Nicolas Dichtel and took shape
in the discussion with him [1]. Thanks Nicolas.
The series is made of two patches. The first implements the attribute. The
second adds an L3 VPN selftest that exercises both the input and the output
path, with the attribute (traffic reaches its destination) and without it
(the packet is dropped).
[1] https://lore.kernel.org/all/20260327140709.959636-1-nicolas.dichtel@6wind.com/T/
====================
Link: https://patch.msgid.link/20260711162907.6521-1-andrea.mayer@uniroma2.it
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a selftest for the SEG6_IPTUNNEL_TABLE attribute, which selects the FIB
table for the post-encap SID route lookup. This looks up the route for the
first SID, the outer destination of the encapsulated packet.
Two routers provide L3 VPN services over an IPv6 underlay. Each router uses
a separate VRF per tenant, with default blackhole routes (IPv4 and IPv6)
that drop unmatched traffic. Tenant traffic is encapsulated, then
decapsulated with an End.DT46.
The encap routes are installed in the tenant VRF, but the routes that match
the first SIDs live in a separate underlay table (500). The "lookup 500"
attribute points the lookup there rather than to the VRF.
The test covers both the input path, where forwarded host traffic triggers
encapsulation, and the output path, where a router originates traffic from
its own loopback inside a VRF.
With the "lookup" attribute, traffic reaches its destination on both paths.
Without it, on the input path the lookup stays in the VRF and hits the
blackhole, and on the output path it falls through to the main table, which
has no matching route.
Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://patch.msgid.link/20260711162907.6521-3-andrea.mayer@uniroma2.it
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After SRv6 encapsulation the kernel looks up the route for the first SID,
that is the outer IPv6 destination of the encapsulated packet. This
post-encap SID route lookup uses the FIB table of the current routing
context. When the encap route is installed in a VRF, the VRF's table may
not have a route matching the SID. In that case another table should
handle it, e.g. one configured for underlay connectivity.
Add an optional SEG6_IPTUNNEL_TABLE attribute that selects the FIB table
used for this lookup. When set by the user, the attribute is honored on
both the input path (forwarded traffic) and the output path (locally
originated traffic). SRv6 encap routes that do not set the attribute use
the current routing context, as before.
For example:
# SID route installed in the underlay table 500
ip -6 route add fc00::100/128 via fd00::1 dev veth0 table 500
# encap route in vrf-100; the first SID is looked up in table 500
ip -6 route add cafe::1/128 vrf vrf-100 \
encap seg6 mode encap segs fc00::100 lookup 500 dev veth0
# or look up the SID in the main table
ip -6 route add cafe::1/128 vrf vrf-100 \
encap seg6 mode encap segs fc00::100 lookup main dev veth0
Suggested-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20260711162907.6521-2-andrea.mayer@uniroma2.it
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Michael Bommarito says:
====================
amt: fix use-after-free of the skb head across pulls
Several AMT receive and transmit paths cache a pointer into the skb head
and then call a helper that can reallocate that head before the cached
pointer is used again, so the later access reads or writes freed memory.
Patch 1 walks every AMT path and, for each pointer used after a
reallocating call, either snapshots the value before the first pull or
re-derives the pointer after the last one.
Patch 2 is a smaller, separable hardening change: the three handlers
that rewrite the ethernet header do so in place without making the head
private, which corrupts a cloned skb (for example one held by a packet
tap). It adds skb_cow_head() before the rewrite, split out so the
use-after-free fix is not held up by discussion of the clone case.
====================
Link: https://patch.msgid.link/20260711151934.2955226-1-michael.bommarito@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
amt_multicast_data_handler(), amt_membership_query_handler() and
amt_update_handler() rewrite the ethernet header of the decapsulated skb
in place (eth->h_proto, eth->h_dest and, for the query, also
eth->h_source) before handing it up the stack. The skb head may be
shared, for example when a packet tap has cloned it on the underlay
interface, so writing through it corrupts the other reader's copy.
Call skb_cow_head() before the rewrite so the head is private. It is
placed before the pointers into the head are (re-)derived, so a
reallocation caused by the copy is picked up by those derivations.
Fixes: cbc21dc1cf ("amt: add data plane of amt interface")
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Taehee Yoo <ap420073@gmail.com>
Link: https://patch.msgid.link/20260711151934.2955226-3-michael.bommarito@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Several AMT receive and transmit paths cache a pointer into the skb head
(ip_hdr(), ipv6_hdr(), eth_hdr() or the AMT message header) and then call
a helper that can reallocate that head before the cached pointer is used
again. pskb_may_pull(), ip_mc_may_pull(), ipv6_mc_may_pull(),
iptunnel_pull_header(), ip_mc_check_igmp() and ipv6_mc_check_mld() can all
free the old head and move the data, so a pointer taken before the call
dangles afterwards and the later access is a use-after-free of the freed
head.
The affected sites are:
amt_rcv() caches ip_hdr() before amt_parse_type() pulls, then reads
iph->saddr.
amt_dev_xmit() caches ip_hdr()/ipv6_hdr() before ip_mc_check_igmp()/
ipv6_mc_check_mld() and pskb_may_pull(), then reads the group address.
amt_multicast_data_handler() caches eth_hdr() before pskb_may_pull(),
then writes the L2 header.
amt_membership_query_handler() caches the AMT header, the outer and
inner eth_hdr() and ip_hdr() before iptunnel_pull_header() and several
pulls, then reads and writes them.
amt_igmpv3_report_handler() and amt_mldv2_report_handler() cache
ip_hdr()/ipv6_hdr() and the current group record and read the record
count from the report header inside the record loop, across the
*_mc_may_pull() calls.
amt_update_handler() caches ip_hdr() and the AMT membership-update
header before pskb_may_pull(), iptunnel_pull_header(),
ip_mc_check_igmp() and the report handler, then reads iph->daddr and
amtmu->nonce / amtmu->response_mac.
Fix each site by either snapshotting the scalar that is used after the
pull before the first pull runs, or re-deriving the header pointer from
the skb after the last pull that can move the head. Values that are
stable across the pull (source and group address, the response MAC and
nonce, the record count, the outer source MAC) are snapshotted; pointers
that are written through or read repeatedly are re-derived.
Fixes: cbc21dc1cf ("amt: add data plane of amt interface")
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Taehee Yoo <ap420073@gmail.com>
Link: https://patch.msgid.link/20260711151934.2955226-2-michael.bommarito@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The brcmfmac driver uses the SDIO vendor ID values to identify which
vendor's driver extensions to use. However, the Cypress/Infineon devices
have a vendor ID of 02d0, which is Broadcom.
In order to use the Cypress driver extensions, modify the static mapping
for "43430", "4345" (sic) and "43455"
to indicate that they are Cypress parts.
Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Shelley Yang <shelley.yang@infineon.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260525083926.583964-1-shelley.yang@infineon.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add a KUnit test for the extack failure reasons that
__cfg80211_get_bss() now reports: no matching scan entry at all, a
matching entry that is expired, and a matching entry whose use_for
flags do not allow the requested use. Also cover the cases that must
not report a failure (a fresh entry, and an expired-but-held entry),
an entry that is both expired and unusable, and the combined message
when one matching entry is expired while another is current but
unusable.
Signed-off-by: Louis Kotze <loukot@gmail.com>
Link: https://patch.msgid.link/20260722070734.3612581-3-loukot@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The BSS lookup for an authentication or association request can fail
for three distinct reasons: cfg80211 has no scan entry at all for the
BSSID/channel, an entry exists but is older than
IEEE80211_SCAN_RESULT_EXPIRE (and not held), or a fresh entry exists
but its use_for flags do not allow this use. All three currently
surface as the same generic extack message "Error fetching BSS for
link" on the MLO association path, and as a bare -ENOENT with no
message at all on the authentication and non-MLO association paths.
Since wpa_supplicant logs the extack message verbatim ("nl80211:
kernel reports: ..."), that message is often the only diagnostic a
user sees when an MLO association degrades to fewer links, and it
does not say whether a fresh scan could have helped. In practice the
expired case is common for MLO partner links: 6 GHz is passive-scan
in many regulatory domains, so the partner-link entry is routinely
stale by the time userspace requests the association even though the
link is perfectly usable.
Let __cfg80211_get_bss() take an optional extack and record, during
the same bss_lock walk that fails the lookup, whether any matching
entry was rejected for being expired or for not being usable for the
requested use, and set a distinct message for each case (and a
combined one when different entries were rejected for different
reasons). Reorder the checks in the walk so that an entry's identity
(type, privacy, channel, BSSID/SSID) is established before the
usability checks; this doesn't change which entry is returned since
an entry is only used when all checks pass.
Also give the -EINVAL paths in nl80211_assoc_bss() proper messages
while at it, and keep pointing the bad_attr at the failing link on
the MLO path there; the message for that case is already set by the
lookup itself.
Signed-off-by: Louis Kotze <loukot@gmail.com>
Link: https://patch.msgid.link/20260722070734.3612581-2-loukot@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Populate link_valid/link_id in mac80211_hwsim TX status so the
transmitted link is reported to mac80211.
Set the link information in both the direct TX status path and the
wmediumd/netlink TX status path.
With that done, enable NL80211_EXT_FEATURE_PROBE_AP.
Signed-off-by: Priyansha Tiwari <priyansha.tiwari@oss.qualcomm.com>
Link: https://patch.msgid.link/20260709114228.672317-3-pritiwa@qti.qualcomm.com
[add note about NL80211_EXT_FEATURE_PROBE_AP]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add STA/P2P-client support to ieee80211_probe_peer(): when called
for a station interface, send a null-data frame (TODS) to the
associated AP and report the ACK via cfg80211_probe_status().
For MLO connections the driver/firmware selects the link
(IEEE80211_LINK_UNSPECIFIED); for non-MLO the single link is used.
Signed-off-by: Priyansha Tiwari <priyansha.tiwari@oss.qualcomm.com>
Link: https://patch.msgid.link/20260709114228.672317-2-pritiwa@qti.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Alice Mikityanska says:
====================
BIG TCP for UDP tunnels
This series is a follow-up to "BIG TCP without HBH in IPv6", and it adds
support for BIG TCP IPv4/IPv6 workloads in vxlan and geneve. Now that
IPv6 BIG TCP doesn't require stripping the HBH in all various
combinations in tunneled traffic, adding BIG TCP becomes feasible.
Patch 01 adds accessors for the length field in the UDP header, as
suggested by Paolo in review. The usage of udp_set_len is then added in
the following patches that start using length=0 in BIG TCP UDP packets.
Patches 02-04 close the gaps that prevent BIG TCP packets from going
through UDP tunnel code.
Patch 05 validates packets in udp_gro_receive to exclude packets with
length=0 from GRO aggregation.
Patch 06 is for proper formatting in tcpdump (set UDP len to 0 rather
than a trimmed value on overflow).
Patches 07-08 bump up tso_max_size for VXLAN and GENEVE.
Patch 09 adds selftests.
====================$
Link: https://patch.msgid.link/20260710134242.216538-1-alice.kernel@fastmail.im
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The test sets up VXLAN and GENEVE tunnels over IPv4 and IPv6 and runs
IPv4 and IPv6 traffic through them with BIG TCP enabled. It checks that
a non-negligible amount of big aggregated packets are seen by setting up
iptables counters.
Check the number of packets on both TX and RX sides to verify that GSO
packets are valid and not dropped. Capture on the lower netdev (veth),
when checksum offload is on, to verify that encapsulated BIG TCP packets
can get to their destination. In the test with TX checksum offload off,
software GSO splits aggregated VXLAN packets before passing them to
veth, so capture inside the tunnel instead to check that the big packets
are not dropped.
Check that the amount of SACKs is negligible. On unsupported kernels,
some amount of broken GSO packets bigger than 65536 bytes can be
produced in VXLAN tunnels, but they don't reach the destination. Seeing
TCP SACKs is a sign that such packets could have been dropped (in such
cases, the amount of SACKs is a few times bigger than the number of
attempts to send BIG TCP packets).
Signed-off-by: Alice Mikityanska <alice@isovalent.com>
Link: https://patch.msgid.link/20260710134242.216538-10-alice.kernel@fastmail.im
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
