summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2025-04-15net: dsa: mt7530: generalize read port stats logicChristian Marangi
In preparation for migration to use of standard MIB API, generalize the read port stats logic to a dedicated function. This will permit to manually provide the offset and size of the MIB counter to directly access specific counter. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://patch.msgid.link/20250410163022.3695-2-ansuelsmth@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-15eth: fbnic: add support for TTI HW statsMohsin Bashir
Add coverage for the TX Extension (TEI) Interface (TTI) stats. We are tracking packets and control message drops because of credit exhaustion on the TX interface. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250410070859.4160768-6-mohsin.bashr@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-15eth: fbnic: add support for TMI statsMohsin Bashir
This patch add coverage for TMI stats including PTP stats and drop stats. PTP stats include illegal requests, bad timestamp and good timestamps. The bad timestamp and illegal request counters are reported under as `error` via `ethtool -T` Both these counters are individually being reported via `ethtool -S` The good timestamp stats are being reported as `pkts` via `ethtool -T` ethtool -S eth0 | grep "ptp" ptp_illegal_req: 0 ptp_good_ts: 0 ptp_bad_ts: 0 Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250410070859.4160768-5-mohsin.bashr@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-15eth: fbnic: add coverage for RXB statsMohsin Bashir
This patch provides coverage to the RXB (RX Buffer) stats. RXB stats are divided into 3 sections: RXB enqueue, RXB FIFO, and RXB dequeue stats. The RXB enqueue/dequeue stats are indexed from 0-3 and cater for the input/output counters whereas, the RXB fifo stats are indexed from 0-7. The RXB also supports pause frame stats counters which we are leaving for a later patch. ethtool -S eth0 | grep rxb rxb_integrity_err0: 0 rxb_mac_err0: 0 rxb_parser_err0: 0 rxb_frm_err0: 0 rxb_drbo0_frames: 1433543 rxb_drbo0_bytes: 775949081 --- --- rxb_intf3_frames: 1195711 rxb_intf3_bytes: 739650210 rxb_pbuf3_frames: 1195711 rxb_pbuf3_bytes: 765948092 Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250410070859.4160768-4-mohsin.bashr@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-15eth: fbnic: add coverage for hw queue statsMohsin Bashir
This patch provides support for hardware queue stats and covers packet errors for RX-DMA engine, RCQ drops and BDQ drops. The packet errors are also aggregated with the `rx_errors` stats in the `rtnl_link_stats` as well as with the `hw_drops` in the queue API. The RCQ and BDQ drops are aggregated with `rx_over_errors` in the `rtnl_link_stats` as well as with the `hw_drop_overruns` in the queue API. ethtool -S eth0 | grep -E 'rde' rde_0_pkt_err: 0 rde_0_pkt_cq_drop: 0 rde_0_pkt_bdq_drop: 0 --- --- rde_127_pkt_err: 0 rde_127_pkt_cq_drop: 0 rde_127_pkt_bdq_drop: 0 Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250410070859.4160768-3-mohsin.bashr@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-15eth: fbnic: add locking support for hw statsMohsin Bashir
This patch adds lock protection for the hardware statistics for fbnic. The hardware statistics access via ndo_get_stats64 is not protected by the rtnl_lock(). Since these stats can be accessed from different places in the code such as service task, ethtool, Q-API, and net_device_ops, a lock-less approach can lead to races. Note that this patch is not a fix rather, just a prep for the subsequent changes in this series. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250410070859.4160768-2-mohsin.bashr@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-15net: mdio: Add RTL9300 MDIO driverChris Packham
Add a driver for the MDIO controller on the RTL9300 family of Ethernet switches with integrated SoC. There are 4 physical SMI interfaces on the RTL9300 however access is done using the switch ports. The driver takes the MDIO bus hierarchy from the DTS and uses this to configure the switch ports so they are associated with the correct PHY. This mapping is also used when dealing with software requests from phylib. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250409231554.3943115-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-15net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry readsJonathan Currier
Fix niu_try_msix() to not cause a fatal trap on sparc systems. Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to work around a bug in the hardware or firmware. For each vector entry in the msix table, niu chips will cause a fatal trap if any registers in that entry are read before that entries' ENTRY_DATA register is written to. Testing indicates writes to other registers are not sufficient to prevent the fatal trap, however the value does not appear to matter. This only needs to happen once after power up, so simply rebooting into a kernel lacking this fix will NOT cause the trap. NON-RESUMABLE ERROR: Reporting on cpu 64 NON-RESUMABLE ERROR: TPC [0x00000000005f6900] <msix_prepare_msi_desc+0x90/0xa0> NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff NON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000] NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff] NON-RESUMABLE ERROR: type [precise nonresumable] NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv > NON-RESUMABLE ERROR: raddr [0xffffffffffffffff] NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c] NON-RESUMABLE ERROR: size [0x8] NON-RESUMABLE ERROR: asi [0x00] CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63 Workqueue: events work_for_cpu_fn TSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not tainted TPC: <msix_prepare_msi_desc+0x90/0xa0> g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100 g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000 o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620 o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128 RPC: <__pci_enable_msix_range+0x3cc/0x460> l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020 l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734 i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d i4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0 I7: <niu_try_msix.constprop.0+0xc0/0x130 [niu]> Call Trace: [<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu] [<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu] [<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu] [<00000000005ef3e4>] local_pci_probe+0x28/0x74 [<0000000000469240>] work_for_cpu_fn+0x8/0x1c [<000000000046b008>] process_scheduled_works+0x144/0x210 [<000000000046b518>] worker_thread+0x13c/0x1c0 [<00000000004710e0>] kthread+0xb8/0xc8 [<00000000004060c8>] ret_from_fork+0x1c/0x2c [<0000000000000000>] 0x0 Kernel panic - not syncing: Non-resumable error. Fixes: 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") Signed-off-by: Jonathan Currier <dullfire@yahoo.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20241117234843.19236-3-dullfire@yahoo.com
2025-04-14net: stmmac: qcom-ethqos: remove speed_mode_2500() methodRussell King (Oracle)
qcom-ethqos doesn't need to implement the speed_mode_2500() method as it is only setting priv->plat->phy_interface to 2500BASE-X, which is already a pre-condition for assigning speed_mode_2500 in qcom_ethqos_probe(). So, qcom_ethqos_speed_mode_2500() has no effect. Remove it. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1u3bYa-000EcW-H1@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net: stmmac: qcom-ethqos: remove unnecessary setting max_speedRussell King (Oracle)
Phylink will already limit the MAC speed according to the interface, so if 2500BASE-X is selected, the maximum speed will be 2.5G. It is, therefore, not necessary to set a speed limit. Remove setting plat_dat->max_speed from this glue driver. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1u3bYV-000EcQ-Cv@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net: stmmac: qcom-ethqos: remove ethqos->speedRussell King (Oracle)
Rather than ethqos_fix_mac_speed() storing the speed in struct qcom_ethqos and then functions that are only called from here reading that speed, pass the speed to the called functions instead. This removes all readers of this struct member, which then allows the removal of the two places that set its value and the struct member. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1u3bYQ-000EcK-9K@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net: stmmac: qcom-ethqos: set serdes speed using serdes_speedRussell King (Oracle)
ethqos->serdes_speed represents the current speed the serdes was configured for, which should be the same as ethqos->speed. Since we wish to remove ethqos->speed to simplify the code, switch to using the serdes_speed instead. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/E1u3bYL-000EcE-5c@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Export action STE tables to debugfsVlad Dogaru
Introduce a new type of dump object and dump all action STE tables, along with information on their RTCs and STEs. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Hamdan Agbariya <hamdani@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-13-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Free unused action STE tablesVlad Dogaru
Periodically check for unused action STE tables and free their associated resources. In order to do this safely, add a per-queue lock to synchronize the garbage collect work with regular operations on steering rules. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-12-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Cleanup matcher action STE tableVlad Dogaru
Remove the matcher action STE implementation now that the code uses per-queue action STE pools. This also allows simplifying matcher code because it is now only handling a single type of RTC/STE. The matcher resize data is also going away. Matchers were saving old action STE data because the rules still used it, but now that data lives in the action STE pool and is no longer coupled to a matcher. Furthermore, matchers no longer need to rehash a due to action template addition. If a new action template needs more action STEs, we simply update the matcher's num_of_action_stes and future rules will allocate the correct number. Existing rules are unaffected by such an operation and can continue to use their existing action STEs. The range action was using the matcher action STE implementation, but there was no reason to do this other than the container fitting the purpose. Extract that information to a separate structure. Finally, stop dumping per-matcher information about action RTCs, because they no longer exist. A later patch in this series will add support for dumping action STE pools. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-11-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Use the new action STE poolVlad Dogaru
Use the central action STE pool when creating / updating rules. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-10-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Implement action STE poolVlad Dogaru
Implement a per-queue pool of action STEs that match STEs can link to, regardless of matcher. The code relies on hints to optimize whether a given rule is added to rx-only, tx-only or both. Correspondingly, action STEs need to be added to different RTC for ingress or egress paths. For rx-and-tx rules, the current rule implementation dictates that the offsets for a given rule must be the same in both RTCs. To avoid wasting STEs, each action STE pool element holds 3 pools: rx-only, tx-only, and rx-and-tx, corresponding to the possible values of the pool optimization enum. The implementation then chooses at rule creation / update which of these elements to allocate from. Each element holds multiple action STE tables, which wrap an RTC, an STE range, the logic to buddy-allocate offsets from the range, and an STC that allows match STEs to point to this table. When allocating offsets from an element, we iterate through available action STE tables and, if needed, create a new table. Similar to the previous implementation, this iteration does not free any resources. This is implemented in a subsequent patch. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-9-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Fix pool size optimizationVlad Dogaru
The optimization to create a size-one STE range for the unused direction was broken. The hardware prevents us from creating RTCs over unallocated STE space, so the only reason this has worked so far is because the optimization was never used. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-8-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Add fullness tracking to poolVlad Dogaru
Future users will need to query whether a pool is empty. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-7-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Cleanup after pool refactoringVlad Dogaru
Remove members which are now no longer used. In fact, many of the `struct mlx5hws_pool_chunk` were not even written to beyond being initialized, but they were used in various internals. Also cleanup some local variables which made more sense when the API was thicker. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-6-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Refactor pool implementationVlad Dogaru
Refactor the pool implementation to remove unused flags and clarify its usage. A pool represents a single range of STEs or STCs which are allocated at pool creation time. Pools are used under three patterns: 1. STCs are allocated one at a time from a global pool using a bitmap based implementation. 2. Action STEs are allocated in power-of-two blocks using a buddy algorithm. 3. Match STEs do not use allocation, since insertion into these tables is based on hashes or direct addressing. In such cases we use a pool only to create the STE range. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Make pool single resourceVlad Dogaru
The pool implementation claimed to support multiple resources, but this does not really make sense in context. Callers always allocate a single STC or STE chunk of exactly the size provided. The code that handled multiple resources was unused (and likely buggy) due to the combination of flags passed by callers. Simplify the pool by having it handle a single resource. As a result of this simplification, chunks no longer contain a resource offset (there is now only one resource per pool), and the get_base_id functions no longer take a chunk parameter. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Remove unused element arrayVlad Dogaru
Remove the array of elements wrapped in a struct because in reality only the first element was ever used. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net/mlx5: HWS, Fix matcher action template attachVlad Dogaru
The procedure of attaching an action template to an existing matcher had a few issues: 1. Attaching accidentally overran the `at` array in bwc_matcher, which would result in memory corruption. This bug wasn't triggered, but it is possible to trigger it by attaching action templates beyond the initial buffer size of 8. Fix this by converting to a dynamically sized buffer and reallocating if needed. 2. Similarly, the `at` array inside the native matcher was never reallocated. Fix this the same as above. 3. The bwc layer treated any error in action template attach as a signal that the matcher should be rehashed to account for a larger number of action STEs. In reality, there are other unrelated errors that can arise and they should be propagated upstack. Fix this by adding a `need_rehash` output parameter that's orthogonal to error codes. Fixes: 2111bb970c78 ("net/mlx5: HWS, added backward-compatible API handling") Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Link: https://patch.msgid.link/1744312662-356571-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net: dsa: microchip: add ETS scheduler support for KSZ88x3 switchesOleksij Rempel
Implement Enhanced Transmission Selection scheduler (ETS) support for KSZ88x3 devices, which support two fixed egress scheduling modes: Strict Priority and Weighted Fair Queuing (WFQ). Since the switch does not allow remapping priorities to queues or adjusting weights, this implementation only supports enabling strict priority mode. If strict mode is not explicitly requested, the switch falls back to its default WFQ mode. This patch introduces KSZ88x3-specific handlers for ETS add and delete operations and uses TXQ Split Control registers to toggle the WFQ enable bit per queue. Corresponding macros are also added for register access. Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20250410124249.2728568-1-o.rempel@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net: stmmac: remove GMAC_1US_TIC_COUNTER definitionRussell King (Oracle)
GMAC_1US_TIC_COUNTER is now no longer used, so remove the definition. This was duplicated by GMAC4_MAC_ONEUS_TIC_COUNTER further down in the same file. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1u3Vv0-000E87-DQ@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net: stmmac: intel-plat: remove eee_usecs_rate and hardware writeRussell King (Oracle)
Remove the write to GMAC_1US_TIC_COUNTER for two reasons: 1. during initialisation or reinitialisation of the DWMAC core, the core is reset, which sets this register back to its default value. Writing it prior to stmmac_dvr_probe() has no effect. 2. Since commit 8efbdbfa9938 ("net: stmmac: Initialize MAC_ONEUS_TIC_COUNTER register"), GMAC4/5 core code will set this register based on the rate of plat->stmmac_clk. This clock is fetched by devm_stmmac_probe_config_dt(), and plat->clk_ptp_rate will be set to its rate profided a "ptp_ref" clock is not provided. In any case, Marek's commit will set the effectual value of this register. Therefore, dwmac-intel-plat.c writing GMAC_1US_TIC_COUNTER serves no useful purpose and can be removed. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1u3Vuq-000E7s-5Y@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net: stmmac: intel: remove eee_usecs_rate and hardware writeRussell King (Oracle)
Remove the write to GMAC_1US_TIC_COUNTER for two reasons: 1. during initialisation or reinitialisation of the DWMAC core, the core is reset, which sets this register back to its default value. Writing it prior to stmmac_dvr_probe() has no effect. 2. Since commit 8efbdbfa9938 ("net: stmmac: Initialize MAC_ONEUS_TIC_COUNTER register"), GMAC4/5 core code will set this register based on the rate of plat->stmmac_clk. This clock is created by the same code which initialises plat->eee_usecs_rate, which is also created to run at this same rate. Since Marek's commit, this will set this register appropriately using the rate of this clock. Therefore, dwmac-intel.c writing GMAC_1US_TIC_COUNTER serves no useful purpose and can be removed. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1u3Vul-000E7m-1j@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14net: stmmac: dwc-qos: remove tegra_eqos_init()Russell King (Oracle)
tegra_eqos_init() initialises the 1US TIC counter for the EEE timers. However, the DWGMAC core is reset after this write, which clears this register to its default. However, dwmac4_core_init() configures this register using the same clock, which happens after reset - thus this is the write which ensures that the register is correctly configured. Therefore, tegra_eqos_init() is not required and is removed. This also means eqos->clk_slave can also be removed. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1u3Vuf-000E7g-U4@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14geneve: Convert geneve_exit_batch_rtnl() to ->exit_rtnl().Kuniyuki Iwashima
geneve_exit_batch_rtnl() iterates the dying netns list and performs the same operation for each. Let's use ->exit_rtnl(). Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20250411205258.63164-14-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14bareudp: Convert bareudp_exit_batch_rtnl() to ->exit_rtnl().Kuniyuki Iwashima
bareudp_exit_batch_rtnl() iterates the dying netns list and performs the same operation for each. Let's use ->exit_rtnl(). While at it, we replace unregister_netdevice_queue() with bareudp_dellink() for better cleanup. It unlinks the device from net_generic(net, bareudp_net_id)->bareudp_list, but there is no real issue as both the dev and the list are freed later. Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20250411205258.63164-13-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14gtp: Convert gtp_net_exit_batch_rtnl() to ->exit_rtnl().Kuniyuki Iwashima
gtp_net_exit_batch_rtnl() iterates the dying netns list and performs the same operations for each. Let's use ->exit_rtnl(). Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20250411205258.63164-12-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14bonding: Convert bond_net_exit_batch_rtnl() to ->exit_rtnl().Kuniyuki Iwashima
bond_net_exit_batch_rtnl() iterates the dying netns list and performs the same operation for each. Let's use ->exit_rtnl(). Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20250411205258.63164-11-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14vxlan: Convert vxlan_exit_batch_rtnl() to ->exit_rtnl().Kuniyuki Iwashima
vxlan_exit_batch_rtnl() iterates the dying netns list and performs the same operations for each. Let's use ->exit_rtnl(). Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://patch.msgid.link/20250411205258.63164-6-kuniyu@amazon.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14page_pool: Move pp_magic check into helper functionsToke Høiland-Jørgensen
Since we are about to stash some more information into the pp_magic field, let's move the magic signature checks into a pair of helper functions so it can be changed in one place. Reviewed-by: Mina Almasry <almasrymina@google.com> Tested-by: Yonglong Liu <liuyonglong@huawei.com> Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://patch.msgid.link/20250409-page-pool-track-dma-v9-1-6a9ef2e0cba8@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14Merge branch '100GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2025-04-11 (ice, i40e, ixgbe, igc, e1000e) For ice: Mateusz and Larysa add support for LLDP packets to be received on a VF and transmitted by a VF in switchdev mode. Additional information: https://lore.kernel.org/intel-wired-lan/20250214085215.2846063-1-larysa.zaremba@intel.com/ Karol adds timesync support for E825C devices using 2xNAC (Network Acceleration Complex) configuration. 2xNAC mode is the mode in which IO die is housing two complexes and each of them has its own PHY connected to it. Martyna adds messaging to clarify filter errors when recipe space is exhausted. Colin Ian King adds static modifier to a const array to avoid stack usage. For i40e: Kyungwook Boo changes variable declaration types to prevent possible underflow. For ixgbe: Rand Deeb adjusts retry values so that retries are attempted. For igc: Rui Salvaterra sets VLAN offloads to be enabled as default. For e1000e: Piotr Wejman converts driver to use newer hardware timestamping API. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: net: e1000e: convert to ndo_hwtstamp_get() and ndo_hwtstamp_set() igc: enable HW vlan tag insertion/stripping by default ixgbe: Fix unreachable retry logic in combined and byte I2C write functions i40e: fix MMIO write access to an invalid page in i40e_clear_hw ice: make const read-only array dflt_rules static ice: improve error message for insufficient filter space ice: enable timesync operation on 2xNAC E825 devices ice: refactor ice_sbq_msg_dev enum ice: remove SW side band access workaround for E825 ice: enable LLDP TX for VFs through tc ice: support egress drop rules on PF ice: remove headers argument from ice_tc_count_lkups ice: receive LLDP on trusted VFs ice: do not add LLDP-specific filter if not necessary ice: fix check for existing switch rule ==================== Link: https://patch.msgid.link/20250411204401.3271306-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14Merge branch '1GbE' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== igc: Fix PTM timeout Christopher S M Hall says: There have been sporadic reports of PTM timeouts using i225/i226 devices These timeouts have been root caused to: 1) Manipulating the PTM status register while PTM is enabled and triggered 2) The hardware retrying too quickly when an inappropriate response is received from the upstream device The issue can be reproduced with the following: $ sudo phc2sys -R 1000 -O 0 -i tsn0 -m Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue. PHC2SYS exits with: "ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction fails The first patch in this series also resolves an issue reported by Corinna Vinschen relating to kdump: This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM. The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle. When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump. With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not zero, but extremly reduced. * '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: igc: add lock preventing multiple simultaneous PTM transactions igc: cleanup PTP module if probe fails igc: handle the IGC_PTP_ENABLED flag correctly igc: move ktime snapshot into PTM retry loop igc: increase wait time before retrying PTM igc: fix PTM cycle trigger logic ==================== Link: https://patch.msgid.link/20250411162857.2754883-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-14bna: bnad_dim_timeout: Rename del_timer_sync in commentWangYuli
Commit 8fa7292fee5c ("treewide: Switch/rename to timer_delete[_sync]()") switched del_timer_sync to timer_delete_sync, but did not modify the comment for bnad_dim_timeout(). Now fix it. Signed-off-by: WangYuli <wangyuli@uniontech.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/61DDCE7AB5B6CE82+20250411101736.160981-1-wangyuli@uniontech.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-11wifi: ath12k: reset MLO global memory during recoveryAditya Kumar Singh
When operating with multiple devices grouped together, the firmware stores data related to the state machine of each partner device in the MLO global memory region. If the firmware crashes, it updates the state to 'crashed'. During recovery, this memory is shared with the firmware again, and upon detecting the 'crashed' state, it reasserts. This leads to a loop of firmware asserts and it never recovers. Hence to fix this issue, once all devices in the group have been asserted and powered down, reset the MLO global memory region. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-9-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: handle ath12k_core_reset() with hardware groupingAditya Kumar Singh
Currently, in ath12k_core_reset(), the device is powered up immediately after a power down. However, with hardware grouping, when one device asserts, all partner devices also asserts. If there is a delay in processing these asserts, by the time this device powers up, other devices might still be asserting, leading to an overall recovery failure. To prevent this issue, ensure all asserts for a group are processed before initiating the power-up sequence. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-8-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: handle ath12k_core_restart() with hardware groupingAditya Kumar Singh
Currently, when ath12k_core_restart() is called and the ab->is_reset flag is set, it invokes ieee80211_restart_hw() for all hardware in the same group. However, other hardware might still be in the recovery process, making this call inappropriate with grouping into picture. To address this, add a condition to check if the group is ready. If the group is not ready, do not call ieee80211_restart_hw(). Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-7-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix ath12k_core_pre_reconfigure_recovery() with groupingAditya Kumar Singh
Currently, ath12k_core_pre_reconfigure_recovery() reconfigures all radios within the same group. During grouping and driver going for a recovery, this function is called as many times as there are devices in the group. Consequently, it performs the same reconfiguration multiple times, which is unnecessary. To prevent this, add a check to continue if the action has already been taken. To simplify the management of various flags, the reason for hardware queues being stopped is used as a check instead of introducing a new flag. While at it, also add missing wiphy locks. Wiphy lock is required since ath12k_mac_drain_tx() which is called by ath12k_core_pre_reconfigure_recovery() needs this lock to be held by the caller. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-6-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix firmware assert during reboot with hardware groupingAditya Kumar Singh
At present, during PCI shutdown, the power down is only executed for a single device. However, when operating in a group, all devices need to be powered down simultaneously. Failure to do so will result in a firmware assertion. Hence, introduce a new ath12k_pci_hw_group_power_down() and call it during power down. This will ensure that all partner devices are properly powered down. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-5-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix ATH12K_FLAG_REGISTERED flag handlingAditya Kumar Singh
Commit a5686ae820fa ("wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()") relocated the setting of the ATH12K_FLAG_REGISTERED flag to the ath12k_mac_register() function. However, this function only accesses the first device (ab) via ag->ab[0], resulting in the flag being set only for the first device in the group. Similarly, ath12k_mac_unregister() only unsets the flag for the first device. The flag should actually be set for all devices in the group to avoid issues during recovery. Hence, move setting and clearing of this flag in the function ath12k_core_hw_group_start() and ath12k_core_hw_group_stop() respectively. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: a5686ae820fa ("wifi: ath12k: move ATH12K_FLAG_REGISTERED handling to ath12k_mac_register()") Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-4-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix failed to set mhi state error during reboot with hardware ↵Aditya Kumar Singh
grouping With hardware grouping, during reboot, whenever a device is removed, it powers down itself and all its partner devices in the same group. Now this is done by all devices and hence there is multiple power down for devices and hence the following error messages can be seen: ath12k_pci 0002:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0002:01:00.0: failed to set mhi state: POWER_OFF(3) ath12k_pci 0002:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0) ath12k_pci 0002:01:00.0: failed to set mhi state: DEINIT(1) ath12k_pci 0003:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0003:01:00.0: failed to set mhi state: POWER_OFF(3) ath12k_pci 0003:01:00.0: failed to set mhi state DEINIT(1) in current mhi state (0x0) ath12k_pci 0003:01:00.0: failed to set mhi state: DEINIT(1) ath12k_pci 0004:01:00.0: failed to set mhi state POWER_OFF(3) in current mhi state (0x0) ath12k_pci 0004:01:00.0: failed to set mhi state: POWER_OFF(3) To prevent this, check if the ATH12K_PCI_FLAG_INIT_DONE flag is already set before powering down. If it is set, it indicates that another partner device has already performed the power down, and this device can skip this step. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-3-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: add reference counting for core attachment to hardware groupAditya Kumar Singh
Currently, driver does not manage reference counting for attaching and detaching cores to/from hardware groups. This can lead to issues when multiple cores are involved. Or with same core, attach/detach is called multiple times back to back. Fix this issue by using reference counting. With that, it is now ensured that the core is properly attached or detached from the hardware group and even back to back calls will not alter the count. Additionally, add some debug logs during the attachment and detachment events for better debugging and tracking. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-2-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: fix SLUB BUG - Object already free in ath12k_reg_free()Aditya Kumar Singh
During rmmod of ath12k module with SLUB debug enabled, following print is seen - ============================================================================= BUG kmalloc-1k (Not tainted): Object already free ----------------------------------------------------------------------------- Allocated in ath12k_reg_build_regd+0x94/0xa20 [ath12k] age=10470 cpu=0 pid=0 __kmalloc_noprof+0xf4/0x368 ath12k_reg_build_regd+0x94/0xa20 [ath12k] ath12k_wmi_op_rx+0x199c/0x2c14 [ath12k] ath12k_htc_rx_completion_handler+0x398/0x554 [ath12k] ath12k_ce_per_engine_service+0x248/0x368 [ath12k] ath12k_pci_ce_workqueue+0x28/0x50 [ath12k] process_one_work+0x14c/0x28c bh_worker+0x22c/0x27c workqueue_softirq_action+0x80/0x90 tasklet_action+0x14/0x3c handle_softirqs+0x108/0x240 __do_softirq+0x14/0x20 Freed in ath12k_reg_free+0x40/0x74 [ath12k] age=136 cpu=2 pid=166 kfree+0x148/0x248 ath12k_reg_free+0x40/0x74 [ath12k] ath12k_core_hw_group_destroy+0x68/0xac [ath12k] ath12k_core_deinit+0xd8/0x124 [ath12k] ath12k_pci_remove+0x6c/0x130 [ath12k] pci_device_remove+0x44/0xe8 device_remove+0x4c/0x80 device_release_driver_internal+0x1d0/0x22c driver_detach+0x50/0x98 bus_remove_driver+0x70/0xf4 driver_unregister+0x30/0x60 pci_unregister_driver+0x24/0x9c ath12k_pci_exit+0x18/0x24 [ath12k] __arm64_sys_delete_module+0x1a0/0x2a8 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 Slab 0xfffffdffc0033600 objects=10 used=6 fp=0xffff000000cdcc00 flags=0x3fffe0000000240(workingset|head|node=0|zone=0|lastcpupid=0x1ffff) Object 0xffff000000cdcc00 @offset=19456 fp=0xffff000000cde400 [...] This issue arises because in ath12k_core_hw_group_destroy(), each device calls ath12k_core_soc_destroy() for itself and all its partners within the same group. Since ath12k_core_hw_group_destroy() is invoked for each device, this results in a double free condition, eventually causing the SLUB bug. To resolve this, set the freed pointers to NULL. And since there could be a race condition to read these pointers, guard these with the available mutex lock. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: 6f245ea0ec6c ("wifi: ath12k: introduce device group abstraction") Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250408-fix_reboot_issues_with_hw_grouping-v4-1-95e7bf048595@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: Fix buffer overflow in debugfsDan Carpenter
If the user tries to write more than 32 bytes then it results in memory corruption. Fortunately, this is debugfs so it's limited to root users. Fixes: 3f73c24f28b3 ("wifi: ath12k: Add support to enable debugfs_htt_stats") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/35daefbd-d493-41d9-b192-96177d521b40@stanley.mountain Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath12k: Fix a couple NULL vs IS_ERR() bugsDan Carpenter
The devm_memremap() function returns error pointers on error and the ioremap() function returns NULL on error. The error checking here got those flipped around. Fixes: c01d5cc9b9fe ("wifi: ath12k: Power up userPD") Fixes: 6cee30f0da75 ("wifi: ath12k: add AHB driver support for IPQ5332") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/937abc74-9648-4c05-a2c3-8db408b3ed9e@stanley.mountain Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-04-11wifi: ath11k: Use of_property_present() to test property presenceRob Herring (Arm)
The use of of_property_read_u32() isn't really correct as "memory-region" contains phandles (though those happen to be u32s. As it is just testing for property presence, use of_property_present() instead. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250408190211.2505737-2-robh@kernel.org Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>