summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-07-31wifi: mt76: mt7925: add MT7928 TXD/TXS/TX_DONE supportEmery Hsin
Add MT7928 TXD v2 fields, per-chip WTBL register addresses, UNI TxDone event parsing, and TXS format acceptance for MPDU/PPDU. Suppress HW AMSDU on management frames for MT7928. Signed-off-by: Xiong <xiong.huang@mediatek.com> Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075339.2578327-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt7925: add MT7928 DMA configurationEmery Hsin
Add MT7928 DMA queue layout, DMASHDL configuration, prefetch ring setup, and WFDMA interrupt priority initialization. Select the MT7928-specific layout and GLO_CFG path in mt7925_dma_init(). Signed-off-by: FC Wei <fc.wei@mediatek.com> Signed-off-by: Xiong <xiong.huang@mediatek.com> Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075313.2578154-5-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt7925: add MT7928 irq_map with chip-specific rx masksEmery Hsin
MT7928 uses different RX interrupt bit assignments (RX_DONE_DATA on ENA0, RX_DONE_WM on ENA3). Add MT7928-specific irq_map and select it at probe time based on PCI device ID. Signed-off-by: FC Wei <fc.wei@mediatek.com> Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075313.2578154-4-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt7925: add MT7928 FWDL supportEmery Hsin
Add CBMCU and PHY RAM firmware download flow for MT7928. The CBMCU firmware is loaded in sections before the main WM firmware. Register MT7928 firmware file names and is_mt7928() chip check. Signed-off-by: FC Wei <fc.wei@mediatek.com> Signed-off-by: Xiong <xiong.huang@mediatek.com> Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075313.2578154-3-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt7925: fix MMIO dynamic remap window sizeEmery Hsin
Fix the 0x7c500000 remap entry window size from 0x2000000 (32MB) to 0x200000 (2MB) to match the actual addressable range. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075313.2578154-2-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: connac3: update basic rate table starting indexEmery Hsin
Change MT792x_BASIC_RATES_TBL index from 11 to 14 to match the latest connac3 firmware rate table layout. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075313.2578154-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt792x: add tx_done ring to common DMA queue allocationEmery Hsin
Add a tx_done field to mt792x_dma_layout and extend mt792x_dma_alloc_queues() to allocate the MT_RXQ_MCU_WA queue when tx_done.ring_base is configured. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075136.2577553-5-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt7925: rename WTBL registers to chip-specific formatEmery Hsin
Rename MT_WTBLON_TOP_WDUCR and MT_WTBL_UPDATE to MT7925-prefixed versions since MT7928 uses different WTBL register offsets. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075136.2577553-4-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt792x: rename WFDMA DMASHDL enable bit to follow the conventionEmery Hsin
Rename MT_WFDMA0_CSR_TX_DMASHDL_ENABLE to MT_WFDMA0_GLO_CFG_EXT0_CSR_TX_DMASHDL_EN to follow the register naming convention (parent register name as prefix). This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075136.2577553-3-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt792x: replace shared PCIe MAC macros with per-chip structEmery Hsin
Update mt792x_wpdma_reinit_cond() to use dev->pcie_reg and remove the now unused MT_PCIE_MAC_INT_ENABLE and MT_PCIE_MAC_PM macros from mt792x_regs.h. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075042.2577193-5-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt7925: add per-chip PCIe register definitionsEmery Hsin
Add MT7925_PCIE_MAC_{INT_ENABLE,PM} macros and mt7925_pcie_reg struct. Update all PCIe register accesses in pci.c, pci_mac.c, and pci_mcu.c to use dev->pcie_reg->{imask,pm}. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Xiong <xiong.huang@mediatek.com> Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075136.2577553-2-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: connac2: add per-chip PCIe register definitionsEmery Hsin
Add MT_PCIE_MAC_{INT_ENABLE,PM} definitions to mt7921/regs.h and wire up mt7921_pcie_reg in mt7921_pci_probe() to provide connac2 series chips with their own PCIe register definitions. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Xiong <xiong.huang@mediatek.com> Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075136.2577553-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt792x: add per-chip PCIe register structEmery Hsin
Add a mt792x_pcie_reg struct and a pcie_reg pointer in mt792x_dev, so that each chip can supply its own PCIe register offsets. Users are converted in the following patches. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075042.2577193-5-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt7925: add MT7927 per-chip rx irq definitionsEmery Hsin
Add MT7927_INT_RX_DONE_{DATA,WM,WM2,ALL} macros and populate all_complete_mask in mt7927_irq_map. MT7927 maps RX_DONE_DATA to ENA4 and RX_DONE_WM to ENA6, differing from MT7925. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075042.2577193-4-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt7925: replace shared rx irq masks with per-chip definitionsEmery Hsin
Replace shared MT_INT_RX_DONE_* macros with chip-specific MT7925_INT_RX_DONE_{DATA,WM,WM2,ALL} and populate all_complete_mask in mt7925_irq_map. Update resume and mac_reset paths accordingly. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075042.2577193-3-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: connac2: apply new rx all_complete_maskEmery Hsin
Populate all_complete_mask in MT7921 irq_map and update pci_resume() and mac_reset() to use irq_map->rx.all_complete_mask instead of the hardcoded MT_INT_RX_DONE_ALL macro. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075042.2577193-2-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt792x: consolidate rx interrupt masks into all_complete_maskEmery Hsin
Add all_complete_mask to irq_map rx sub-struct and use it in mt792x_irq_tasklet() and mt792x_dma_enable() to replace individual per-ring mask OR expressions. This is a preparation patch before enabling MT7928 PCIe support. Signed-off-by: Emery Hsin <emery.hsin@mediatek.com> Link: https://patch.msgid.link/20260612075042.2577193-1-jb.tsai@mediatek.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: mt7615: avoid waiting for mac work under the mt76 mutexRunyu Xiao
mt7615_suspend() acquired the mt76 mutex and then called cancel_delayed_work_sync() on mac_work. mt7615_mac_work() acquires the same mutex via mt7615_mutex_acquire() at the top of the worker, so if mac_work is already running and blocked on the mutex, the suspend path deadlocks waiting for the work it holds the mutex against. Flush scan_work and mac_work before taking the mutex, matching the suspend paths in mt7921 and mt7925. scan_work only takes the mt76 spinlock, but moving it keeps the sequence consistent. This also keeps mac_work from running over an already suspended HIF, which the previous split (async cancel under the lock, sync cancel after release) would have allowed. Fixes: c6bf20109a3f ("mt76: mt7615: add WoW support") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Link: https://patch.msgid.link/20260612041331.2596331-1-runyu.xiao@seu.edu.cn Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mt76: connac: add MT7991A (0x7991) to is_mt7996()Dmitry Gomzyakov
The MT7991A chipset uses PCI device ID 0x7991 (MT7996_DEVICE_ID_2), but is_mt7996() only checks for 0x7990. This causes MT7991A devices to use incorrect chip-specific settings, such as: - MSDU_CNT_V2 instead of MSDU_CNT in TX descriptors - Wrong WTBL BMC size (32 instead of 64) - Incorrect prefetch depth for MCU queues Fixes: 7014fe535860 ("wifi: mt76: mt7996: add macros for pci device ids") Signed-off-by: Dmitry Gomzyakov <nicerok11@gmail.com> Link: https://patch.msgid.link/20260510102911.1883849-2-kyoto1337@protonmail.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
2026-07-31wifi: mm81x: prevent timers from outliving teardownLinmao Li
The three timer teardown paths call timer_delete_sync_try() and ignore its return value. If a callback is running on another CPU it returns -1 without waiting, and it does not prevent a later rearm even when it does deactivate a pending timer. mm81x_skbq_tx_complete() can rearm the stale-status timer, and the rc and yaps callbacks queue work that rearms their timers. Teardown can therefore continue with a callback still running or the timer rearmed, so it fires after the associated state has been freed. Use timer_shutdown_sync() for these permanent teardowns: it waits for an in-flight callback and prevents any future rearm. In mm81x_rc_deinit() shut the timer down before cancel_work_sync() so the work can no longer recreate the timer/work cycle. Fixes: b1906cea00b0 ("wifi: mm81x: add mm81x Wi-Fi HaLow driver") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Dan Callaghan <dan.callaghan@morsemicro.com> Link: https://patch.msgid.link/20260723113927.2370301-1-lilinmao@kylinos.cn Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
2026-07-30net/funeth: switch to higher-level allocator APIBrendan Jackman
The difference between __alloc_pages_node() and alloc_pages_node() is that the latter allows you to pass NUMA_NO_NODE. The former is going away and the latter works fine here so switch over. No functional change intended. Link: https://lore.kernel.org/20260703-alloc-trylock-v5-12-c87b714e19d3@google.com Signed-off-by: Brendan Jackman <jackmanb@google.com> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Dimitris Michailidis <dmichail@fungible.com> Cc: Andrew Lunn <andrew+netdev@lunn.ch> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Assisted-by: Gemini:unknown-version Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-07-30net: mctp: usb: Allow multiple urbs in flightJeremy Kerr
Currently, we stop tx queues when we have one urb submitted. This means we will immediately hit dev_hard_start_xmit's tx-queues-off -> NETDEV_TX_BUSY case, and revert to the requeue -> gso_skb single-dequeue path, and no longer be able to pack skbs without an xmit_more indication. Instead, allow a few urbs to be in-flight, with a limit of 16kB of data outstanding (after which we will disable queues). With this, the tx path will cause fewer requeues (and therefore non-packed transfers) under normal loads. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-12-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: enable v1.1 packet spanningJeremy Kerr
Now that mctp-usblib supports DSP0283 v1.1 packet spanning, enable it in our host-side transport driver. Add a match for the new device subclass (0x02), and indicating spanning mode to the usblib rx/tx implementation. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-11-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Add initial kunit testsJeremy Kerr
Add some initial tests for the usblib receive path, where we're extracting MCTP packets from incoming USB transfer data. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-10-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Implement transmit-side packet spanningJeremy Kerr
Add support for packet spanning as defined in DSP0283 v1.1. With the existing v1.0 implementation of multi-packet transfers, all we need here is to adjust the buffer sizes to suit v1.1. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-9-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Implement receive-side packet spanningJeremy Kerr
Using the existing prepare/complete API, we can persist the rx skb across receives to implement v1.1 packet spanning. Alter the packet-extraction loop to allow truncated packets, returning early with the skb persisted for the next IN urb completion. When we see we have a complete packet, netif_rx() that. If the packet boundary aligns with the urb completion, we can netif_rx() the whole thing. Those intermediate packets are cloned from the original (large-transfer-data) skb. Unlike existing behaviour, if the clone fails, we drop just that clone, instead of the existing transfer skb. This allows us to process the rest of the skb data, and any continuation of the span into the next transfer. One subtle change: the mctp_usblib_rx() helper now handles skbs with the full transport header, so we shift the skb_pull() for the header data to the helper, before doing the rx_bytes stats update. We still need to handle non-spanning mode, so error out on truncated-packet cases there. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-8-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Accommodate DSP0283 v1.1 header formatJeremy Kerr
In the v1.1 update to DSP0283, we have a larger header field, of 13 bits rather than 8. In order to accommodate this, in preparation for proper v1.1 support, expand our struct mctp_usb_hdr's len field to a u16, and endian-convert when necessary. Because we don't yet support spanning mode, we will never receive or transmit with the top 5 bits set, so we always mask out anyway. This allows for a future change where we allow spanning mode with >512-byte transfers. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-7-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Add support for multi-packet transmitJeremy Kerr
The MCTP over USB spec allows us to pack multiple packets in one transfer. Given the packet max length is 255, and the transfer max length is 512, we can typically include two full-size packets per urb submission. To do this, we allow a struct mctp_usb_tx to persist a tx_ctx, representing the ongoing context for a transmit. If possible, a TX skb will be queued to the context and the send deferred until the context is full, or the device queue reports no more packets. This typically requires a linear buffer for the 512-byte TX, which we allocate along with the TX context. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-6-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Move TX transfer processing to mctp-usblibJeremy Kerr
With the RX processing in mctp-usblib, add TX processing alongside. To accommodate packed transfers in DSP0283, where a transfer may contain multiple MCTP packets, we move to a split process for the transmit API: * push: create a new transmit context, and add a skb to it. * send: callback to the driver implementation to send the (possibly multi-packet) USB transfer * complete: update skb accounting and release the tx context The actual multi-packet transfer implementation will be added in the next change; no tx context persists beyond the single send at present. However, we use an anchor in the host driver implementation to track the submitted TX urb when necessary. While we're here, fix an inconsistency between tx and rx stats: both should not include the transport header. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-5-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Improve IN endpoint status handlingJeremy Kerr
Currently, we give-up on all non-zero status values on our IN/rx urb, and do not re-queue the urb. This will stall the driver, and prevent any further receive. Instead, attempt a re-queue on transient errors, with a max of ten successive failures. Handle EPIPE specially, by scheduling a usb_clear_halt() in non-atomic context. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-4-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usblib: Move RX transfer processing to a new mctp-usblibJeremy Kerr
The processing of USB receive transfers is common to both sides of a MCTP over USB transport. In order to support a future gadget driver, move the current host-side driver into a new common file, mctp-usblib. This currently handles the submit-complete-packetise process of the receive path of the USB transport. We'll add transmit handling in an upcoming change. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-3-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Use packet-length max for maximum packet-size checkJeremy Kerr
The max packet size is smaller than the max transfer size, as we only have a u8 length field in the transport header. Add a define for the maximum representable length, and use that for our check. Use this for the MTU maximum calculation too. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-2-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: mctp: usb: Include version indicator in max packet size definesJeremy Kerr
DSP0283 v1.1.0 will introduce larger maximum packet sizes. In preparation, indicate that the current maxima are specific to v1.0.x. Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260724-dev-mctp-usb-1-1-v5-1-e66bbba0dbdc@codeconstruct.com.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30pds_core: cancel pending PCI reset work on AER recoveryNikhil P. Rao
pdsc_check_pci_health() queues pci_reset_work when it sees a broken PCI connection, and nothing cancels it. When the PCI core starts AER recovery, pdsc_pci_error_detected() runs pdsc_reset_prepare() and recovers the device, but a pci_reset_work queued just before is left pending. If it runs after recovery released the device lock, it resets a device the driver now considers healthy, bouncing the link for no reason. Cancel pci_reset_work in pdsc_pci_error_detected() after pdsc_reset_prepare(), which has already stopped the health thread so it cannot requeue the work. cancel_work_sync() is safe under the device lock here because pdsc_pci_reset_thread() uses pci_try_reset_function(), which returns instead of blocking on the lock. Only PFs initialize pci_reset_work, so guard the cancel with !is_virtfn. Fixes: 81665adf25d2 ("pds_core: Fix pdsc_check_pci_health function to use work thread") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260714180223.1642792-2-nikhil.rao%40amd.com?part=1 Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260727170030.361116-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30pds_core: keep the health thread stopped during resetNikhil P. Rao
Commit d9407ff11809 ("pds_core: Prevent health thread from running during reset/remove") stops the health thread with cancel_work_sync() before a reset, but a devcmd timeout during pdsc_fw_down() re-queues health_work, so pdsc_health_thread() runs again mid-reset and double allocates the core DMA queues via pdsc_fw_up(). Only the reset path is affected: on remove PDSC_S_STOPPING_DRIVER gates the health thread and the workqueue is destroyed. Use disable_work_sync() to cancel health_work and block further queue_work() on it, and enable_work() in pdsc_restart_health_thread() to re-allow it after the reset. disable_work_sync() keeps a disable depth, so every disable must be matched by one enable. pdsc_reset_prepare() stops the health thread and pdsc_reset_done() restarts it. On the AER path pdsc_pci_error_detected() calls pdsc_reset_prepare(), then pdsc_pci_error_resume() re-inits via pci_reset_function_locked() (pds_core has no .slot_reset handler), which runs the pair again - stopping the thread twice but restarting it once. Gate the disable and enable on a health_stopped flag so each fires at most once per stopped/running transition. Fixes: d9407ff11809 ("pds_core: Prevent health thread from running during reset/remove") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2 Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260727164548.359562-1-nikhil.rao@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net/mlx5e: TC, Check if flow is PEER before acquiring devcom lockShay Drory
In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring ESW devcom lock without condition. In addition, in case of peer_flow, __mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock. This results in an AA deadlock. To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5e_tc_del_flow() before acquiring ESW devcom lock. Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================ Possible unsafe locking scenario: CPU0 ---- lock(&comp->lock_key#2); lock(&comp->lock_key#2); *** DEADLOCK *** Call Trace: <TASK> dump_stack_lvl+0x69/0xa0 print_deadlock_bug.cold+0xbd/0xca __lock_acquire+0x1671/0x2ec0 lock_acquire+0x10e/0x2e0 down_read+0x95/0x430 mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core] mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core] mlx5e_flow_put+0x99/0x100 [mlx5_core] __mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core] mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core] mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core] mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core] tc_setup_cb_add+0x1dc/0x470 fl_change+0x2f4d/0x626d [cls_flower] tc_new_tfilter+0x79b/0x2310 rtnetlink_rcv_msg+0x778/0xad0 do_syscall_64+0x70/0x960 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Fixes: 04de7dda7394 ("net/mlx5e: Infrastructure for duplicated offloading of TC flows") Signed-off-by: Shay Drory <shayd@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260728044338.2271143-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30enic: fix tx_hang_reset use-after-free on device removalSatish Kharat
enic_remove() cancels the reset and change_mtu_work items but does not cancel tx_hang_reset. A TX timeout that fires while the device is being removed can schedule enic_tx_hang_reset() so that it runs after free_netdev(), resulting in a use-after-free. cancel_work_sync() alone is not sufficient here: the still-live watchdog and notify paths can re-schedule these work items in the window between the cancel and unregister_netdev(). Use disable_work_sync(), which cancels the work and blocks any subsequent schedule_work() from requeuing it, and apply it to the reset and change_mtu_work items as well so the same requeue race is closed for all teardown work. Fixes: 937317c7c109 ("enic: do hang reset only in case of tx timeout") Signed-off-by: Satish Kharat <satishkh@cisco.com> Link: https://patch.msgid.link/20260728062730.2394873-1-satishkh@cisco.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30bonding: alb: re-check primary_is_promisc under RTNL in bond_alb_monitorXiang Mei (Microsoft)
bond_alb_monitor() reads primary_is_promisc under RCU, then drops RCU and takes RTNL via rtnl_trylock() before undoing the promiscuity it set on the active slave. In that window the active slave can change under RTNL (RTM_DELLINK -> __bond_release_one() -> bond_alb_handle_active_change()), which already drops the promiscuity and clears primary_is_promisc. The monitor still acts on the stale decision: if the slave was removed with no failover, curr_active_slave is now NULL and the deref faults; if it failed over, the stale dev_set_promiscuity(-1) underflows the new slave's promiscuity counter and pins it in IFF_PROMISC. Oops: general protection fault, probably for non-canonical address ... KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: b42 bond_alb_monitor RIP: 0010:bond_alb_monitor (drivers/net/bonding/bond_alb.c:1600) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) Kernel panic - not syncing: Fatal exception Re-check primary_is_promisc (and curr_active_slave) after taking RTNL so the monitor only undoes an increment it still owns. The other bonding monitors already re-read state under RTNL in their commit phase (bond_miimon_commit/bond_ab_arp_commit); bond_alb_monitor() was the only one acting on the pre-trylock decision. Fixes: d0e81b7e2246 ("bonding: Acquire correct locks in alb for promisc change") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Acked-by: Jay Vosburgh <jv@jvosburgh.net> Link: https://patch.msgid.link/20260725233930.2957317-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30wanxl: Remove pci_map_single_debug()Bence Csokas
Since commit 24dd377a76b0 ("wan: wanxl: switch from 'pci_' to 'dma_' API") this has been dead code anyways. The pci_map_single() function it attempts to redefine has been removed in commit 7968778914e5 ("PCI: Remove the deprecated "pci-dma-compat.h" API"). Reviewed-by: Simon Horman <horms@kernel.org> Link: https://lore.kernel.org/all/20260709151401.GO1364329@horms.kernel.org Signed-off-by: Bence Csokas <bence.csokas@arm.com> Link: https://patch.msgid.link/20260727-wanxl-cleanup-v2-1-3826430829c9@arm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30Revert "net: thunderbolt: Enable end-to-end flow control also in transmit"Fan Ye
This reverts commit a8065af3346ebd7c76ebc113451fb3ba94cf7769. Per the USB4 spec, a Transmit Descriptor Ring with E2E flow control disabled does not require any credits to be available before the Host Interface Adapter Layer transmits a tunneled packet from it. Once E2E is enabled on that ring the controller must first obtain end-to-end credits. The ASMedia ASM4242 USB4 host router (PCI 1b21:2425) never delivers those credits. The controller does accept the configuration: reading the ring OPTIONS register back right after tb_ring_start() returns exactly what was written, including RING_FLAG_E2E_FLOW_CONTROL (bit 28) and the E2E HopID field. No credit ever arrives though, so the Tx ring's hardware consumer index never advances and the link carries no traffic at all. Measured on two hosts connected point to point, onboard ASM4242 on MSI X870E and X870, v6.17, stock drivers/net/thunderbolt/main.c with only this revert applied on top: before: 100% packet loss to the peer; thunderbolt0 is up and the XDomain handshake completes ("new host found"), but iperf3 fails with "No route to host" once the neighbour entry expires after: 0% packet loss, 0.28 ms RTT; iperf3 4.21 Gb/s one way and 5.17 Gb/s the other (5 runs each, stddev <= 0.02), 1 retransmit in 10 s An instrumented build additionally showed a frozen-Tx-consumer watchdog firing ~30k times in a 10 s window before this change. Rx-side E2E is not touched by this revert, so peers that do return credits keep receive-side flow control. ASMedia does not look like an isolated case. The out-of-tree thunderbolt-ibverbs project disables native E2E on AMD NHI by default, noting that "Strix Halo has reproduced TX completion wedges with multiple native E2E rings active" -- the same failure mode, on a different vendor. Since the driver has no way to tell in advance which host router returns the credits, going back to the previous behaviour looks safer than adding a quirk per affected part; Tx-side E2E can be reintroduced as an opt-in for controllers that are known to implement the credit return. Note that the reverted commit was not fixing a reported problem, it was derived from the spec wording alone, so this revert is not expected to regress a known workload. Cc'ing the original author in case there was one. Fixes: a8065af3346e ("net: thunderbolt: Enable end-to-end flow control also in transmit") Cc: zhangjianrong <zhangjianrong5@huawei.com> Signed-off-by: Fan Ye <fy15309206903@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://patch.msgid.link/20260727123002.25225-1-fy15309206903@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30net: hns3: fix speed configuration residue after driver reloadJijie Shao
After setting a 100G optical port to 40G via ethtool and reloading the driver, the port remains at 40G instead of reverting to the firmware default speed of 100G. The commit referenced in Fixes: added two overwrites in hclge_init_ae_dev() for non-copper media, so that optical ports connected to forced-mode remotes inherit the firmware-preset autoneg and speed instead of the hardcoded defaults: req_autoneg = mac.autoneg req_speed = mac.speed (when autoneg disabled) The autoneg overwrite keeps existing behavior: hclge_set_autoneg_speed_dup() already uses mac.autoneg (not req_autoneg) since it was introduced, so autoneg inheritance from firmware was already in place. This part is kept. The speed overwrite, however, introduces the residue: mac.speed reflects whatever was last programmed into the MAC, and after unload firmware does not restore the MAC speed to the flash default. So if the user changed speed via ethtool in a prior load, mac.speed still carries that value on reload and req_speed inherits it. Fix by dropping the req_speed overwrite only. req_speed keeps the firmware default value set in hclge_configure() (cfg.default_speed), so a reload reverts the speed to default, matching the expectation that a driver reload resets link configuration. Trade-off: on optical ports whose firmware default speed does not match a forced-mode remote, reload now drops the link and the user must re-apply ethtool configuration. This is acceptable: a driver reload is expected to reset link configuration, not to inherit runtime state from before unload. The autoneg inheritance is left in place as established behavior; changing it is out of scope for this patch and would itself be a user-perceivable behavior change. Fixes: d9d349c4e8a0 ("net: hns3: differentiate autoneg default values between copper and fiber") Signed-off-by: Jijie Shao <shaojijie@huawei.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260724093036.426631-1-shaojijie@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.2-rc6). No conflicts. Adjacent changes: net/ipv4/route.c dbc3791e3b24 ("net: do not send ICMP/NDISC Redirects when peer allocation fails") 7804eaa057fe ("ipv4: snapshot dst.dev in ip_rt_send_redirect() and ip_rt_get_source()") drivers/net/tun.c 23dad2d088df ("tun: no longer rely on RTNL in tun_fill_info()") c3da92af07ea ("Revert "tun/tap: add ptr_ring consume helper with netdev queue wakeup"") drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c 3bd438a58e91 ("octeontx2-af: Block VFs from clobbering special CGX PKIND state") 5ba5611ef946 ("octeontx2-af: reserve 4 PKINDs for skip-size custom use") drivers/net/wireless/ath/ath12k/core.h drivers/net/wireless/ath/ath12k/mac.c drivers/net/wireless/ath/ath12k/peer.c 469d7e6077c1 ("wifi: ath12k: resolve PENDING ML peer ID from MLO_PEER_MAP HTT event") 378e659029d5 ("wifi: ath12k: introduce host_alloc_ml_id hardware parameter") c42b27336eef ("wifi: ath12k: fix survey indexing across bands") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-30wifi: ath6kl: return 0 explicitly in ath6kl_init_upload()Sang-Heon Jeon
status is always zero at the last return in ath6kl_init_upload(). Explicitly return 0 on the success path instead of returning status. No functional change. Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Link: https://patch.msgid.link/20260729160458.201962-1-ekffu200098@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-30wifi: ath11k: fix stride mismatch in mac_phy_caps_parse()Jeff Johnson
Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Compile tested only. Fixes: 5b90fc760db5 ("ath11k: fix wmi service ready ext tlv parsing") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260728-mac_phy_caps_parse-stride-mismatch-v1-2-27a9c1a3fbd0@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-30wifi: ath12k: fix stride mismatch in mac_phy_caps_parse()Jeff Johnson
Currently, in ath12k_wmi_mac_phy_caps_parse(), kzalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct ath12k_wmi_mac_phy_caps_params)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation. The reader in ath12k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride. Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Assisted-by: Claude:claude-sonnet-4-6 Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com> Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Link: https://patch.msgid.link/20260728-mac_phy_caps_parse-stride-mismatch-v1-1-27a9c1a3fbd0@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2026-07-30qede: sync udp_tunnel ports outside qede_lock in the recovery pathDenis V. Lunev
A TX timeout on a qede NIC that has VXLAN/GENEVE tunnel ports configured wedges the rtnetlink control plane of the whole machine: NETDEV WATCHDOG: ens6f1 (qede): transmit queue 2 timed out 10226 ms [qede_tx_timeout:586(ens6f1)]TX timeout on queue 2! [qede_recovery_handler:2665(ens6f0)]Starting a recovery process The recovery path deadlocks on the driver's own mutex: qede_sp_task rtnl_lock() mutex_lock(&edev->qede_lock) <- taken qede_recovery_handler qede_load udp_tunnel_nic_reset_ntf __udp_tunnel_nic_device_sync info->sync_table == qede_udp_tunnel_sync mutex_lock(&edev->qede_lock) <- same task: deadlock The mutex is not recursive, so the kworker blocks on itself with rtnl_lock held, and neither lock is ever released. Every task that calls rtnl_lock() afterwards (ip, ovs-vswitchd, lldpad, IPv6 addrconf, sshd) blocks forever while the node still answers ping. In a vmcore from an affected production node rtnl_mutex.owner decodes to the very kworker blocked at the innermost mutex_lock() above. Re-sync the tunnel ports from qede_sp_task() after the internal lock is dropped, still under rtnl_lock as the udp_tunnel API requires. This mirrors qede_open(), which calls udp_tunnel_nic_reset_ntf() under rtnl without the internal lock. qede_recovery_handler() now returns whether it has successfully reloaded an open device, and the caller re-syncs the ports only in that case. This keeps the old gating exactly: a device that was down or a failed recovery returns false, as those paths never reached the udp_tunnel_nic_reset_ntf() call before either. This was the only user of the qede_lock()/qede_unlock() helpers, so remove them. Fixes: 8cd160a29415 ("qede: convert to new udp_tunnel_nic infra") Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Andrew Lunn <andrew+netdev@lunn.ch> CC: "David S. Miller" <davem@davemloft.net> CC: Eric Dumazet <edumazet@google.com> CC: Jakub Kicinski <kuba@kernel.org> CC: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20260726104311.1782900-1-den@openvz.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-30Merge tag 'linux-can-fixes-for-7.2-20260729' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2026-07-29 this is a pull request of 20 patches for net/main. The first 2 patches fix problems in the CAN J1939 protocol and are by Tetsuo Handa and Oleksij Rempel. The next 2 patches fix problems in the CAN ISOTP protocol and are by Oliver Hartkopp and Minhong He. Avi Weiss contributes contributed 4 fixes for the ctucanfd, Pengpeng Hou's patch adds a missing MODULE_DEVICE_TABLE. The patches for the peak_usb driver are contributed by James Gao, Maoyi Xie, Maoyi Xie and add sanity checks for the USB bulk data parsing and fix a double free. 2 fixes for the kvaser_usb driver are provided by Abdun Nihaal and Pengpeng Hou, a mem leak is fixed and sanity checks for the USB bulk data parsing. Tu Nguyen's patch for the rcar_canfd driver fixes the initializing flow. Pengpeng Hou contributes a patch for the softing driver to validate the firmware record spans. Lucas Martins Alves's patch for the c_can driver keeps the controller in init mode until configuration is complete. A patch by my add missing URB resubmission on skb allocation failure to the gs_usb driver. Guangshuo Li's patch for the etas_es58x driver fixes a RX buffer leak. The last patch is by Pengpeng Hou and adds sanity checks to the USB bulk data parsing of the ems_usb driver. linux-can-fixes-for-7.2-20260729 * tag 'linux-can-fixes-for-7.2-20260729' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: ems_usb: validate CPC message lengths can: etas_es58x: es58x_read_bulk_callback(): fix RX buffer leak on URB resubmit failure can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb allocation failure can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured can: softing: fw_parse(): validate firmware record spans can: rcar_canfd: change the initializing flow for clocks and resets can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in kvaser_usb_hydra_get_busparams() can: peak_usb: validate uCAN receive record lengths can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error can: peak_usb: add bounds check for USB channel index can: ctucanfd: add missing MODULE_DEVICE_TABLE() can: ctucanfd: use self-test mode for PRESUME_ACK can: ctucanfd: handle bus error interrupts can: ctucanfd: mark error-active controller status valid can: ctucanfd: unmap BAR0 using base address can: isotp: check register_netdevice_notifier() error in module init can: isotp: fix timer drain order, wakeup handling and tx_gen ordering can: j1939: transport: j1939_session_fresh_new(): initialize receive buffer can: j1939: use netdevice_tracker for j1939_{priv,session,ecu} tracking ==================== Link: https://patch.msgid.link/20260729102802.505168-1-mkl@pengutronix.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-30net: phy: micrel: Add loopback support for ksz9131Maxime Chevallier
ksz9131 is configured for local loopback in a similar fashion as the ksz9031, with a need for full-duplex operation, but with some extra steps to take as specified in section 4.13.1 : 1. Configure the following registers: - MMD 1C, Register 15 = EEEE - MMD 1C, Register 16 = EEEE - MMD 1C, Register 18 = EEEE - MMD 1C, Register 1B = EEEE These 4 registers are marked as "Reserved" in the register map. When setting loopback up without configuring these 4 registers, the PHY appears to shut its RXC down, which can trigger failures on MACs that require it, such as stmmac. The datasheet does not specify to which state the registers must be reset when disabling loopback, so let's restore them to their measured initial values. This was discovered when trying to use stmmac selftests on imx8mp with a ksz9131 connected in RGMII. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260728075222.956780-1-maxime.chevallier@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-30net: intel: remove conditional return with no effectSang-Heon Jeon
Both branches of the check return the same value, so the check has no effect. Remove it and return the value directly. This is the result of running the Coccinelle script from scripts/coccinelle/misc/cond_return_no_effect.cocci. Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com> Link: https://patch.msgid.link/20260725150852.859188-5-ekffu200098@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-30net: remove conditional return with no effectSang-Heon Jeon
Both branches of the check return the same value, so the check has no effect. Remove it and return the value directly. This is the result of running the Coccinelle script from scripts/coccinelle/misc/cond_return_no_effect.cocci. Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260725150852.859188-4-ekffu200098@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-19 12:06:22 +0000