summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2025-04-24Merge tag 'wireless-2025-04-24' of ↵Jakub Kicinski19-195/+217
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Some more fixes, notably: * iwlwifi: various regression and iwlmld fixes * mac80211: fix TX frames in monitor mode * brcmfmac: error handling for firmware load * tag 'wireless-2025-04-24' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: wifi: iwlwifi: restore missing initialization of async_handlers_list wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage() wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release wifi: iwlwifi: fix the check for the SCRATCH register upon resume wifi: iwlwifi: don't warn if the NIC is gone in resume wifi: iwlwifi: mld: fix BAID validity check wifi: iwlwifi: back off on continuous errors wifi: iwlwifi: mld: only create debugfs symlink if it does not exist wifi: iwlwifi: mld: inform trans on init failure wifi: iwlwifi: mld: properly handle async notification in op mode start Revert "wifi: iwlwifi: make no_160 more generic" Revert "wifi: iwlwifi: add support for BE213" wifi: mac80211: restore monitor for outgoing frames ==================== Link: https://patch.msgid.link/20250424120535.56499-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24Merge tag 'net-6.15-rc4' of ↵Linus Torvalds19-159/+211
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "No fixes from any subtree. Current release - regressions: - net: fix the missing unlock for detached devices Previous releases - regressions: - sched: fix UAF vulnerability in HFSC qdisc - lwtunnel: disable BHs when required - mptcp: pm: defer freeing of MPTCP userspace path manager entries - tipc: fix NULL pointer dereference in tipc_mon_reinit_self() - eth: virtio-net: disable delayed refill when pausing rx Previous releases - always broken: - phylink: fix suspend/resume with WoL enabled and link down - eth: - mlx5: fix null-ptr-deref in mlx5_create_{inner_,}ttc_table() - xen-netfront: handle NULL returned by xdp_convert_buff_to_frame() - enetc: fix frame corruption on bpf_xdp_adjust_head/tail() and XDP_PASS - stmmac: fix dwmac1000 ptp timestamp status offset - pds_core: prevent possible adminq overflow/stuck condition Misc: - a bunch of MAINTAINERS updates" * tag 'net-6.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (32 commits) net: stmmac: fix multiplication overflow when reading timestamp net: stmmac: fix dwmac1000 ptp timestamp status offset net: dp83822: Fix OF_MDIO config check pds_core: make wait_context part of q_info pds_core: Remove unnecessary check in pds_client_adminq_cmd() pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result pds_core: Prevent possible adminq overflow/stuck condition net: dsa: mt7530: sync driver-specific behavior of MT7531 variants selftests/tc-testing: Add test for HFSC queue emptying during peek operation net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too net_sched: hfsc: Fix a UAF vulnerability in class handling selftests: mptcp: diag: use mptcp_lib_get_info_value mptcp: pm: Defer freeing of MPTCP userspace path manager entries net: ethernet: mtk_eth_soc: net: revise NETSYSv3 hardware configuration tipc: fix NULL pointer dereference in tipc_mon_reinit_self() virtio-net: disable delayed refill when pausing rx net: phy: leds: fix memory leak net: phylink: mac_link_(up|down)() clarifications net: phylink: fix suspend/resume with WoL enabled and link down net: lwtunnel: disable BHs when required ...
2025-04-24net: phy: marvell-88q2xxx: Enable temperature sensor for mv88q211xNiklas Söderlund1-12/+2
The temperature sensor enabled for mv88q222x devices also functions for mv88q211x based devices. Unify the two devices probe functions to enable the sensors for all devices supported by this driver. The same oddity as for mv88q222x devices exists, the PHY link must be up for a correct temperature reading to be reported. # cat /sys/class/hwmon/hwmon9/temp1_input -75000 # ifconfig end5 up # cat /sys/class/hwmon/hwmon9/temp1_input 59000 Worth noting is that while the temperature register offsets and layout are the same between mv88q211x and mv88q222x devices their names in the datasheets are different. This change keeps the mv88q222x names for the mv88q211x support. Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Dimitri Fedrau <dima.fedrau@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250418145800.2420751-1-niklas.soderlund+renesas@ragnatech.se Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-24net: stmmac: fix multiplication overflow when reading timestampAlexis Lothoré2-2/+2
The current way of reading a timestamp snapshot in stmmac can lead to integer overflow, as the computation is done on 32 bits. The issue has been observed on a dwmac-socfpga platform returning chaotic timestamp values due to this overflow. The corresponding multiplication is done with a MUL instruction, which returns 32 bit values. Explicitly casting the value to 64 bits replaced the MUL with a UMLAL, which computes and returns the result on 64 bits, and so returns correctly the timestamps. Prevent this overflow by explicitly casting the intermediate value to u64 to make sure that the whole computation is made on u64. While at it, apply the same cast on the other dwmac variant (GMAC4) method for snapshot retrieval. Fixes: 477c3e1f6363 ("net: stmmac: Introduce dwmac1000 timestamping operations") Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20250423-stmmac_ts-v2-2-e2cf2bbd61b1@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-24net: stmmac: fix dwmac1000 ptp timestamp status offsetAlexis Lothore1-2/+2
When a PTP interrupt occurs, the driver accesses the wrong offset to learn about the number of available snapshots in the FIFO for dwmac1000: it should be accessing bits 29..25, while it is currently reading bits 19..16 (those are bits about the auxiliary triggers which have generated the timestamps). As a consequence, it does not compute correctly the number of available snapshots, and so possibly do not generate the corresponding clock events if the bogus value ends up being 0. Fix clock events generation by reading the correct bits in the timestamp register for dwmac1000. Fixes: 477c3e1f6363 ("net: stmmac: Introduce dwmac1000 timestamping operations") Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20250423-stmmac_ts-v2-1-e2cf2bbd61b1@bootlin.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-24net: dp83822: Fix OF_MDIO config checkJohannes Schneider1-1/+1
When CONFIG_OF_MDIO is set to be a module the code block is not compiled. Use the IS_ENABLED macro that checks for both built in as well as module. Fixes: 5dc39fd5ef35 ("net: phy: DP83822: Add ability to advertise Fiber connection") Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20250423044724.1284492-1-johannes.schneider@leica-geosystems.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-04-24pds_core: make wait_context part of q_infoShannon Nelson3-24/+18
Make the wait_context a full part of the q_info struct rather than a stack variable that goes away after pdsc_adminq_post() is done so that the context is still available after the wait loop has given up. There was a case where a slow development firmware caused the adminq request to time out, but then later the FW finally finished the request and sent the interrupt. The handler tried to complete_all() the completion context that had been created on the stack in pdsc_adminq_post() but no longer existed. This caused bad pointer usage, kernel crashes, and much wailing and gnashing of teeth. Fixes: 01ba61b55b20 ("pds_core: Add adminq processing and commands") Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250421174606.3892-5-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24pds_core: Remove unnecessary check in pds_client_adminq_cmd()Brett Creeley1-3/+0
When the pds_core driver was first created there were some race conditions around using the adminq, especially for client drivers. To reduce the possibility of a race condition there's a check against pf->state in pds_client_adminq_cmd(). This is problematic for a couple of reasons: 1. The PDSC_S_INITING_DRIVER bit is set during probe, but not cleared until after everything in probe is complete, which includes creating the auxiliary devices. For pds_fwctl this means it can't make any adminq commands until after pds_core's probe is complete even though the adminq is fully up by the time pds_fwctl's auxiliary device is created. 2. The race conditions around using the adminq have been fixed and this path is already protected against client drivers calling pds_client_adminq_cmd() if the adminq isn't ready, i.e. see pdsc_adminq_post() -> pdsc_adminq_inc_if_up(). Fix this by removing the pf->state check in pds_client_adminq_cmd() because invalid accesses to pds_core's adminq is already handled by pdsc_adminq_post()->pdsc_adminq_inc_if_up(). Fixes: 10659034c622 ("pds_core: add the aux client API") Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250421174606.3892-4-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL resultBrett Creeley1-3/+1
If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the "devlink dev info" devlink command. This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array. Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails. Fixes: 45d76f492938 ("pds_core: set up device and adminq") Signed-off-by: Brett Creeley <brett.creeley@amd.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250421174606.3892-3-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24pds_core: Prevent possible adminq overflow/stuck conditionBrett Creeley2-5/+2
The pds_core's adminq is protected by the adminq_lock, which prevents more than 1 command to be posted onto it at any one time. This makes it so the client drivers cannot simultaneously post adminq commands. However, the completions happen in a different context, which means multiple adminq commands can be posted sequentially and all waiting on completion. On the FW side, the backing adminq request queue is only 16 entries long and the retry mechanism and/or overflow/stuck prevention is lacking. This can cause the adminq to get stuck, so commands are no longer processed and completions are no longer sent by the FW. As an initial fix, prevent more than 16 outstanding adminq commands so there's no way to cause the adminq from getting stuck. This works because the backing adminq request queue will never have more than 16 pending adminq commands, so it will never overflow. This is done by reducing the adminq depth to 16. Fixes: 45d76f492938 ("pds_core: set up device and adminq") Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250421174606.3892-2-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24net/mlx5: HWS, Disallow matcher IP version mixingVlad Dogaru3-0/+160
Signal clearly to the user, via an error, that mixing IPv4 and IPv6 rules in the same matcher is not supported. Previously such cases silently failed by adding a rule that did not work correctly. Rules can specify an IP version by one of two fields: IP version or ethertype. At matcher creation, store whether the template matches on any of these two fields. If yes, inspect each rule for its corresponding match value and store the IP version inside the matcher to guard against inconsistencies with subsequent rules. Furthermore, also check rules for internal consistency, i.e. verify that the ethertype and IP version match values do not contradict each other. The logic applies to inner and outer headers independently, to account for tunneling. Rules that do not match on IP addresses are not affected. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Mark Bloch <mbloch@nvidia.com> Link: https://patch.msgid.link/20250422092540.182091-4-mbloch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24net/mlx5: HWS, Harden IP version definer checksVlad Dogaru1-2/+42
Replicate some sanity checks that firmware does, since hardware steering does not go through firmware. When creating a definer, disallow matching on IP addresses without also matching on IP version. The latter can be satisfied by matching either on the version field in the IP header, or on the ethertype field. Also refuse to match IPv4 IHL alongside IPv6. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Mark Bloch <mbloch@nvidia.com> Link: https://patch.msgid.link/20250422092540.182091-3-mbloch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24net/mlx5: HWS, Fix IP version decisionVlad Dogaru1-22/+16
Unify the check for IP version when creating a definer. A given matcher is deemed to match on IPv6 if any of the higher order (>31) bits of source or destination address mask are set. A single packet cannot mix IP versions between source and destination addresses, so it makes no sense that they would be decided on independently. Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Mark Bloch <mbloch@nvidia.com> Link: https://patch.msgid.link/20250422092540.182091-2-mbloch@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24net: dsa: mt7530: sync driver-specific behavior of MT7531 variantsDaniel Golle1-3/+3
MT7531 standalone and MMIO variants found in MT7988 and EN7581 share most basic properties. Despite that, assisted_learning_on_cpu_port and mtu_enforcement_ingress were only applied for MT7531 but not for MT7988 or EN7581, causing the expected issues on MMIO devices. Apply both settings equally also for MT7988 and EN7581 by moving both assignments form mt7531_setup() to mt7531_setup_common(). This fixes unwanted flooding of packets due to unknown unicast during DA lookup, as well as issues with heterogenous MTU settings. Fixes: 7f54cc9772ce ("net: dsa: mt7530: split-off common parts from mt7531_setup") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Chester A. Unal <chester.a.unal@arinc9.com> Link: https://patch.msgid.link/89ed7ec6d4fa0395ac53ad2809742bb1ce61ed12.1745290867.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24octeontx2-pf: AF_XDP: code clean upHariprasad Kelam3-14/+35
The current API, otx2_xdp_sq_append_pkt, verifies the number of available descriptors before sending packets to the hardware. However, for AF_XDP, this check is unnecessary because the batch value is already determined based on the free descriptors. This patch introduces a new API, "otx2_xsk_sq_append_pkt" to address this. Remove the logic for releasing the TX buffers, as it is implicitly handled by xsk_tx_peek_release_desc_batch Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Link: https://patch.msgid.link/20250420032350.4047706-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24Merge branch '1GbE' of ↵Jakub Kicinski15-220/+525
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== igc: Add support for Frame Preemption Faizal Rahim says: Introduce support for the FPE feature in the IGC driver. The patches aligns with the upstream FPE API: https://patchwork.kernel.org/project/netdevbpf/cover/20230220122343.1156614-1-vladimir.oltean@nxp.com/ https://patchwork.kernel.org/project/netdevbpf/cover/20230119122705.73054-1-vladimir.oltean@nxp.com/ It builds upon earlier work: https://patchwork.kernel.org/project/netdevbpf/cover/20220520011538.1098888-1-vinicius.gomes@intel.com/ The patch series adds the following functionalities to the IGC driver: a) Configure FPE using `ethtool --set-mm`. b) Display FPE settings via `ethtool --show-mm`. c) View FPE statistics using `ethtool --include-statistics --show-mm'. e) Block setting preemptible tc in taprio since it is not supported yet. Existing code already blocks it in mqprio. Tested: Enabled CONFIG_PROVE_LOCKING, CONFIG_DEBUG_ATOMIC_SLEEP, CONFIG_DMA_API_DEBUG, and CONFIG_KASAN 1) selftests 2) netdev down/up cycles 3) suspend/resume cycles 4) fpe verification No bugs or unusual dmesg logs were observed. Ran 1), 2) and 3) with and without the patch series, compared dmesg and selftest logs - no differences found. * '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: igc: add support to get frame preemption statistics via ethtool igc: add support to get MAC Merge data via ethtool igc: block setting preemptible traffic class in taprio igc: add support to set tx-min-frag-size igc: add support for frame preemption verification igc: set the RX packet buffer size for TSN mode igc: use FIELD_PREP and GENMASK for existing RX packet buffer size igc: optimize TX packet buffer utilization for TSN mode igc: use FIELD_PREP and GENMASK for existing TX packet buffer size igc: rename I225_RXPBSIZE_DEFAULT and I225_TXPBSIZE_DEFAULT igc: rename xdp_get_tx_ring() for non-xdp usage net: ethtool: mm: reset verification status when link is down net: ethtool: mm: extract stmmac verification logic into common library net: stmmac: move frag_size handling out of spin_lock ==================== Link: https://patch.msgid.link/20250418163822.3519810-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24net: airoha: Enable multiple IRQ lines support in airoha_eth driver.Lorenzo Bianconi3-59/+206
EN7581 ethernet SoC supports 4 programmable IRQ lines for Tx and Rx interrupts. Enable multiple IRQ lines support. Map Rx/Tx queues to the available IRQ lines using the default scheme used in the vendor SDK: - IRQ0: rx queues [0-4],[7-9],15 - IRQ1: rx queues [21-30] - IRQ2: rx queues 5 - IRQ3: rx queues 6 Tx queues interrupts are managed by IRQ0. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250418-airoha-eth-multi-irq-v1-2-1ab0083ca3c1@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24net: airoha: Introduce airoha_irq_bank structLorenzo Bianconi3-44/+86
EN7581 ethernet SoC supports 4 programmable IRQ lines each one composed by 4 IRQ configuration registers. Add airoha_irq_bank struct as a container for independent IRQ lines info (e.g. IRQ number, enabled source interrupts, ecc). This is a preliminary patch to support multiple IRQ lines in airoha_eth driver. Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20250418-airoha-eth-multi-irq-v1-1-1ab0083ca3c1@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24r8169: merge chip versions 52 and 53 (RTL8117)Heiner Kallweit3-12/+7
Handling of both chip versions is the same, only difference is the firmware. So we can merge handling of both chip versions. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/ae866b71-c904-434e-befb-848c831e33ff@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24r8169: merge chip versions 64 and 65 (RTL8125D)Heiner Kallweit3-5/+1
Handling of both chip versions is the same, only difference is the firmware. So we can merge handling of both chip versions. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/0baad123-c679-4154-923f-fdc12783e900@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24r8169: merge chip versions 70 and 71 (RTL8126A)Heiner Kallweit3-13/+4
Handling of both chip versions is the same, only difference is the firmware. So we can merge handling of both chip versions. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/97d7ae79-d021-4b6b-b424-89e5e305b029@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24net: phy: remove function stubsHeiner Kallweit1-0/+1
All callers of these functions depend on PHYLIB or select it directly or indirectly by selecting PHYLINK. Stubs make sense for optional functionality, but that's not the case here. MDIO_XGENE usually is selected by NET_XGENE which also selects PHYLIB. Add a dependency to PHYLIB nevertheless, in order not to break randconfig builds. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/f7a69a1f-60e9-4ac0-8b7c-481e0cc850e7@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24net: stmmac: dwc-qos: calibrate tegra with mdio bus idleRussell King (Oracle)1-2/+10
Thierry states that there are prerequists for Tegra's calibration that should be met before starting calibration - both the RGMII and MDIO interfaces should be idle. This commit adds the necessary MII bus locking to ensure that the MDIO interface is idle during calibration. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/E1u7EYR-001ZAS-Cr@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-24bnxt_en: hide CONFIG_DETECT_HUNG_TASK specific codeArnd Bergmann1-0/+2
The CONFIG_DEFAULT_HUNG_TASK_TIMEOUT setting is only available when the hung task detection is enabled, otherwise the code now produces a build failure: drivers/net/ethernet/broadcom/bnxt/bnxt.c:10188:21: error: use of undeclared identifier 'CONFIG_DEFAULT_HUNG_TASK_TIMEOUT' 10188 | max_tmo_secs > CONFIG_DEFAULT_HUNG_TASK_TIMEOUT) { Enclose this warning logic in an #ifdef to ensure this builds. Fixes: 0fcad44a86bd ("bnxt_en: Change FW message timeout warning") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://patch.msgid.link/20250423162827.2189658-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-04-23PCI: Add CONFIG_MMU dependencyArnd Bergmann1-1/+0
It turns out that there are no platforms that have PCI but don't have an MMU, so adding a Kconfig dependency on CONFIG_PCI simplifies build testing kernels for those platforms a lot, and avoids a lot of inadvertent build regressions. Add a dependency for CONFIG_PCI and remove all the ones for PCI specific device drivers that are currently marked not having it. There are a few platforms that have an optional MMU, but they usually cannot have PCI at all. The one exception is Coldfire MCF54xx, but this is mainly for historic reasons, and anyone using those chips should really use the MMU these days. Link: https://lore.kernel.org/lkml/a41f1b20-a76c-43d8-8c36-f12744327a54@app.fastmail.com/ Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> # SCSI Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20250423202215.3315550-1-arnd@kernel.org
2025-04-23wifi: mac80211: restructure tx profile retrieval for MLO MBSSIDRameshkumar Sundaram3-9/+30
For MBSSID, each vif (struct ieee80211_vif) stores another vif pointer for the transmitting profile of MBSSID set. This won't suffice for MLO as there may be multiple links, each of which can be part of different MBSSID sets. Hence the information needs to be stored per-link. Additionally, the transmitted profile itself may be part of an MLD hence storing vif will not suffice either. Fix MLO by storing an instance of struct ieee80211_bss_conf for each link. Modify following operations to reflect the above structure updates: - channel switch completion - BSS color change completion - Removing nontransmitted links in ieee80211_stop_mbssid() - drivers retrieving the transmitted link for beacon templates. Signed-off-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com> Co-developed-by: Muna Sinada <muna.sinada@oss.qualcomm.com> Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com> Co-developed-by: Aloka Dixit <aloka.dixit@oss.qualcomm.com> Signed-off-by: Aloka Dixit <aloka.dixit@oss.qualcomm.com> Link: https://patch.msgid.link/20250408184501.3715887-3-aloka.dixit@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: remove mwifiex_sta_init_cmd() last argumentSascha Hauer4-7/+7
The init argument from mwifiex_sta_init_cmd() is no longer used. Drop it. Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20250423-mwifiex-drop-asynchronous-init-v2-4-1bb951073a06@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: drop asynchronous init waiting codeSascha Hauer6-61/+4
Historically all commands sent to the mwifiex driver have been asynchronous. The different commands sent during driver initialization have been queued at once and only the final command has been waited for being ready before finally starting the driver. This has been changed in Commit 7bff9c974e1a ("mwifiex: send firmware initialization commands synchronously"). With this the initialization is finished once the last mwifiex_send_cmd_sync() (now mwifiex_send_cmd()) has returned. This makes all the code used to wait for the last initialization command to be finished unnecessary, so it's removed in this patch. Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20250423-mwifiex-drop-asynchronous-init-v2-3-1bb951073a06@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: let mwifiex_init_fw() return 0 for successSascha Hauer3-10/+4
mwifiex_sta_init_cmd() returns -EINPROGRESS as success indication when the init param is true. Likewise mwifiex_init_fw() returns -EINPROGRESS as success indication: It will either return -EINPROGRESS directly when in mfg_mode or the return value of mwifiex_sta_init_cmd() when in normal mode. -EINPROGRESS is a leftover from times when the initialization commands were sent asynchronously. Since Commit 7bff9c974e1a ("mwifiex: send firmware initialization commands synchronously") the return value has become meaningless, so change mwifiex_sta_init_cmd() and mwifiex_init_fw() to return 0 for success. Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20250423-mwifiex-drop-asynchronous-init-v2-2-1bb951073a06@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: remove unnecessary queue empty checkSascha Hauer1-10/+3
Since Commit 7bff9c974e1a ("mwifiex: send firmware initialization commands synchronously") all initialization commands are sent synchronously which means the command queue is empty when mwifiex_sta_init_cmd() returns. No need to check for entries in the command code then, so remove the check. Add a WARN_ON() just in case there is something wrong with the reasoning. Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Acked-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20250423-mwifiex-drop-asynchronous-init-v2-1-1bb951073a06@pengutronix.de [remove now unused is_cmd_pend_q_empty variable and comment] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: set step_urm in transport and not in the opmodesMiri Korenblit3-9/+5
This has nothing to do with the opmode. Set it in the transport layer instead. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Tested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20250423091408.4e288f7897be.I0c8f792ea2ed6967f8c6d8181f9c5f74bbec7d18@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mld: tests: simplify le32 bitfield handlingJohannes Berg1-7/+7
We can use le32_encode_bits() instead of cpu_to_le32() combined with FIELD_PREP(). Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250423091408.9155a412dcc7.I8330ca413d6bdf953e79361ac50939176bcc4e6e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: update the PHY_CONTEXT_CMD APIEmmanuel Grumbach1-3/+6
A new field is added, no impact on the current flows. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250423091408.0e1324ae07b7.I6d8ffda2b00c817d3f784241dd61cfe533e12d93@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mld: inform trans on init failureMiri Korenblit1-2/+3
If starting the op mode failed, the opmode memory is being freed, so trans->op_mode needs to be NULLified. Otherwise, trans will access already freed memory. Call iwl_trans_op_mode_leave in that case. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250423091408.c7e178748ef7.Ifaf15bdd8ef8c59e04effbd2e7aa0034b30eeacb@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mld: properly handle async notification in op mode startMiri Korenblit5-10/+12
From the moment that we have ALIVE, we can receive notification that are handled asynchronously. Some notifications (for example iwl_rfi_support_notif) requires an operational FW. So we need to make sure that they were handled in iwl_op_mode_mld_start before we stop the FW. Flush the async_handlers_wk there to achieve that. Also, if loading the FW in op mode start failed, we need to cancel these notifications, as they are from a dead FW. More than that, not doing so can cause us to access freed memory if async_handlers_wk is executed after ieee80211_free_hw is called. Fix this by canceling all async notifications if a failure occurred in init (after ALIVE). Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250423091408.a8f63d983466.Ifd77d9c1a29fdd278b0a7bfc2709dd5d5e5efdb1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mld: refactor purging async notificationsMiri Korenblit4-11/+11
To cancel all async notifications, we need to: - cancel async_handlers_wk - empty async_handlers_list Instead of having the callers to do both, do it in iwl_mld_purge_async_handlers_list and rename it accordingly. Note that the caller iwl_cleanup_mld didn't cancel the work, but it is harmless. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250423091408.e98aed77e836.Id9f858d9d553d406a24165b09db830df111befce@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mld: don't do iwl_trans_stop_device twiceMiri Korenblit2-3/+2
If iwl_mld_load_fw failed, we call iwl_mld_stop_fw which does, among the others, iwl_trans_stop_device. But this is already called from iwl_mld_load_fw's error path. Since we do need the other stuff of iwl_mld_stop_fw to be done also in the error path of iwl_mld_load_fw, just call it there. This also makes the call to iwl_fw_flush_dumps in iwl_mld_op_mope_start redundant, since it is the same as iwl_fw_dbg_stop_sync. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250423091408.f7d86be570d3.Ied68f0c4d126b3b0f1ffd9990bbc43d97f098e24@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mld: stop hw if mcc_init failsMiri Korenblit1-16/+10
iwl_mld_run_fw_init_sequence used to be the last thing done in iwl_mld_load_fw, and if it failed, it called iwl_trans_stop_hw. Now we also have there iwl_mld_init_mcc, and it can fail. In that case, we need to undo what we did so far, which is basically only iwl_trans_stop_device. Do that. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250423091408.ba06d972a57b.I317fb7b10ed8a688a0d92c5d99de8765d8044b10@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mld: avoid memory leak if mcc_init failsMiri Korenblit2-11/+10
allocating mld->nvm_data used to be the last thing done in iwl_mld_load_fw, so there was no need to free on any error path of iwl_mld_load_fw. But now iwl_mld_load_fw also calls iwl_mld_init_mcc, that can fail, after allocating nvm->data. In that case, it is not freed. As allocating the NVM data should only be done at op mode start anyway, simply move it to there, where it is already freed in the right error paths. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250423091408.d07469f866ac.I84ad2e624ce7cd4a661c73b4942186e50cdf82b2@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mld: remove stored_beacon supportEmmanuel Grumbach2-46/+3
We never ask the firmware to store the beacon, so it won't ever send the notification. Remove the handling of that notification. Remove that notification from the arrays of the notifications' names and add the ones that we forgot to add. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250423091408.2bb3ea3ff79b.Ie8f1d89f59d45a960a5fe63e7b717527251350ad@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mld: remove P2P powersave trackingJohannes Berg1-5/+0
Since the FW is tracking the CT window by itself, we don't need to update the MAC context or even fill in the value. We just had added that because a firmware bug had broken it for a while. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250423091408.ee164b464c21.I29de491b4d74b2b8084e54bfbd28646b15dee196@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: parse active and 20 MHz AP NVM channel flagAnjaneyulu1-14/+22
Configure 20 MHz AP mode based on NVM settings, set the NL80211_RRF_ALLOW_20MHZ_ACTIVITY flag, when the NVM indicates that an access point can operate in 20 MHz only. Signed-off-by: Somashekhar Puttagangaiah <somashekhar.puttagangaiah@intel.com> Signed-off-by: Pagadala Yesu Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250423091408.897d826a8612.I1f7f84f4485ed3928070c97a031110ccb608bda8@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: re-add IWL_AMSDU_8K caseMiri Korenblit1-0/+1
This case in iwl_trans_get_rb_size_order was accidently combined with the IWL_AMSDU_12K case. Fix this. Fixes: 7391b2a4f7db ("wifi: iwlwifi: rework firmware error handling") Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250423091408.ef19205aa358.Ifbf89e7b7391cd7070267b7360c53230b3b2c57c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: fw: do reset handshake during assert if neededJohannes Berg3-7/+23
Earlier, the firmware could only request the reset handshake is done during the dump, if the dump was split. However, it's also needed when the dump isn't split, in which case it must be done before the dump. The firmware now advertises this requirement, so do the handshake in the non-split case when asked for. Rename apply policy ..._RESET_HANDSHAKE to ..._SPLIT_DUMP_RESET to more clearly indicate that this specific dump needs to be split, while the handshake requirement overall is now indicated by the new capability flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250423091408.10adafedb74b.Ie3911db1ebbd196ae4b0de1c53012aa1de193c0d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: iwlwifi: mvm: remove IWL_EMPTYING_HW_QUEUE_DELBA stateJohannes Berg2-16/+3
This state can never be entered, since the last place using it was removed with non-DQA mode in commit c8f54701bdbf ("iwlwifi: mvm: remove non-DQA mode"). Clean up this code too. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250423091408.e8a20fb41dc5.I9cd41a15148c90e953335e7020405103ba3fc7f0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: brcm80211: fmac: Add error log in brcmf_usb_dl_cmd()Wentao Liang1-7/+16
In brcmf_usb_dl_cmd(), the error logging is not enough to describe the error state. And some caller of the brcmf_usb_dl_cmd() does not handle its error. An error log in brcmf_usb_dl_cmd() is needed to prevent silent failure. Add error handling in brcmf_usb_dl_cmd() to log the command id and error code in the brcmf_usb_dl_cmd() fails. In this way, every invocation of the function logs a message upon failure. Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20250422065938.2345-1-vulab@iscas.ac.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: Don't use %pK through printkThomas Weißschuh1-1/+1
In the past %pK was preferable to %p as it would not leak raw pointer values into the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. Furthermore, restricted pointers ("%pK") were never meant to be used through printk(). They can still unintentionally leak raw pointers or acquire sleeping looks in atomic contexts. Switch to the regular pointer formatting which is safer and easier to reason about. There are still a few users of %pK left, but these use it through seq_file, for which its usage is safe. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20250417-restricted-pointers-wifi-v1-1-b79cdaae5579@linutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: brcmsmac: Spelling correctionsSimon Horman9-15/+15
Various spelling corrections as flagged by codespell. Signed-off-by: Simon Horman <horms@kernel.org> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Link: https://patch.msgid.link/20250415-brcmsmac-spell-v1-1-3e1375586883@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: move common settings out of switch/caseSascha Hauer1-11/+5
In mwifiex_add_virtual_intf() several settings done in a switch/case are the same in all cases. Move them out of the switch/case to deduplicate the code. bss_started is not initialized in all switch/case branches, but it is only used in AP mode in the driver, so it doesn't hurt to move its initialization out of the switch/case as well. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Francesco Dolcini <francesco@dolcini.it> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-9-a6bbd4ac4d37@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-23wifi: mwifiex: make locally used function staticSascha Hauer2-2/+1
mwifiex_is_tdls_off_chan() is only used locally. Make it static. Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Brian Norris <briannorris@chromium.org> Link: https://patch.msgid.link/20250410-mwifiex-cleanup-1-v6-8-a6bbd4ac4d37@pengutronix.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-21 09:56:38 +0300