| Age | Commit message (Collapse) | Author |
|---|
|
Refactor mt7925_nan_enable() to build the MCU command from separate
TLVs via skb instead of inline fields in the enable request struct.
The cluster ID, DW interval, discovery beacon interval and RSSI
threshold settings are now shared with mt7925_nan_change_configure()
through the common TLV helpers, avoiding duplicated setup code.
Fixes: a5487a682406 ("wifi: mt76: mt7925: add NAN MCU helpers")
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Stella Liu <yu-ching.liu@mediatek.com>
Link: https://patch.msgid.link/20260824195227.12589-9-sean.wang@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
NAN operates with OFDM and does not support CCK, so the phy, rate
control and BSS rate TLVs must not fall back to 2.4 GHz. Borrow the
5 GHz band lookup to keep the STA records OFDM-only.
Fixes: 9824fb4edbf3 ("wifi: mt76: mt7925: add NAN MCU handling")
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Stella Liu <yu-ching.liu@mediatek.com>
Link: https://patch.msgid.link/20260824195227.12589-8-sean.wang@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
The deferred NAN local schedule update path in
mt7925_nan_local_sched_changed() is removed for now; it will be
implemented separately. Drop the now set-but-unused ret variable
along with it.
Fixes: 0f3605e4f8de ("wifi: mt76: mt7925: wire up NAN operations")
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Stella Liu <yu-ching.liu@mediatek.com>
Link: https://patch.msgid.link/20260824195227.12589-7-sean.wang@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
The config_support_5g/support_5g_val and config_2dot4g_support/
support_2dot4g_val fields in the NAN enable request are not used by the
firmware, so stop setting them and drop mt7925_nan_set_2g_support().
Fixes: 0f3605e4f8de ("wifi: mt76: mt7925: wire up NAN operations")
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Stella Liu <yu-ching.liu@mediatek.com>
Link: https://patch.msgid.link/20260824195227.12589-6-sean.wang@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
The firmware only checks the 2.4 GHz bit of the local device capability
supported_bands field, so set it directly and drop the unused helper.
Fixes: 0f3605e4f8de ("wifi: mt76: mt7925: wire up NAN operations")
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Stella Liu <yu-ching.liu@mediatek.com>
Link: https://patch.msgid.link/20260824195227.12589-5-sean.wang@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
The committed CRB timeline carried a local_map_id byte that does not
exist in the firmware NAN_SCHEDULE_TIMELINE_T layout (map id plus 3
reserved bytes), shifting the availability bitmap. Drop it and match
the firmware structure.
The common-slot check is also dropped as redundant: mac80211 already
tracks common slots, so avail_map is built directly from the peer
schedule.
Fixes: 0f3605e4f8de ("wifi: mt76: mt7925: wire up NAN operations")
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Stella Liu <yu-ching.liu@mediatek.com>
Link: https://patch.msgid.link/20260824195227.12589-4-sean.wang@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
mt7925_start_nan() called mt7925_nan_set_nmi_addr(), which makes NAN
start fail. The NMI address is not managed here, so drop the call.
Also track dev->nan_vif only in add/remove_interface and fold the
single BSS rollback into an inline error check.
Fixes: 0f3605e4f8de ("wifi: mt76: mt7925: wire up NAN operations")
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Stella Liu <yu-ching.liu@mediatek.com>
Link: https://patch.msgid.link/20260824195227.12589-3-sean.wang@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
The NDP STA record role_idx must carry the NAN BSS band0 index
rather than the mac80211 BSS index, otherwise the firmware maps the
NDP peer to the wrong role. Use the fixed NAN_BSS_INDEX_BAND0 value.
While at it, drop the inline peer-schedule setup in
mt792x_nan_map_sta_rec(): the peer schedule is already driven by the
upper layer through the peer_sched_changed callback
(mt792x_nan_set_peer_schedule()), so the redundant call and the
now-unused local variables are removed.
Fixes: 0f3605e4f8de ("wifi: mt76: mt7925: wire up NAN operations")
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Stella Liu <yu-ching.liu@mediatek.com>
Link: https://patch.msgid.link/20260824195227.12589-2-sean.wang@kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
seq_id from the WED RRO indication is a 12-bit field (0-4095), but only
values up to MT7996_RRO_MAX_SESSION map into wed_rro.addr_elem[], which
has MT7996_RRO_ADDR_ELEM_LEN (128) entries. A larger session id computes
an out-of-bounds element index that is then read and, on a signature
mismatch, written. Reject an out-of-range session id.
Fixes: a09d2f9d69af ("wifi: mt76: Convert mt76_wed_rro_ind to LE")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
mt7915_coredump_build()/mt7996_coredump_build() wrote dump_mem->len
unconditionally, but the allocation only reserves room for the memory
dump header when coredump_memdump is enabled and memdump_buf_len is
non-zero. In the default configuration the allocation ends right after
the fixed header, so the write landed one struct past the buffer. Only
populate the memory-dump section when it was actually allocated.
Fixes: 4dbcb9125cc3 ("wifi: mt76: mt7915: enable coredump support")
Fixes: 878161d5d4a4 ("wifi: mt76: mt7996: enable coredump support")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
mt7915_thermal_init() registered the thermal cooling device and its sysfs
link, then returned the hwmon registration error without undoing them.
The cooling device (not devm-managed) and the link then leaked, and its
callbacks referenced the freed phy. Unregister the cooling device before
returning the error.
Fixes: 0ae3ff568451 ("mt76: mt7915: fix hwmon temp sensor mem use-after-free")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
Two unsolicited event handlers trusted firmware-provided lengths:
mt7996_mcu_rx_all_sta_info_event() looped over res->sta_num without
checking it against skb->len, reading the flex array out of bounds; and
mt7996_mcu_rx_log_message() could compute a negative or oversized length
from tlv->len and feed it to %.*s and the debugfs log path. Bound both
against the actual skb length.
Fixes: adde3eed4a75 ("wifi: mt76: mt7996: Add mcu commands for getting sta tx statistic")
Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
mt7915_eeprom_load_default() copied mt7915_eeprom_size() bytes from the
firmware blob after only checking that it was non-NULL. A truncated
default bin caused an out-of-bounds read past the firmware buffer into
the EEPROM image. Reject a blob smaller than the EEPROM size.
Fixes: beed8bea8d74 ("mt76: mt7915: add mt7916 calibrated data support")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
The driver increments wcid->non_aql_packets when a frame goes to the
hardware queue. The completion path decrements the counter again.
For an MLO peer, the hardware reports the completion on the link that it
used for the transmission. This link can differ from the link that the
driver queued the frame on. In that case, the increment and the
decrement go to different link wcids, and the count drifts upwards until
it blocks the station.
Keep the count on the wcid of the primary link, like the other peer-wide
state.
Fixes: 86c051f2c418 ("wifi: mt76: mt7925: enabling MLO when the firmware supports it")
Link: https://patch.msgid.link/20260818125825.395538-5-nbd@nbd.name
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
mt76_scan_complete() restores the operating channel only if the phy has one.
__mt76_set_channel() is the only function that clears phy->offchannel.
A phy can run a scan while it has no operating channel. A 6 GHz radio with
no configured interface is one example. After such a scan, the flag stays
set.
mt76_txq_schedule_list() skips each TXQ whose wcid points to a phy in this
state. All traffic for the stations on that band stops. The frames stay in
the mac80211 queues. They do not reach the hardware, and no counter shows
them. Only an unrelated channel set clears the flag.
Fixes: 31083e38548f ("wifi: mt76: add code for emulating hardware scanning")
Fixes: a8f424c1287c ("wifi: mt76: add multi-radio remain_on_channel functions")
Link: https://patch.msgid.link/20260818125825.395538-4-nbd@nbd.name
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
mt76 runs its own beacon monitor. mt76_beacon_mon_check() counts a miss
for each affiliated link of an MLD, and it stops the count while the phy
is off channel. mt7996 supplies it through mt76_rx_beacon(), but it does
not set CONNECTION_MONITOR. Therefore mac80211 also starts its legacy
monitor.
The legacy monitor knows one interface, not a set of links. It also
counts while the radio serves a different link. After seven beacon
intervals it removes an association that still carries traffic on the
other links.
Set the CONNECTION_MONITOR flag to disable the legacy monitor.
Fixes: 4df75606ece5 ("wifi: mt76: add per-link beacon monitoring for MLO")
Link: https://patch.msgid.link/20260818125825.395538-3-nbd@nbd.name
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
mvif->roc_phy points to the phy of the request that started last for the
interface. That request can end, and the phy can start a request for a
different interface. The driver does not always clear the pointer.
Two callers trust the pointer:
- mt76_vif_cleanup() aborts the request on that phy when the driver removes
the interface.
- mt76_cancel_remain_on_channel() aborts the request on that phy for the
interface.
If the phy holds a request for a different interface, both callers abort the
wrong request. The request of the interface stays active. Its work then runs
after the driver removes the interface. The work tears the link down through
the freed bss_conf.
Compare phy->roc_vif with the interface in both callers before the abort.
Fixes: a8f424c1287c ("wifi: mt76: add multi-radio remain_on_channel functions")
Link: https://patch.msgid.link/20260818125825.395538-2-nbd@nbd.name
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
The firmware needs the driver to remove active links from the BSSINFO table
when it destroys the interface. A link therefore stays registered from its
first chanctx assignment until the interface goes away. If the driver holds
the link already, a second add does nothing.
mac80211 gives a non-AP MLD a new address each time it sets a link up. A link
that comes back after a failed attempt thus carries an address that the
hardware does not know, on a BSS that the driver never programs again. The
station then authenticates from an address that nothing answers. The failure
repeats until the driver tears the interface down for good.
Program the address and the BSS again. This is the pair that the initial add
sets up. For a station it does what mt7996_mcu_mld_link_oper() does for an AP.
Fixes: 08813703ac41 ("wifi: mt76: mt7996: Destroy vif active links in mt7996_remove_interface()")
Link: https://patch.msgid.link/20260818125825.395538-1-nbd@nbd.name
Signed-off-by: Felix Fietkau <nbd@nbd.name>
|
|
When the driver is removed while the user space process that created
the P2P device (e.g. wpa_supplicant) is still exiting, the P2P device
interface is removed twice and the kernel crashes.
The two paths are:
- wpa_supplicant, on exit, sends NL80211_CMD_DEL_INTERFACE for the P2P
device. nl80211_del_interface() holds RTNL and the wiphy mutex and
calls brcmf_p2p_del_vif(), which disables discovery and waits up to
1.5 s for BRCMF_E_IF_DEL. Then it calls brcmf_remove_interface(),
which unregisters the wdev and frees the vif and the ifp.
- brcmf_detach() sets the bus down, so BRCMF_E_IF_DEL never arrives,
and calls brcmf_remove_interface(ifp, false) for the same ifp.
brcmf_p2p_ifp_removed() reads ifp->vif and then blocks on
rtnl_lock(). When brcmf_p2p_del_vif() releases RTNL, it calls
cfg80211_unregister_wdev() on the wdev that was already unregistered
and freed.
The second list_del_rcu() of wdev->list faults on LIST_POISON2:
brcmfmac: brcmf_p2p_del_vif delete P2P vif
brcmfmac: brcmf_p2p_deinit_discovery enter
brcmfmac: brcmf_p2p_del_vif P2P: GO_NEG_PHASE status cleared
brcmfmac: brcmf_detach Enter
brcmfmac: brcmf_bus_change_state 1 -> 0
brcmfmac: brcmf_remove_interface Enter, bsscfgidx=1, ifidx=0
brcmfmac: brcmf_del_if Enter, bsscfgidx=1, ifidx=0
brcmfmac: brcmf_p2p_ifp_removed P2P: device interface removed
[1.5 s later, brcmf_p2p_del_vif() timed out]
brcmfmac: brcmf_remove_interface Enter, bsscfgidx=1, ifidx=0
brcmfmac: brcmf_del_if Enter, bsscfgidx=1, ifidx=0
brcmfmac: brcmf_p2p_ifp_removed P2P: device interface removed
Unable to handle kernel paging request at virtual address dead000000000122
Internal error: Oops: 96000044 [#1] PREEMPT_RT SMP
pc : _cfg80211_unregister_wdev+0x6c/0x264 [cfg80211]
Call trace:
_cfg80211_unregister_wdev+0x6c/0x264 [cfg80211]
cfg80211_unregister_wdev+0x10/0x1c [cfg80211]
brcmf_p2p_ifp_removed+0x84/0xb0 [brcmfmac]
brcmf_remove_interface+0x1f4/0x254 [brcmfmac]
brcmf_detach+0x88/0x180 [brcmfmac]
brcmf_sdio_remove+0x90/0x7b0 [brcmfmac]
brcmf_sdiod_remove+0x20/0xa0 [brcmfmac]
brcmf_ops_sdio_remove+0xbc/0x12c [brcmfmac]
sdio_bus_remove+0x38/0x144
device_release_driver_internal+0x1e8/0x2c0
device_release_driver+0x14/0x20
brcmf_sdio_bus_remove+0x2c/0x40 [brcmfmac]
brcmf_fwvid_unregister_vendor+0xd8/0x170 [brcmfmac]
__exit_compat+0x18/0x418 [brcmfmac_cyw]
__arm64_sys_delete_module+0x1ac/0x244
The log was taken with debug=0x406 on an i.MX 8M Plus board with a
CYW55513 (Sona IF513) on SDIO. The driver is the Ezurio backport of
brcmfmac from v6.18.22 on a 5.4-rt kernel. The code involved is the same
in mainline.
To reproduce:
1. Start wpa_supplicant on wlan0 and let it associate. It creates the
P2P device (iw dev shows "type P2P-device").
2. Stop wpa_supplicant and remove the driver without waiting for
wpa_supplicant to exit:
kill $(pidof wpa_supplicant)
rmmod brcmfmac_cyw brcmfmac
The crash is reproducible on that board.
For the interface without a netdev (the P2P device), take RTNL and the
wiphy mutex in brcmf_detach() before reading iflist, and remove it with
locked=true. If brcmf_p2p_del_vif() runs first, brcmf_detach() finds the
slot empty. If brcmf_detach() runs first, nl80211 does not find the wdev
any more. The interfaces with a netdev are removed as before, because
brcmf_del_if() takes RTNL on its own for the primary interface.
Fixes: 9831bcb987df ("brcmfmac: Deleting of p2p device is leaking memory.")
Cc: stable@vger.kernel.org
Assisted-by: claude-opus-5-5
Signed-off-by: Michele Dionisio <michele.dionisio@gmail.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://patch.msgid.link/20260924123027.4122909-2-michele.dionisio@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git update for v7.3-rc7
In ath12k, revert the panic handler that landed in v6.11 since it can
perform a voluntary context switch within an RCU read-side critical
section.
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
https://github.com/nxp-upstream/nxpwifi-next
Jeff Chen says:
===============
nxpwifi updates for 7.3
This update contains fixes for station list synchronization,
aggregation and reorder buffer cleanup, authentication frame
handling, and several memory safety issues.
Highlights:
- fix concurrent sta_list add/delete races
- clean up station entries on uAP deauthentication
- fix Tx BA stream entry deletion logic
- avoid deleting Rx reorder entries under RCU
- improve aggregation buffer cleanup
- fix authentication frame length validation
- handle authentication frame allocation failures
- fix wakeup timer shutdown ordering
===============
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
tegra_xusb_padctl_parse_subnode() can append mappings before a later
child or configuration operation fails. The top-level callback currently
returns the error while retaining all mappings allocated for earlier
children.
Free the accumulated map on failure. The caller ignores the output
parameters when the mapping callback returns an error, so they do not need
to be reset after freeing the map.
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
sprd_dt_node_to_map() reserves map storage before adding mux and
configuration entries. If a later operation fails, the error path only
frees the temporary configurations and leaves the map allocation reachable
through the output pointer.
Free the partially built map on failure. The caller ignores the output
parameters when the mapping callback returns an error, so they do not need
to be reset after freeing the map.
Fixes: 41d32cfce1ae ("pinctrl: sprd: Add Spreadtrum pin control driver")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mikulas Patocka:
"dm-integrity:
- validate the superblock after re-reading it
- fix buffer overflow if tag size > 64
dm:
- fix reading up to 7 bytes beyond the end of block in dm-ioctl
- fix reading free memory if the ioctls are called concurrently
dm-crypt:
- fix a crash on invalid table line
dm-snap:
- fix a crash on invalid table line"
* tag 'for-7.3/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm-integrity: validate the superblock on resume
dm-snap: reject the transient exception store for snapshot-merge
dm: fix reading free memory in do_resume
dm ioctl: don't let data_start run past the buffer
dm-crypt: reject the lmk IV mode with AEAD ciphers
dm-integrity: fix buffer overflow in inline mode with large tag size
|
|
This driver performs the fundamental read/write functions as an I2C
controller and supports Standard-mode and Fast-mode.
Default operation is Standard-mode.
Signed-off-by: Ben Huang <Ben_Huang@novatek.com.tw>
Signed-off-by: Nina Kuo <Nina_Kuo@novatek.com.tw>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://patch.msgid.link/20260910030123.215609-3-nina_kuo@novatek.com.tw
|
|
fw_cancel_transaction() has no kerneldoc even though it is exposed.
Add kerneldoc for it.
Link: https://lore.kernel.org/r/20261007093235.175742-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The current implementation invokes the transaction callback in the
context where transaction cancellation is requested. This is
inconvenient because the context can affect the transaction callback.
Invoke the transaction callback from a workqueue instead. Use the
workqueue for error handling.
Link: https://lore.kernel.org/r/20261007093235.175742-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The current implementation uses a different path for local packets than
for remote packets, and local packets cannot be cancelled once they have
been queued.
Allow local packets to be cancelled.
Link: https://lore.kernel.org/r/20261007093235.175742-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The current implementation invokes the packet callback in the context
where the packet cancellation is requested. This is inconvenient because
the context can affect the packet callback.
Invoke the packet callback from a workqueue instead. Use the workqueue
for local AT packets.
Link: https://lore.kernel.org/r/20261007093235.175742-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
The return value from close_transaction() is useful only in
fw_cancel_transaction(). The other caller,
transmit_complete_callback(), simply discards it.
Additionally, the pending transaction queue should be enumerated as soon
as possible to prevent the issued transaction from completing.
Expand close_transaction() into its callers, and remove it.
In the find_and_pop_transaction_entry() macro, a local variable provides
the evaluation result, however transmit_complete_callback() uses the same
local variable for another purpose. Add an underscore prefix to the one
in the macro to avoid the unexpected result.
Link: https://lore.kernel.org/r/20261007093235.175742-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
|
|
When an AER error occurs, candidate error-source devices are added to
e_info->dev[] by add_error_device(), which takes a reference with
pci_dev_get().
A device can be recorded without any error status being present: the
Requester ID fast path in is_error_source(),
if (e_info->id == pci_dev_id(dev))
return true;
matches purely on the ID reported by the Root Port and returns true without
reading the device's AER status registers.
In aer_process_err_devices(), handle_error_source() is called only if
aer_get_device_error_info() returns non-zero, i.e. only if an unmasked
error status bit is actually set. It returns 0 if the device has become
inaccessible (status and mask both read as all ones, so
status & ~mask == 0) or if no unmasked status bit is set.
Because handle_error_source() was responsible for calling pci_dev_put(),
skipping it permanently leaks the reference taken in add_error_device().
Decouple reference lifetime from error handling by moving pci_dev_put() out
of handle_error_source() and into the aer_process_err_devices() loop, so
every recorded device is put exactly once.
handle_error_source() is static and aer_process_err_devices() is its only
caller, so no other path is affected.
Fixes: 60271ab044a5 ("PCI/AER: Take reference on error devices")
Signed-off-by: Priyank Rathod <rathodpriyank@google.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260918-fix-aer-refcount-leak-v2-1-bdd1ff1c35a9@google.com
|
|
ghes_handle_aer() allocates the AER register snapshot that it passes to
aer_recover_queue() from ghes_estatus_pool. aer_recover_queue() returns
void, so the caller cannot tell whether the record was queued, and the AER
code owns the buffer from then on and must free it on every path.
None of this is documented at the definition of this exported function.
With GHES enabled, a new caller that passed a buffer from any other
allocator would hit the BUG() in gen_pool_free_owner() when the AER code
returns the buffer to ghes_estatus_pool, and a caller that freed the buffer
itself would cause a double free.
Add a kernel-doc comment that describes the parameters and states that
aer_recover_queue() takes ownership of @aer_regs, which must have been
allocated from ghes_estatus_pool.
No functional change.
Suggested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://lore.kernel.org/r/4513e7d4-4e2f-42d8-8f0c-2f0e03815dee@linux.intel.com
Signed-off-by: Priyank Rathod <rathodpriyank@google.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://patch.msgid.link/20260928-b4-fix-aer-memleaks-v5-3-ba6b94c9c9a6@google.com
|
|
Add IPQ9650 support to the Qualcomm NVMEM cpufreq driver so the supported
OPP can be selected at runtime using the eFuse value and the
opp-supported-hw OPP property. Also block the generic cpufreq-dt platform
device for IPQ9650 so the NVMEM-based driver is used.
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
Select the corresponding pinctrl and pinmux generic Kconfig symbols
when PINCTRL_SCMI is enabled.
Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
Acked-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
During probe, populate the pinctrl device with group info
so that the generic callbacks can be used to fetch group
count, name, and pins.
Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
Acked-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
During probe, populate the pinctrl device with function info
so that the generic callbacks can be used to fetch function
count, name, and groups. Remove locally stored functions
since caching them in this driver is no longer needed.
Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
Acked-by: Sudeep Holla <sudeep.holla@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
the sband information existed as a single static struct and was
directly modified in place by both the stack and the driver. If the
regdom was ever changed to 00 where all the S1G channels are NO_IR
and a bus module then removed, these flags would remain even after
changing the regdom and prevent channels from being used.
Instead, make sure we copy the sband each time we init our mac80211
hw such that when a bus module is removed the state is reset and
flags don't persist.
Link: https://patch.msgid.link/20261007050000.127009-4-lachlan.hodges@morsemicro.com
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
|
|
Introduce monitor mode support by extending the command to add a
monitor interface to the firmware and inserting the S1G radiotap TLV.
Also rework the .configure_filter() callback to better handle frame
filtering when we are in monitor mode. This implementation works best
as a standalone sniffer currently, as support is yet to be added in
mac80211 to handle building the radiotap for tx frames (i.e if you
bind a monitor interface to an existing station or AP).
Right now the S1G radiotap header is not really complete and lacks
the ability to convey the frequency offset and correct NDP reporting.
The process to amend the S1G TLV will begin after this initial
support is complete.
Link: https://patch.msgid.link/20261007050000.127009-3-lachlan.hodges@morsemicro.com
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
|
|
Right now we look up the station on rx to update its average RSSI but
then hand the frame to mac80211 without it, leaving mac80211 to look
the station up again. Use ieee80211_rx_napi() and rework the code a
bit so we pass the station directly to mac80211 to prevent another
lookup.
Link: https://patch.msgid.link/20261007050000.127009-2-lachlan.hodges@morsemicro.com
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
|
|
_update_wl_mlo_info() derives path_rf_band, link_mode, dbcc_en and
other per-RF-path fields from the current MLO link_status, but never
wrote mlo_info->rf_combination in any of the three link_status cases.
The field stayed at its zero-initialized value, which aliases
BTC_MLO_RF_2_PLUS_0.
_set_bind_info() and _set_coex_binding() both branch on
rf_combination to decide how to bind WL RF-paths to BT devices for
1+1, 2+2, 2+0 and 0+2 MLO combinations. With the field always zero,
those branches silently treated every MLO combination as 2+0,
producing an incorrect WL/BT binding whenever the real combination
was 1+1, 2+2 or 0+2.
Set rf_combination to the matching BTC_MLO_RF_* value in each of the
2+0, 0+2 and 1+1/2+2 branches so the binding logic sees the actual
RF combination.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-16-pkshih@realtek.com
|
|
Nothing drives the BTG control that turns the BT TX/RX on and off, so the
BT keeps transmitting and receiving even where COEX already knows it is
not in use, and WL takes interference it does not have to.
Program it from the BT enable state coex already maintains, which is the
same value reported to the firmware, so a driver-side write and a
firmware-side one always agree. This matters for the BT-only case, where
that state is forced to enable both BT while the per-BT enable may still
be clear.
That report was not actually reaching the firmware. The control
information is sent only when it differs from what was sent last, but
the comparison is inverted, so an unchanged run sends a redundant
command while a real change is dropped. Drop the inversion, so the
state programmed here is the state the firmware is told about.
Each BT keeps its own shadow of what was programmed and of whether that
is trustworthy, rather than writing on a change of the enable state. A
change is a one-shot edge, so an RF write the lower layer refuses would
never be retried, and an offloaded write can be refused for reasons coex
cannot see. The shadow is dropped on init and on a radio-state change
since the RF may have been re-initialized, and compared on every run so
that a redundant write is suppressed without losing the retry. Skip the
whole thing while the RF is off, and on chips with a single BT, which do
not drive this control from the driver side.
Report the state and the shadow in the coex mechanism-status dump.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-15-pkshih@realtek.com
|
|
The WiFi BE serials chips could disable BT TX/RX by BTG control, with this
control logic, WiFi could lower down the interference signal from BT.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-14-pkshih@realtek.com
|
|
Two unrelated enumerations describe a BT antenna switch type. The one
the RTL8922D antenna configuration uses numbers the absent switch as
zero and the internal switch as one, while the older one numbers the
internal switch as zero. The shared 2-antenna case picked the internal
value from the older enumeration, so it stored zero and claimed no
switch at all.
A BT whose switch type says there is no switch is treated as not sharing
an antenna with the WL RF-path that the other RF-path shares with it,
which drops the cross-talk entry for that path. Store the value from the
enumeration this field is read with. The 1-antenna and 3-antenna cases
in the same function already do.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-13-pkshih@realtek.com
|
|
The WL/BT space-interaction map that decides whether a WL RF-path and a
BT take a TDD or an FDD action is built from the antenna-division map
with the cross-talk map. A WL RF-path that physically shares its
antenna with a BT must be marked in the antenna-division map, otherwise
it is only ever marked interacting when the measured WL RSSI happens to
fall below the BT Tx interference threshold, and a shared-antenna design
with a strong WL signal gets bound to FDD where it has to coexist in
time instead.
Chips with a single BT never filled that map, so fill it from the RFE
type that the antenna configuration is already derived from: mark the
one WL RF-path that carries the BTG circuit as sharing with the only BT
whenever the antenna type is shared, and leave the map clear for the
dedicated-antenna RFE types where the BT has an antenna of its own. The
second-BT and external-coexistence columns stay clear because these
designs have neither.
This is driver-internal state only. The coex init information these
chips send to firmware has no antenna-map field, so what reaches the
firmware is unchanged.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-12-pkshih@realtek.com
|
|
A BT TX power report identifies which BT device came from, in bit 7
of its second byte, whether it describes that device's 2.4 GHz
or 5/6 GHz link. The handler ignored both and always wrote the first
BT device's 2.4 GHz link info.
On a chip with two BT devices or with 5/6 GHz BT support, the reported
power therefore never reached the second device or the 5/6 GHz link.
The TDD/FDD switch threshold reads exactly those fields when the WL
link is not on 2.4 GHz or when it scores the second BT, so on those
paths it kept comparing against the reset default instead of what BT
actually transmits at.
Select the device from the report's own index and the link from its
band bit, the same way the other BT mailbox reports already do.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-11-pkshih@realtek.com
|
|
The RF band that TDD and FDD bind to is picked by scoring each BT
link's weight against the WL/BT band-overlap map. That map is built
from connected WL links, so while WL is running RFK on a band it has
not associated on yet, neither band scores and the binding ends up
empty. Coexistence then treats the chip as having no WL/BT band
overlap at all and leaves RFK unprotected against a BT device already
transmitting on that same band, which can corrupt the calibration
result.
Force the score of the band being calibrated up to the binding
threshold when any BT is on an overlapping band, so the RFK band
binds for as long as the calibration runs.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-10-pkshih@realtek.com
|
|
The TDD/FDD switch threshold is derived as the WL RSSI at which a BT
device's TX power, after antenna isolation, starts to interfere:
110 + bt_pin - ant_iso - sir_thres, in RSSI percent. Before the first
BT TX power report arrives, and on any link whose report never
arrives, bt_pin falls back to the BR/LE defaults, so those defaults
decide where coexistence flips between TDD and FDD.
Both defaults were 4 dBm, which places the threshold about 6 dB below
what the BT side actually transmits at, so the driver stays in FDD
well past the point where BT TX already interferes with WL RX. Raise
both to 10 dBm, which matches the BT TX power these designs report
once their first query completes.
The 8922A ext-SOC path already used a separate 10 dBm define for the
same reason; drop it now that the common default carries that value.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-9-pkshih@realtek.com
|
|
Firmware 0.35.119.3 moves both RTL8922A and RTL8922D to coex H2C
role-info version 11 and outsrc-set-info version 7. Add top
ver_defs entries for both chips with the new fwlrole and fcxosi
values; all other scope versions are unchanged from the previous
firmware.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-8-pkshih@realtek.com
|
|
When a BT CIS (LE-audio) link exists on a dual-BT, shared-antenna
chip, limiting WL to 1SS on the RF-path that is isolated from that
link protects WL Rx from the CIS traffic without a full freerun
fallback. Add _set_trx_nss() to compute whether that 1SS limit
should apply, which path it should apply to, and what stream count
and path the WL TRX should fall back to when it does not, gated on
a chip-reported MIMO-PS capability flag and limited to Lenovo
designs or dual-BT chips to match the hardware this has been
validated on. The result also re-arms the limit once after a device
exits low-power state, since LPS can clear the BB/RF setup the
previous decision put in place.
The RTL8922D 3-antenna shared configuration also claimed that
capability, but it has no WL path shared with BT to power down, so
the limit there would cost a stream without buying any isolation.
Measurement on that configuration confirms it, so stop reporting
the capability for it and leave the 2-antenna configuration as the
only one that does.
There is currently no driver API to apply the computed stream/path
decision to the BB and RF, so the function stops right after
printing the decision for debug and before it would otherwise update
dm->wl_trx_nss, recompute the cross-talk maps, or call into set_rfe().
Those steps follow once that HW-apply API exists.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-7-pkshih@realtek.com
|
|
The TDD/FDD binding logic consumed dm->sit_xmap and dm->xtk_xmap to
decide whether a WL RF-path and a BT device need TDD or FDD
coexistence, but nothing in the driver ever wrote those two maps, so
they stayed all-zero and the binding logic silently fell back to
whatever that implied. Add _update_wl_rssi_status() to track the
minimum WL RSSI across all connected roles and HW-bands and turn it
into a per-BT interference state by comparing it against each BT's
Tx power minus antenna isolation, and _update_sdm_map() to turn that
state plus the existing antenna-sharing map into the cross-talk and
space-interaction maps the binding logic expects.
Call _update_wl_rssi_status() from the per-station notify path where
RSSI is refreshed, and recompute the maps whenever it reports a
change or whenever the BT scoreboard flips the dedicated TRX-active
bit that forces TDD regardless of RSSI. _update_sdm_map() also runs
once during coex init so the maps are populated before the first
coex cycle, and _set_coex_binding() now derives dm->fit_used_path and
a per-path dm->fit_map alongside the existing fit_xmap use, which a
later change will need once it introduces 1SS Rx-path limiting.
Whether the WL path under a 1SS RX limit still co-receives with a BT
device also depends on traffic direction: the limit only confines
RX, so the cross-talk map that feeds the TDD/FDD binding is derived
differently for downlink than for uplink. Also recompute the maps
when the per-station notify path latches a traffic direction flip,
so a downlink-to-uplink switch with a steady RSSI does not leave the
binding running on the previous direction's map until some later
event happens to refresh it.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-6-pkshih@realtek.com
|
