summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-06-09net: mana: Allocate interrupt context for each EQ when creating vPortLong Li
Use GIC functions to create a dedicated interrupt context or acquire a shared interrupt context for each EQ when setting up a vPort. The caller now owns the GIC reference across the EQ create/destroy lifecycle: mana_create_eq() calls mana_gd_get_gic() before creating each EQ and mana_destroy_eq() calls mana_gd_put_gic() after destroying it. The msix_index invalidation is moved from mana_gd_deregister_irq() to the mana_gd_create_eq() error path so that mana_destroy_eq() can read the index before teardown. Signed-off-by: Long Li <longli@microsoft.com> Link: https://patch.msgid.link/20260605005717.2059954-6-longli@microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: mana: Use GIC functions to allocate global EQsLong Li
Replace the GDMA global interrupt setup code with the new GIC allocation and release functions for managing interrupt contexts. This changes the per-queue interrupt names in /proc/interrupts from mana_q0, mana_q1, ... to mana_msi1, mana_msi2, ... to reflect the MSI-X index rather than a zero-based queue number. The HWC interrupt name (mana_hwc) is unchanged. Signed-off-by: Long Li <longli@microsoft.com> Link: https://patch.msgid.link/20260605005717.2059954-5-longli@microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: mana: Introduce GIC context with refcounting for interrupt managementLong Li
To allow Ethernet EQs to use dedicated or shared MSI-X vectors and RDMA EQs to share the same MSI-X, introduce a GIC (GDMA IRQ Context) with reference counting. This allows the driver to create an interrupt context on an assigned or unassigned MSI-X vector and share it across multiple EQ consumers. Signed-off-by: Long Li <longli@microsoft.com> Link: https://patch.msgid.link/20260605005717.2059954-4-longli@microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: mana: Query device capabilities and configure MSI-X sharing for EQsLong Li
When querying the device, adjust the max number of queues to allow dedicated MSI-X vectors for each vPort. The per-vPort queue count is clamped towards MANA_DEF_NUM_QUEUES but will not exceed the hardware maximum reported by the device. MSI-X sharing among vPorts is enabled when there are not enough MSI-X vectors for dedicated allocation, or when the platform does not support dynamic MSI-X allocation (in which case all vectors are pre-allocated at probe time and sharing is always used). The msi_sharing flag is reset at the top of mana_gd_query_max_resources() so it is recomputed from current hardware state on each probe or resume cycle. Clamp apc->max_queues to gc->max_num_queues_vport in mana_init_port() so that on resume, if max_num_queues_vport has decreased due to fewer MSI-X vectors, num_queues is reduced accordingly before EQ allocation. A device reporting zero ports now results in a fatal probe error since the per-vPort MSI-X math requires at least one port. Rename mana_query_device_cfg() to mana_gd_query_device_cfg() as it is used at GDMA device probe time for querying device capabilities. Signed-off-by: Long Li <longli@microsoft.com> Link: https://patch.msgid.link/20260605005717.2059954-3-longli@microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: mana: Create separate EQs for each vPortLong Li
To prepare for assigning vPorts to dedicated MSI-X vectors, remove EQ sharing among the vPorts and create dedicated EQs for each vPort. Move the EQ definition from struct mana_context to struct mana_port_context and update related support functions. Export mana_create_eq() and mana_destroy_eq() for use by the MANA RDMA driver. RSS QPs now take a vport reference via pd->vport_use_count to ensure EQs outlive all QP consumers. The vport must already be configured by a raw QP before an RSS QP can be created. EQs are only destroyed when the last QP (raw or RSS) on the PD releases its reference. Restrict each vport to a single RSS QP. The hardware only supports one steering configuration (indirection table / hash key) per vport, and mana_disable_vport_rx() on QP destroy disables RX globally for the vport. Previously, creating a second RSS QP would silently overwrite the first QP's steering config and destroy would blackhole all traffic. This is now explicitly rejected with -EBUSY. Existing applications (DPDK being the primary RDMA consumer) always create one RSS QP per vport, so no real-world flows are affected. Reject cross-port PD sharing for both raw and RSS QPs. Since EQs and vport configuration are per-port, a PD is bound to the port used by its first raw QP. Subsequent QPs on the same PD must use the same port or the creation fails with -EINVAL. Previously this was silently broken: with shared EQs it appeared to work, but with per-vPort EQs a cross-port PD would cause wrong-port EQ teardown and corruption. DPDK creates one PD per port so no existing flows are affected. Serialize mana_set_channels() and the async per-port queue reset handler against RDMA vport configuration to prevent RDMA from claiming the vport during the detach/attach window. A channel_changing flag is set under apc->vport_mutex before detach and checked by mana_cfg_vport() when called from the RDMA path, blocking RDMA from grabbing the vport during the entire window. When the port is down and RDMA already holds the vport, the channel change is rejected with -EBUSY. Signed-off-by: Long Li <longli@microsoft.com> Link: https://patch.msgid.link/20260605005717.2059954-2-longli@microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock on Netlink path for SET opsJakub Kicinski
Make ethtool not take rtnl_lock for SET commands when operation is performed on an ops-locked driver. cfg/cfg_pending are now ops-locked, since only ethtool modifies them. Some SET driver callbacks will still need rtnl_lock, most notably those which may end up calling netdev_update_features() or the qdisc layer (via netif_set_real_num_tx_queues()). Let drivers selectively opt back into the rtnl_lock with a new bitfield in ops. We need two helpers since Netlink and ioctl cmds have different values. Keep the helpers side by side in common.h to make sure they get updated together, even tho they will only get called from ioctl.c and netlink.c. SET commands which don't use ethnl_default_set_doit() are converted by subsequent commits. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-6-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: optionally skip rtnl_lock on Netlink path for GET opsJakub Kicinski
ethnl_default_doit() and ethnl_default_dump_one() are both used exclusively for GET callbacks (former to get info for a single device or get global strings). ops-locked devices don't need rtnl_lock for GET callbacks, stop taking it. Introduce an opt-out mechanism for devices which use phylink (fbnic) since phylink currently depends on rtnl_lock protection. Subsequent patches will add more exceptions, anyway. Practically the new helpers for judging if command needs rtnl_lock could also call netdev_need_ops_lock() but I find that it makes the code in the callers slightly less obvious. Add a helper for IOCTLs already, even tho it's unused so that we can keep them in sync as the series progresses. This is the first user-visible step of moving ethtool ops out from under rtnl. Subsequent patches do the same for SET ops, as well as the ioctl path. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: make dev->hwprov ops-protectedJakub Kicinski
dev->hwprov tracks the active hwtstamp provider for the device. Make it ops protected (instance lock if the netdev driver opts into holding instance lock around callbacks, otherwise rtnl_lock). hwprov is written and read in: - drivers/net/phy/phy_device.c phydev and ops protection don't currently mix, add a comment - net/ethtool/ as of now holds both rtnl lock and ops lock, this one will soon only hold one lock or the other read in: - net/core/dev_ioctl.c holds both rtnl lock and ops lock - net/core/timestamping.c RCU reader The new netdev_ops_lock_dereference() helper does not have "compat" in the name. The name would be quite long and I think in this case it should be obvious that we need _a_ lock. netdev_lock_dereference() already exists and means dev->lock is always expected. Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09net: ethtool: relax ethnl_req_get_phydev() locking assertionJakub Kicinski
phydev <> netdev linking and lifecycle depends on rtnl_lock. We want to switch to instance locks for most ethtool ops. Let's add an assert that ops locked devices don't use phydev today. If one does we can either opt the phy ops out of being purely ops locked, or do deeper surgery to make phy locking ops-compatible. I don't think there's any fundamental challenge to make that work. Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260605002912.3456868-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-06-09igc: skip RX timestamp header for frame preemption verificationKhaiWenTan
When RX hardware timestamping is enabled, a 16-byte inline timestamp header is added to the start of the packet buffer, causing FPE handshake verification to fail. Because an incorrect packet buffer is passed to igc_fpe_handle_mpacket(), the mem_is_zero() check inspects the timestamp metadata instead of the actual mPacket payload. As a result, valid Verify/Response mPackets can be missed when inline RX timestamps are present. Pass pktbuf + pkt_offset to igc_fpe_handle_mpacket() so it inspects the actual mPacket payload instead of the timestamp header. Fixes: 5422570c0010 ("igc: add support for frame preemption verification") Co-developed-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com> Signed-off-by: KhaiWenTan <khai.wen.tan@linux.intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-09ixgbe: do not configure xps for XDP queuesLarysa Zaremba
netif_set_xps_queue() should not be called for an XDP Tx queue, since such queues are not netdev-exposed. On systems with number of CPUs >=64, on E610 adapter, netdev is configured with maximum number queue pairs being 63 (due to MSI-X assignment), but configuring XDP results in 64 XDP queues. So, during XDP program load, when netif_set_xps_queue() is called for the last XDP queue, we get a WARNING with a call trace and KASAN report afterwards (if enabled). [ 2012.699800] WARNING: net/core/dev.c:2854 at __netif_set_xps_queue+0x116a/0x1e40, CPU#36: xdpsock/103668 [...] [ 2012.700029] RIP: 0010:__netif_set_xps_queue+0x116a/0x1e40 [ 2012.700035] Code: b6 34 06 48 89 f8 83 e0 07 83 c0 01 40 38 f0 7c 09 40 84 f6 0f 85 03 0a 00 00 0f b7 44 24 40 66 43 89 44 6a 18 e9 01 fb ff ff <0f> 0b e9 f2 ee ff ff 44 8b 44 24 44 45 85 c0 74 50 4d 85 e4 0f 84 [ 2012.700040] RSP: 0018:ffff8882369aeb28 EFLAGS: 00010246 [ 2012.700046] RAX: 0000000000000000 RBX: 000000000000003f RCX: 0000000000000000 [ 2012.700050] RDX: 1ffff1111da3d891 RSI: ffff888120e34250 RDI: ffff8888ed1ec488 [ 2012.700054] RBP: ffff888913281560 R08: 0000000000000000 R09: ffff8888ed1ec000 [ 2012.700058] R10: ffff8888a2e83180 R11: 0000000000000000 R12: 0000000000007fa8 [ 2012.700061] R13: 000000000000003f R14: ffff888120e34854 R15: ffff8889132817c8 [ 2012.700065] FS: 00007fc8ea9ff740(0000) GS:ffff88884cefe000(0000) knlGS:0000000000000000 [ 2012.700069] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2012.700073] CR2: 00007f81c8000020 CR3: 00000002299f8006 CR4: 00000000007726f0 [ 2012.700077] PKRU: 55555554 [ 2012.700080] Call Trace: [ 2012.700084] <TASK> [ 2012.700087] ? ktime_get+0x61/0x150 [ 2012.700097] ? usleep_range_state+0x133/0x1b0 [ 2012.700108] ? __pfx_usleep_range_state+0x10/0x10 [ 2012.700114] netif_set_xps_queue+0x31/0x50 [ 2012.700119] ixgbe_configure_tx_ring+0x472/0x920 [ixgbe] [...] [ 2012.700486] ixgbe_xdp+0x38f/0x750 [ixgbe] [...] [ 2012.701094] BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x1ac5/0x1e40 [ 2012.701100] Write of size 4 at addr ffff88888d43cff8 by task xdpsock/103668 Skip XPS configuration for XDP Tx queues. Fixes: 33fdc82f0883 ("ixgbe: add support for XDP_TX action") Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Patryk Holda <patryk.holda@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-09idpf: add padding to PTP virtchnl structuresPrzemyslaw Korba
Add padding to virtchnl2 PTP structures to match the Control Plane expected message sizes: * virtchnl2_ptp_get_dev_clk_time: 8 -> 16 bytes * virtchnl2_ptp_set_dev_clk_time: 8 -> 16 bytes * virtchnl2_ptp_get_cross_time: 16 -> 24 bytes The FW expects the above sizes and PTP negotiation fails due to the mismatch. Previously neither the FW nor the driver checked message/reply sizes strictly, so the problem appeared only after recent validation improvements. reproduction steps: ptp4l -i <pf> -m Observe: failed to open /dev/ptp0: Permission denied Fixes: bf27283ba594 ("virtchnl: add PTP virtchnl definitions") Cc: stable@vger.kernel.org Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2026-06-09wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reportedWen Gong
When firmware reports NSS ratio support, SUPPORTS_VHT_EXT_NSS_BW is enabled in ath12k. However, IEEE80211_VHT_EXT_NSS_BW_CAPABLE must also be set to make the advertisement valid. According to IEEE Std 802.11-2024, Subclause 9.4.2.156.3 (Supported VHT-MCS and NSS Set subfields), the VHT Extended NSS BW Capable bit indicates whether a STA is capable of interpreting the Extended NSS BW Support subfield of the VHT capabilities information field. Advertising extended NSS BW support without setting this capability bit is therefore invalid. Without this change, mac80211 detects the inconsistency and logs: ieee80211 phy0: copying sband (band 1) due to VHT EXT NSS BW flag This indicates that mac80211 implicitly aligns IEEE80211_VHT_EXT_NSS_BW_CAPABLE during ieee80211_register_hw(). Explicitly setting the bit in ath12k avoids this fixup and ensures capabilities are advertised correctly by the driver. This change follows the same approach as the existing ath11k fix. https://lore.kernel.org/all/20211013073704.15888-1-wgong@codeaurora.org/ Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.5-01651-QCAHKSWPL_SILICONZ-1 Fixes: 18ab9d038fad ("wifi: ath12k: add support for 160 MHz bandwidth") Signed-off-by: Wen Gong <quic_wgong@quicinc.com> Signed-off-by: Maharaja Kennadyrajan <maharaja.kennadyrajan@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260604095831.2674298-1-maharaja.kennadyrajan@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-09wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bitsBaochen Qiang
On WCN7850, after the following sequence: 1. load ath12k and connect to a non-MLO AP 2. disconnect and connect to an MLO AP 3. disconnect and reconnect to the non-MLO AP the third connection always fails with a 4-Way handshake timeout. The supplicant transmits message 2 of 4 four times in response to AP retries of message 1, but the AP never sees any of them. ath12k_dp_vdev_tx_attach() composes dp_link_vif->tcl_metadata using |=, but dp_link_vif is embedded in struct ath12k_dp_vif and its slots are reused across vif/peer teardown and setup. Since tcl_metadata is never cleared on detach, vdev_id bits from a previous attach remain set when the same link slot is reused with a different vdev_id. In this specific issue, the same link slot is used for vdev_id 0, then vdev_id 1, then vdev_id 0 again, the OR yields tcl_metadata == 0x9, which encodes vdev_id 1 in the HTT_TCL_META_DATA_VDEV_ID field even though ti.vdev_id is 0. Firmware then routes the EAPOL frame to the wrong vdev and the AP never receives message 2. Use plain assignment instead of |= so the field is fully recomputed from the current arvif on every attach. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: af66c7640cf9 ("wifi: ath12k: Refactor ath12k_vif structure") Signed-off-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260609-ath12k-fix-eapol-tcl-metadata-v1-1-d47e6f90d4ee@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-09wifi: ath: Update copyright in testmode_i.hJeff Johnson
Update Qualcomm copyrights per current legal guidance. Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/20260608-ath12k-copyright-v2-4-37504d70b03c@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-09wifi: ath10k: Update Qualcomm copyrightsJeff Johnson
Update Qualcomm copyrights per current legal guidance. Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/20260608-ath12k-copyright-v2-3-37504d70b03c@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-09wifi: ath11k: Update Qualcomm copyrightsJeff Johnson
Update Qualcomm copyrights per current legal guidance. Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/20260608-ath12k-copyright-v2-2-37504d70b03c@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-09wifi: ath12k: Update Qualcomm copyrightsJeff Johnson
Update Qualcomm copyrights per current legal guidance. Assisted-by: Claude:claude-sonnet-4-6 Link: https://patch.msgid.link/20260608-ath12k-copyright-v2-1-37504d70b03c@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-06-09net: mctp: usb: don't fail mctp_usb_rx_queue on a deferred submissionJeremy Kerr
In the ndo_open path, a deferred queue open will report a failure, and so the netdev will not be ndo_stop()ed, leaving us with the rx_retry work potentially pending. Don't report a deferred queue as an error, as we are still operational. This means we use the ndo_stop() path for future cleanup, which handles rx_retry_work cancellation. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260608-dev-mctp-usb-rx-requeue-v2-2-29a3aa507609@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09net: mctp: usb: fix race between urb completion and rx_retry cancellationJeremy Kerr
It's possible that sequencing between setting ->stopped and cancelling the rx_retry work (in ndo_stop) could leave us with an urb queued: T1: ndo_stop T2: rx_retry_work ------------ ---------------- LD: ->stopped => false ST: ->stopped <= true usb_kill_urb() mctp_usb_rx_queue() usb_submit_urb() cancel_delayed_work_sync() That urb completion can then re-schedule rx_retry_work. Strenghen the sequencing between the stop (preventing another requeue) and the cancel by updating both atomically under a new rx lock. After setting ->rx_stopped, and cancelling pending work, we know that the requeue cannot occur, so all that's left is killing any pending urb. Fixes: 0791c0327a6e ("net: mctp: Add MCTP USB transport driver") Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260608-dev-mctp-usb-rx-requeue-v2-1-29a3aa507609@codeconstruct.com.au Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09hv_netvsc: use kmap_local_page in netvsc_copy_to_send_bufAnton Leontev
netvsc_copy_to_send_buf() copies page buffer entries into the VMBus send buffer using phys_to_virt() on the entry PFN. Entries for the RNDIS header and the skb linear data come from kmalloc'd memory and are always in the kernel direct map, but entries for skb fragments reference page cache or user pages, which on 32-bit x86 with CONFIG_HIGHMEM=y can live above the LOWMEM boundary. For such a page phys_to_virt() returns an address outside the direct map and the subsequent memcpy() faults on the transmit softirq path, which is fatal. Map the pages with kmap_local_page() instead, handling two properties of the page buffer entries: - pb[i].pfn is a Hyper-V PFN at HV_HYP_PAGE_SIZE (4K) granularity, not a native PFN. Reconstruct the physical address first and derive the native page from it, so the mapping stays correct where PAGE_SIZE > HV_HYP_PAGE_SIZE (e.g. arm64 with 64K pages). - Since commit 41a6328b2c55 ("hv_netvsc: Preserve contiguous PFN grouping in the page buffer array"), an entry describes a full physically contiguous fragment and pb[i].len can exceed PAGE_SIZE, while kmap_local_page() maps a single page. Copy page by page, splitting at native page boundaries. The copy path only handles packets smaller than the send section size (6144 bytes by default); larger packets take the cp_partial path where only the RNDIS header is copied. So entries here are bounded by the section size and a copy is split at most once on 4K-page systems. On !CONFIG_HIGHMEM configs kmap_local_page() folds to page_address() and no mapping work is added. Fixes: c25aaf814a63 ("hyperv: Enable sendbuf mechanism on the send path") Cc: stable@vger.kernel.org Signed-off-by: Anton Leontev <leontyevantony@gmail.com> Link: https://patch.msgid.link/20260604165938.32033-1-leontyevantony@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09netconsole: close netdevice unregister window during target resumeBreno Leitao
process_resume_target() removes the target from target_list before calling resume_target() so that netpoll_setup() can run with interrupts enabled, then re-adds it once setup completes. netpoll_setup() acquires a net_device reference (netdev_hold()) and releases the RTNL before returning. While the target is off target_list and the RTNL is not held, netconsole_netdev_event() cannot find it. If the egress device is unregistered in that window, the NETDEV_UNREGISTER notifier walks target_list, misses the resuming target, and never tears it down. The target is then re-added in STATE_ENABLED still holding a reference to the now-unregistered device, leaking it and hanging unregister_netdevice() in netdev_wait_allrefs(). Re-check under RTNL before re-publishing the target: if the device left NETREG_REGISTERED while we were off the list, run do_netpoll_cleanup() and mark the target disabled. Taking the RTNL across the check and the list_add() serialises against the NETDEV_UNREGISTER notifier, which also runs under RTNL, so the device is either still registered (and the notifier will find the re-added target later) or already unregistering (and we drop the reference here). netdev_wait_allrefs() runs from netdev_run_todo() outside the RTNL, so dropping the reference here cannot deadlock against the pending unregister. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260604-netcons_fix_before_move-v3-5-ab055b3a6aa5@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09netconsole: clean up deactivated targets dropped before the cleanup workerBreno Leitao
drop_netconsole_target() downgrades a STATE_DEACTIVATED target to STATE_DISABLED and then only calls netpoll_cleanup() when the target is STATE_ENABLED. A target becomes STATE_DEACTIVATED when its underlying interface is unregistered: netconsole_netdev_event() moves it to target_cleanup_list, and netconsole_process_cleanups_core() is expected to run do_netpoll_cleanup() on it. Now that drop_netconsole_target() takes target_cleanup_list_lock around the unlink, a configfs removal racing with NETDEV_UNREGISTER can pull the target off target_cleanup_list before the cleanup worker processes it. The notifier drops the lock before calling netconsole_process_cleanups_core(), so the worker then iterates a list that no longer contains the target and never runs do_netpoll_cleanup() on it. Because drop_netconsole_target() has already rewritten the state to STATE_DISABLED, its own STATE_ENABLED check is false and netpoll_cleanup() is skipped too. The net_device reference taken by netpoll_setup() is then leaked and unregister_netdevice() hangs forever in netdev_wait_allrefs(). Capture whether the target still owns a netpoll before the state is downgraded and clean it up for both STATE_ENABLED and STATE_DEACTIVATED targets. netpoll_cleanup() is idempotent -- it skips when np->dev is already NULL -- so it is safe even when the cleanup worker won the race and already tore the netpoll down. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260604-netcons_fix_before_move-v3-4-ab055b3a6aa5@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09netconsole: take target_cleanup_list_lock in drop_netconsole_target()Breno Leitao
drop_netconsole_target() unlinks the target while only holding target_list_lock. However, when the underlying interface has been unregistered, netconsole_netdev_event() moves the target from target_list to target_cleanup_list, and netconsole_process_cleanups_core() walks that list under target_cleanup_list_lock only. If a user removes the configfs target at the same time the cleanup worker is iterating target_cleanup_list, list_del() can corrupt the list because the two paths take disjoint locks while operating on the same list node. Acquire target_cleanup_list_lock around the list_del() so the unlink is serialised against netconsole_process_cleanups_core() regardless of which list the target currently belongs to. The state transition that downgrades STATE_DEACTIVATED to STATE_DISABLED is left intact and is performed under the same combined locking, preserving the existing ordering with resume_target(). Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260604-netcons_fix_before_move-v3-3-ab055b3a6aa5@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09netconsole: do not dequeue pooled skbs that cannot satisfy lenBreno Leitao
find_skb() falls back to np->skb_pool when the GFP_ATOMIC alloc_skb() fails. The pool is refilled by refill_skbs(), which always allocates buffers of MAX_SKB_SIZE (ethhdr + iphdr + udphdr + MAX_UDP_CHUNK == 1502 bytes). netconsole, however, computes the requested length dynamically as total_len + np->dev->needed_tailroom If the egress device declares a non-zero needed_tailroom (e.g. some tunnel or hardware accelerator devices), the required length can exceed MAX_SKB_SIZE. The pooled skb is then handed back to the caller, which immediately performs skb_put(skb, len), trips the tail > end check, and triggers skb_over_panic(). Leave the normal alloc_skb(len, GFP_ATOMIC) path untouched -- the slab allocator can still satisfy oversized requests when memory is available, so senders to devices with non-zero needed_tailroom keep working in the common case. Only the pool fallback is gated: when alloc_skb() failed and len exceeds the pool buffer size, skip the skb_dequeue() instead of burning a pre-allocated skb on a request that would later trip skb_over_panic(). Reserving pool entries for requests they can actually satisfy also keeps the panic path, which depends on the pool being primed, intact. When that drop happens, emit a rate-limited net_warn() so the user notices that netconsole is unable to push messages on the egress device. The warn is skipped under in_nmi() for the same reason schedule_work() is: printk machinery taken by net_warn_ratelimited() is not NMI-safe and would risk recursing into the same nbcon console we are servicing. MAX_SKB_SIZE / MAX_UDP_CHUNK were private to net/core/netpoll.c. Move them to include/linux/netpoll.h so netconsole can reference the same definition that refill_skbs() uses, keeping the two in sync by construction. The header now pulls in <linux/ip.h> and <linux/udp.h> explicitly so MAX_SKB_SIZE remains self-contained for any future user. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260604-netcons_fix_before_move-v3-2-ab055b3a6aa5@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09netconsole: do not schedule skb pool refill from NMIBreno Leitao
When alloc_skb() fails in find_skb(), the fallback path dequeues an skb from np->skb_pool and unconditionally calls schedule_work() to top the pool back up. schedule_work() ends up taking the workqueue pool locks, which are not NMI-safe. netconsole_write() is registered as the nbcon write_atomic callback and is explicitly marked CON_NBCON_ATOMIC_UNSAFE, meaning it is invoked from emergency/panic contexts including NMIs. If the NMI interrupts a thread already holding the workqueue pool lock, calling schedule_work() self-deadlocks and the panic message that was being printed is lost. Introduce netcons_skb_pop() to fold the pool dequeue and the refill request into a single helper. The helper skips schedule_work() when called from NMI context; the pool is best-effort, so the refill is simply deferred to the next non-NMI find_skb() call that exhausts alloc_skb() and hits the fallback again. This keeps the fast path untouched and the locking rules around the fallback pool documented in one place. Note this only removes the schedule_work() hazard from the NMI path. The allocation itself is still not fully NMI-safe: the alloc_skb(GFP_ATOMIC) attempted first may take slab locks, and the skb_dequeue() fallback takes np->skb_pool.lock, so either can deadlock if the NMI interrupts a holder of those locks. Closing those windows requires an NMI-safe (lockless) skb pool and is left to a follow-up; this patch addresses the schedule_work() deadlock, which is both the most likely and the easiest to trigger. Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260604-netcons_fix_before_move-v3-1-ab055b3a6aa5@debian.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09wifi: mt76: Drop unneeded mt76_register_debugfs_fops() return checksIngyu Jang
mt76_register_debugfs_fops() returns the dentry from debugfs_create_dir(), which yields an error pointer on failure (notably ERR_PTR(-ENODEV) when CONFIG_DEBUG_FS=n), never NULL. Per commit ff9fb72bc077 ("debugfs: return error values, not NULL"), callers do not need to check the return value. Drop the dead !dir checks in mt7615/mt7915/mt7921/mt7925/mt7996 _init_debugfs(). Converting them to IS_ERR() instead would have exposed a probe abort on CONFIG_DEBUG_FS=n, since each *_init_debugfs() caller propagates the helper's return value. This patch supersedes an earlier proposal that converted the checks to IS_ERR(). Link: https://lore.kernel.org/all/20260514193243.2518979-1-ingyujang25@korea.ac.kr Signed-off-by: Ingyu Jang <ingyujang25@korea.ac.kr> Link: https://patch.msgid.link/20260519085214.164846-1-ingyujang25@korea.ac.kr Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921: assert sniffer on chanctx changeDevin Wittmayer
mt7921_change_chanctx() configures the channel for monitor vifs but does not re-assert sniffer mode. mt7925_change_chanctx() does. Match mt7925 by adding the missing mt7921_mcu_set_sniffer(true) call, completing the architectural pattern from commit 914189af23b8 ("wifi: mt76: mt7921: fix channel switch fail in monitor mode"). The user-visible regression this asymmetry produced on v6.17 and v6.18 was addressed by commit cdb2941a516c ("Revert "wifi: mt76: mt792x: improve monitor interface handling"") in v6.19 and backported to the 6.17.y and 6.18.y stable trees. This patch is defense in depth in case the NO_VIRTUAL_MONITOR change is reintroduced in a future series. Tested-by: Nick Morrow <morrownr@gmail.com> Tested-on: RasPi4B, RasPiOS 64 bit, Alfa AWUS036AXML mt7921u Tested-on: RasPi4B, RasPiOS 64 bit, Netgear A9000 mt7925u Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca> Link: https://patch.msgid.link/20260515183921.23484-1-lucid_duck@justthetip.ca Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09octeontx2-af: fix memory leak in rvu_setup_hw_resources()Dawei Feng
If rvu_npc_exact_init() fails in rvu_setup_hw_resources(), the function returns directly instead of jumping to the error handling path. This causes a resource leak for the previously initialized CGX, NPC, fwdata, and MSI-X states. Fix this by replacing the direct return with goto cgx_err to ensure proper cleanup. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6. An x86_64 allyesconfig build showed no new warnings. As we do not have access to Marvell OcteonTX2 RVU AF hardware to test with, no runtime testing was able to be performed. Fixes: 3571fe07a090 ("octeontx2-af: Drop rules for NPC MCAM") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn> Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Link: https://patch.msgid.link/20260604143756.1524482-1-dawei.feng@seu.edu.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-06-09wifi: mt76: mt7996: fix potential tx_retries underflowRyder Lee
When FIELD_GET returns 0 for the retry count, subtracting 1 causes an unsigned integer underflow, resulting in tx_retries becoming a very large value (0xFFFFFFFF for u32). Fix by checking if count is non-zero before subtracting 1. Fixes: 2461599f835e ("wifi: mt76: mt7996: get tx_retries and tx_failed from txfree") Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Link: https://patch.msgid.link/20260605113306.3485554-4-ryder.lee@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7925: fix potential tx_retries underflowRyder Lee
When FIELD_GET returns 0 for the retry count, subtracting 1 causes an unsigned integer underflow, resulting in tx_retries becoming a very large value (0xFFFFFFFF for u32). Fix by checking if count is non-zero before subtracting 1. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Link: https://patch.msgid.link/20260605113306.3485554-3-ryder.lee@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921: fix potential tx_retries underflowRyder Lee
When FIELD_GET returns 0 for the retry count, subtracting 1 causes an unsigned integer underflow, resulting in tx_retries becoming a very large value (0xFFFFFFFF for u32). Fix by checking if count is non-zero before subtracting 1. Fixes: 9aecfa754c7f ("wifi: mt76: mt7921e: report tx retries/failed counts in tx free event") Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Link: https://patch.msgid.link/20260605113306.3485554-2-ryder.lee@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7915: fix potential tx_retries underflowRyder Lee
When FIELD_GET returns 0 for the retry count, subtracting 1 causes an unsigned integer underflow, resulting in tx_retries becoming a very large value (0xFFFFFFFF for u32). Fix by checking if count is non-zero before subtracting 1. Fixes: 943e4fb96e6f ("wifi: mt76: mt7915: report tx retries/failed counts for non-WED path") Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Link: https://patch.msgid.link/20260605113306.3485554-1-ryder.lee@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921: disable auto regd changes after user setJB Tsai
Add regd_user flag to block automatic regulatory domain updates if set by user. Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: JB Tsai <jb.tsai@mediatek.com> Link: https://patch.msgid.link/20260303053637.465465-5-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921: add auto regdomain switch supportJB Tsai
Implement 802.11d-based automatic regulatory domain switching to dynamically determine the regulatory domain at runtime. The scan-done event structure by reusing reserved padding and appending new fields; the layout and values remains backward-compatible with existing users. Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: JB Tsai <jb.tsai@mediatek.com> Link: https://patch.msgid.link/20260303053637.465465-4-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921: refactor regulatory notifier flowJB Tsai
Rename mt7921_regd_update() to mt7921_mcu_regd_update() to centralize regd updates with error handling. Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: JB Tsai <jb.tsai@mediatek.com> Link: https://patch.msgid.link/20260303053637.465465-3-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921: refactor CLC support check flowJB Tsai
Move the disable_clc module parameter to regd.c and introduce mt7921_regd_clc_supported() to centralize CLC support checks. Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: JB Tsai <jb.tsai@mediatek.com> Link: https://patch.msgid.link/20260303053637.465465-2-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921: refactor regulatory domain handling to regd.[ch]JB Tsai
Move regd logic to regd.c and regd.h files Co-developed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: JB Tsai <jb.tsai@mediatek.com> Link: https://patch.msgid.link/20260303053637.465465-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7996: disable UNI_BSS_INFO_PROTECT_INFO for mt7996Ryder Lee
The current MT7996 firmware causes TX failure and need further investigation, so it is temporarily disabled. MT7992 and MT7990 are working normally. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Link: https://patch.msgid.link/6427326eb4e8f375c63379f7a0df7e2ae9d120a4.1774458901.git.ryder.lee@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt76x2u: Add support for ELECOM WDC-867SU3SZenm Chen
Add the ID 056e:400a to the table to support an additional MT7612U adapter: ELECOM WDC-867SU3S. Compile tested only. Cc: stable@vger.kernel.org # 5.10.x Signed-off-by: Zenm Chen <zenmchen@gmail.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260407154430.9184-1-zenmchen@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: fix argument to ieee80211_is_first_frag()Bjoern A. Zeeb
ieee80211_is_first_frag() operates on the seq_ctrl not the frame_control header field. Pass the correct one in; otherwise the results may vary. Sponsored by: The FreeBSD Foundation Fixes: 30ce7f4456ae4 ("mt76: validate rx CCMP PN") Link: https://cgit.freebsd.org/src/commit/sys/contrib/dev/mediatek/mt76/mac80211.c?id=c67fd35e58c6ee1e19877a7fe5998885683abedc Signed-off-by: Bjoern A. Zeeb <bz@FreeBSD.org> Link: https://patch.msgid.link/83s4psnr-popo-8789-757o-npr2n9n7rs2o@SerrOFQ.bet Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921u: escalate broken USB transport to device resetSean Wang
Check the USB control path before running the normal WFSYS reset flow. If USB access is no longer reliable, stop the WFSYS-only reset path, mark the device as bus_hung, and queue a USB device reset instead. Reuse the existing bus_hung state to represent transport-level failure, keeping the semantics consistent with the SDIO path. Also initialize bus_hung explicitly during probe for consistency. Reported-by: Bryam Vargas <bryamestebanvargas@gmail.com> Closes: https://lore.kernel.org/r/CANAPQziOh3sB7B8G+U3AZsFfeFN1uAg4munhwA_feZi56D7W+Q@mail.gmail.com Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260401190632.147042-2-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt792x: add common USB transport reset helpersSean Wang
Add per-device USB reset work and a control-path access check helper for mt7921u and mt7925u. This prepares common infrastructure for transport-level recovery while keeping the reset state per-device for correct lifetime handling. No functional change intended. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260401190632.147042-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt792x: report txpower for the requested vif linkSean Wang
mt792x currently reports txpower from the generic PHY cached state, which may not match the requested vif/link context. Resolve the requested link channel and derive txpower from that channel instead, with fallback to the current PHY chandef if no valid chanctx is available. Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca> Closes: https://lore.kernel.org/linux-wireless/20260130215839.53270-1-lucid_duck@justthetip.ca/ Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> Tested-by: Satadru Pramanik <satadru@gmail.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260401182322.64355-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: connac: factor out rate power limit calculationSean Wang
Factor out the per-channel rate power limit calculation into a shared helper. This avoids duplicating the same regulatory, SAR and rate-limit logic in multiple paths. Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca> Closes: https://lore.kernel.org/linux-wireless/20260130215839.53270-1-lucid_duck@justthetip.ca/ Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> Tested-by: Satadru Pramanik <satadru@gmail.com> Co-developed-by: Devin Wittmayer <lucid_duck@justthetip.ca> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260401182322.64355-2-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: connac: use a helper to cache txpower_curSean Wang
The cached txpower value is derived from the bounded channel power after applying the chainmask path delta. Use a helper for that conversion so callers do not open-code it. -- v2: - Rebased onto the latest mt76 tree - Added Reported-by, Tested-by, Co-developed-by and Signed-off-by tags Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca> Closes: https://lore.kernel.org/linux-wireless/20260130215839.53270-1-lucid_duck@justthetip.ca/ Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> Tested-by: Satadru Pramanik <satadru@gmail.com> Co-developed-by: Devin Wittmayer <lucid_duck@justthetip.ca> Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Reported-by: Lucid Duck <lucid_duck@justthetip.ca> Tested-by: Lucid Duck <lucid_duck@justthetip.ca> Link: https://patch.msgid.link/20260401182322.64355-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7996: limit work in set_bitrate_maskDylan Eskew
Calls to mt7996_set_bitrate_mask() would propagate work for all stations on the ieee80211_hw regardless of the vif specified in the call. To prevent unnecessary work in FW, limit setting the sta_rate to only the specified vif in mt7996_sta_rate_ctrl_update(). Fixes: afff4325548f0 ("wifi: mt76: mt7996: Use proper link_id in link_sta_rc_update callback") Signed-off-by: Dylan Eskew <dylan.eskew@candelatech.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260408145057.2356878-2-dylan.eskew@candelatech.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7996: reduce phy work in set_coverageDylan Eskew
In mt7996_set_coverage_class(), each phy is iterated over in calling mt7996_mac_set_coverage_class(). Thus, the phy2 and phy3 configuration logic in mt7996_mac_set_coverage_class() can be dropped. Signed-off-by: Dylan Eskew <dylan.eskew@candelatech.com> Link: https://patch.msgid.link/20260415155354.1135548-2-dylan.eskew@candelatech.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: mt7921u: add MT7902 USB supportSean Wang
Add the 0e8d:7902 USB ID and select the MT7902 WM firmware. Use the same USB queue mapping as mt7921/mt7925 so MT7902U can bind and probe through mt7921u driver. Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425160930.739237-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-06-09wifi: mt76: transform aspm_conf for pci_disable_link_stateJiajia Liu
commit b478e162f227 ("PCI/ASPM: Consolidate link state defines") changed PCIE_LINK_STATE_L0S (1) to (BIT(0) | BIT(1)). PCI_EXP_LNKCTL_ASPM_L0S (1) and PCI_EXP_LNKCTL_ASPM_L1 (2) are no longer matched with PCIE_LINK_STATE_L0S (3) and PCIE_LINK_STATE_L1 (4). On the platform enabling ASPM L0s and L1, mt76_pci_disable_aspm is not able to disable L1. Fix this by transforming aspm_conf to pcie link state. Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn> Link: https://patch.msgid.link/20260602054349.42429-1-liujia6264@gmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-23 22:16:50 +0000