summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2025-07-11Merge tag 'wireless-next-2025-07-10' of ↵Jakub Kicinski41-790/+745
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Quite a bit more work, notably: - mt76: firmware recovery improvements, MLO work - iwlwifi: use embedded PNVM in (to be released) FW images to fix compatibility issues - cfg80211/mac80211: extended regulatory info support (6 GHz) - cfg80211: use "faux device" for regulatory * tag 'wireless-next-2025-07-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (48 commits) wifi: mac80211: don't complete management TX on SAE commit wifi: cfg80211/mac80211: implement dot11ExtendedRegInfoSupport wifi: mac80211: send extended MLD capa/ops if AP has it wifi: mac80211: copy first_part into HW scan wifi: cfg80211: add a flag for the first part of a scan wifi: mac80211: remove DISALLOW_PUNCTURING_5GHZ code wifi: cfg80211: only verify part of Extended MLD Capabilities wifi: nl80211: make nl80211_check_scan_flags() type safe wifi: cfg80211: hide scan internals wifi: mac80211: fix deactivated link CSA wifi: mac80211: add mandatory bitrate support for 6 GHz wifi: mac80211: remove spurious blank line wifi: mac80211: verify state before connection wifi: mac80211: avoid weird state in error path wifi: iwlwifi: mvm: remove support for iwl_wowlan_info_notif_v4 wifi: iwlwifi: bump minimum API version in BZ wifi: iwlwifi: mvm: remove unneeded argument wifi: iwlwifi: mvm: remove MLO GTK rekey code wifi: iwlwifi: pcie: rename iwl_pci_gen1_2_probe() argument wifi: iwlwifi: match discrete/integrated to fix some names ... ==================== Link: https://patch.msgid.link/20250710123113.24878-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11Merge tag 'wireless-2025-07-10' of ↵Jakub Kicinski31-203/+311
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless Johannes Berg says: ==================== Quite a number of fixes still: - mt76 (hadn't sent any fixes so far) - RCU - scanning - decapsulation offload - interface combinations - rt2x00: build fix (bad function pointer prototype) - cfg80211: prevent A-MSDU flipping attacks in mesh - zd1211rw: prevent race ending with NULL ptr deref - cfg80211/mac80211: more S1G fixes - mwifiex: avoid WARN on certain RX frames - mac80211: - avoid stack data leak in WARN cases - fix non-transmitted BSSID search (on certain multi-BSSID APs) - always initialize key list so driver iteration won't crash - fix monitor interface in device restart - fix __free() annotation usage * tag 'wireless-2025-07-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (26 commits) wifi: mac80211: add the virtual monitor after reconfig complete wifi: mac80211: always initialize sdata::key_list wifi: mac80211: Fix uninitialized variable with __free() in ieee80211_ml_epcs() wifi: mt76: mt792x: Limit the concurrent STA and SoftAP to operate on the same channel wifi: mt76: mt7925: Fix null-ptr-deref in mt7925_thermal_init() wifi: mt76: fix queue assignment for deauth packets wifi: mt76: add a wrapper for wcid access with validation wifi: mt76: mt7921: prevent decap offload config before STA initialization wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload() wifi: mt76: mt7925: fix incorrect scan probe IE handling for hw_scan wifi: mt76: mt7925: fix invalid array index in ssid assignment during hw scan wifi: mt76: mt7925: fix the wrong config for tx interrupt wifi: mt76: Remove RCU section in mt7996_mac_sta_rc_work() wifi: mt76: Move RCU section in mt7996_mcu_add_rate_ctrl() wifi: mt76: Move RCU section in mt7996_mcu_add_rate_ctrl_fixed() wifi: mt76: Move RCU section in mt7996_mcu_set_fixed_field() wifi: mt76: Assume __mt76_connac_mcu_alloc_sta_req runs in atomic context wifi: prevent A-MSDU attacks in mesh networks wifi: rt2x00: fix remove callback type mismatch wifi: mac80211: reject VHT opmode for unsupported channel widths ... ==================== Link: https://patch.msgid.link/20250710122212.24272-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11net: stmmac: platform: Add snps,dwmac-5.00a IP compatible stringInochi Amaoto1-0/+1
Add "snps,dwmac-5.30a" compatible string for 5.00a version that can avoid to define some platform data in the glue layer. Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Tested-by: Han Gao <rabenda.cn@gmail.com> Link: https://patch.msgid.link/20250708064052.507094-4-inochiama@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11net: stmmac: dwmac-sophgo: Add support for Sophgo SG2042 SoCInochi Amaoto1-0/+1
Adds device id of the ethernet controller on the Sophgo SG2042 SoC. Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Tested-by: Han Gao <rabenda.cn@gmail.com> Link: https://patch.msgid.link/20250708064052.507094-3-inochiama@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-11ice: introduce ice_get_vf_by_dev() wrapperJacob Keller2-6/+19
The ice_get_vf_by_id() function is used to obtain a reference to a VF structure based on its ID. The ice_sriov_set_msix_vec_count() function needs to get a VF reference starting from the VF PCI device, and uses pci_iov_vf_id() to get the VF ID. This pattern is currently uncommon in the ice driver. However, the live migration module will introduce many more such locations. Add a helper wrapper ice_get_vf_by_dev() which takes the VF PCI device and calls ice_get_vf_by_id() using pci_iov_vf_id() to get the VF ID. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-11ice: avoid rebuilding if MSI-X vector count is unchangedJacob Keller1-0/+6
Commit 05c16687e0cc ("ice: set MSI-X vector count on VF") added support to change the vector count for VFs as part of ice_sriov_set_msix_vec_count(). This function modifies and rebuilds the target VF with the requested number of MSI-X vectors. Future support for live migration will add a call to ice_sriov_set_msix_vec_count() to ensure that a migrated VF has the proper MSI-X vector count. In most cases, this request will be to set the MSI-X vector count to its current value. In that case, no work is necessary. Rather than requiring the caller to check this, update the function to check and exit early if the vector count is already at the requested value. This avoids an unnecessary VF rebuild. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-11ice: use pci_iov_vf_id() to get VF IDJacob Keller1-9/+3
The ice_sriov_set_msix_vec_count() obtains the VF device ID in a strange way by iterating over the possible VF IDs and calling pci_iov_virtfn_devfn to calculate the device and function combos and compare them to the pdev->devfn. This is unnecessary. The pci_iov_vf_id() helper already exists which does the reverse calculation of pci_iov_virtfn_devfn(), which is much simpler and avoids the loop construction. Use this instead. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-11ice: expose VF functions used by live migrationJacob Keller3-7/+32
The live migration process will require configuring the target VF with the data provided from the source host. A few helper functions in ice_sriov.c and ice_virtchnl.c will be needed for this process, but are currently static. Expose these functions in their respective headers so that the live migration module can use them during the migration process. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-11ice: move ice_vsi_update_l2tsel to ice_lib.cJacob Keller3-42/+43
A future change is going to need to call ice_vsi_update_l2tsel from a new context outside of ice_virtchnl.c Since this function deals with a generic VSI, move it into ice_lib.c to enable calling it from other places in the ice driver. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-11ice: save RSS hash configuration for migrationJacob Keller3-3/+12
The VF can program the RSS hash configuration over virtchnl. It does this by sending a u64 bitmask which represents the current hash configuration. It is not trivial to reverse the hardware configuration back to this hash set for migration. Instead, save the value to the ice_vf structure when its modified by the VF. The rss_hashcfg value is an 8-byte field. Make room for it in ice_vf by re-arranging some of the existing fields. There is a 4-byte gap after the first_vector_idx, and a 4-byte gap between max_tx_rate and vf_states. Move first_vector_idx into the later 4-byte gap, creating an 8 byte area where rss_hashcfg can be placed. Also move the num_msix field near min_tx_rate, filling 2 bytes of a 3 byte hole. The end result of these changes enables placing the rss_hashcfg field into the structure while also saving 8 bytes in size. It looks like there are a handful of more possible cleanups to reduce the size even further, but those have been left as a future cleanup. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-11ice: add functions to get and set Tx queue contextJacob Keller6-5/+204
The live migration driver will need to save and restore the Tx queue context state from the hardware registers. This state contains both static fields which do not change during Tx traffic as well as dynamic fields which may change during Tx traffic. Unlike the Rx context, the Tx queue context is accessed indirectly from GLCOMM_QTX_CNTX_CTL and GLCOMM_QTX_CNTX_DATA registers. These registers are shared by multiple PFs on the same PCIe card. Multiple PFs cannot safely access the registers simultaneously, and there is no hardware semaphore or logic to control access. To handle this, introduce the txq_ctx_lock to the ice_adapter structure. This is similar to the ptp_gltsyn_time_lock. All PFs on the same adapter share this structure, and use it to serialize access to the registers to prevent error. Add a new functions to get and set the Tx queue context through the GLCOMM_QTX_CNTX_CTL interface. The hardware context values are stored in the registers using the same packed format as the Admin Queue buffer. The hardware buffer is 40 bytes wide, as it contains an additional 18 bytes of internal state not sent with the Admin Queue buffer. For this reason, a separate typedef and packing function must be used. We can share the same packed fields definitions because we never need to unpack the internal state. This is preferred, as it ensures the internal state is zero'd when writing into HW, and avoids issues with reading by u32 registers into a buffer of 22 bytes in length. Thanks to the typedefs, misuse of the API with the wrong size buffer can easily be caught at compile time. Note reading this data from hardware is essential because the current Tx queue context may be different from the context as initially programmed by the driver during VF initialization. When migrating a VF we must ensure the target VF has identical context as the source VF did. Co-developed-by: Yahui Cao <yahui.cao@intel.com> Signed-off-by: Yahui Cao <yahui.cao@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-10Merge branch 'virtio_udp_tunnel_08_07_2025' of ↵Jakub Kicinski3-41/+228
https://github.com/pabeni/linux-devel Paolo Abeni says: ==================== virtio: introduce GSO over UDP tunnel Some virtualized deployments use UDP tunnel pervasively and are impacted negatively by the lack of GSO support for such kind of traffic in the virtual NIC driver. The virtio_net specification recently introduced support for GSO over UDP tunnel, this series updates the virtio implementation to support such a feature. Currently the kernel virtio support limits the feature space to 64, while the virtio specification allows for a larger number of features. Specifically the GSO-over-UDP-tunnel-related virtio features use bits 65-69. The first four patches in this series rework the virtio and vhost feature support to cope with up to 128 bits. The limit is set by a define and could be easily raised in future, as needed. This implementation choice is aimed at keeping the code churn as limited as possible. For the same reason, only the virtio_net driver is reworked to leverage the extended feature space; all other virtio/vhost drivers are unaffected, but could be upgraded to support the extended features space in a later time. The last four patches bring in the actual GSO over UDP tunnel support. As per specification, some additional fields are introduced into the virtio net header to support the new offload. The presence of such fields depends on the negotiated features. New helpers are introduced to convert the UDP-tunneled skb metadata to an extended virtio net header and vice versa. Such helpers are used by the tun and virtio_net driver to cope with the newly supported offloads. Tested with basic stream transfer with all the possible permutations of host kernel/qemu/guest kernel with/without GSO over UDP tunnel support. ==================== Link: https://patch.msgid.link/cover.1751874094.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10ice: add support for reading and unpacking Rx queue contextJacob Keller2-0/+62
In order to support live migration, the ice driver will need to read certain data from the Rx queue context. This is stored in the hardware in a packed format. Since we use <linux/packing.h> for the mapping between the packed hardware format and the unpacked structure, it is trivial to enable unpacking support via the unpack_fields() function. Add the ice_unpack_rxq_ctx() function based on the unpack_fields() API. Re-use the same field definitions from the packing implementation. Add ice_copy_rxq_ctx_from_hw() to copy the Rx queue context data from the hardware registers. Use these to implement ice_read_rxq_ctx() which will return the Rx queue context to the caller in its unpacked ice_rlan_ctx struct. This will enable the migration logic access to the relevant data about the Rx device queues. It can easily be copied to the target system as part of the migration payload, where it will be used to configure the Rx queues. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2025-07-10Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski12-64/+114
Cross-merge networking fixes after downstream PR (net-6.16-rc6). No conflicts. Adjacent changes: Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml 0a12c435a1d6 ("dt-bindings: net: sun8i-emac: Add A100 EMAC compatible") b3603c0466a8 ("dt-bindings: net: sun8i-emac: Rename A523 EMAC0 to GMAC0") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10wifi: iwlwifi: mvm: fix scan request validationAvraham Stern1-1/+1
The scan request validation function uses bitwise and instead of logical and. Fix it. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.3fbc1f27871b.I7a8ee91f463c1a2d9d8561c8232e196885d02c43@changeid
2025-07-10wifi: iwlwifi: pcie: add a missing includeMiri Korenblit1-0/+2
pcie/utils.h needs to include iwl-io.h for the iwl_read/iwl_write calls. Add it. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.716e8b54ebcb.If75c28a85b5ba4c2661bdf4ce20b97dbe7d2abb2@changeid
2025-07-10wifi: iwlwifi: trans: remove retake_ownership parameter from sw_resetItamar Shalev3-4/+4
Remove the retake_ownership parameter from the sw_reset function, as it was always set to true and is not needed by other opmodes. Simplify the sw_reset API function. Signed-off-by: Itamar Shalev <itamar.shalev@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.0a103d021815.I2a3da6f83aa691496a53a548bd73bddd4d4d2db8@changeid
2025-07-10wifi: iwlwifi: assign a FW API range for GFMiri Korenblit4-23/+31
GF device is frozen on API 100, so it is not allowed to use FW APIs higher than that. Make sure of that by assigning a MIN and MAX API range for GF. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.3409de06db40.I2110ee6c0a2f5ff1e16156c5875f83d7a1723857@changeid
2025-07-10wifi: iwlwifi: assign a FW API range for HRMiri Korenblit5-40/+48
HR device is frozen on API 100, so it is not allowed to use FW APIs higher than that. Make sure of that by assigning a MIN and MAX API range for HR. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.ea54c00de44d.I47340ecaefbf40bb0bd254485d242b7f39df85b1@changeid
2025-07-10wifi: iwlwifi: pcie: accept new devices for MVM-only configsJohannes Berg2-2/+3
For newer MACs, the MVM opmode may be used for older firmware images or when the RF isn't EHT/WiFi7 capable. List such devices in the PCI device list when MLD isn't built. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.483c8112f655.Ic05530048fc0b67b1cd8772882a595d56b204e65@changeid
2025-07-10wifi: iwlwifi: pcie: inform me when op mode leavingItamar Shalev3-1/+25
Transport gen2 didn't inform ME when the op mode is leaving. Signed-off-by: Itamar Shalev <itamar.shalev@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.abd840f5e998.I3a3fe174ea55a30daa04a0a3e9a6264913677045@changeid
2025-07-10wifi: iwlwifi: simplify iwl_poll_bits_mask return valueItamar Shalev4-14/+14
Update iwl_poll_bits_mask to return 0 on success or an error code. Remove timing information from the return value, as it is unused. Signed-off-by: Itamar Shalev <itamar.shalev@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.f77b9f484a78.Iae8ef99a94e25c23044e2c36244cda2b55328447@changeid
2025-07-10wifi: iwlwifi: mvm: remove support for iwl_wowlan_status_v9Miri Korenblit3-56/+2
FWs with this version are no longer supported on any device. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.22864efb5074.I51f270f8848970fd2ca1078c14ad31f4a8853e7d@changeid
2025-07-10wifi: iwlwifi: mvm: remove support for iwl_wowlan_status_v12Miri Korenblit3-53/+1
FWs with this version are no longer supported on any device. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.1b9177bfbe1d.I53c1527cc5097f05df352b6f2f99282b00a5d7ac@changeid
2025-07-10wifi: iwlwifi: add a reference to iwl_wowlan_info_notif_v3Miri Korenblit1-1/+2
Mark this structure as one of the structures that represent WOWLAN_INFO_NOTIFICATION Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.19ebfa430c5c.Ie5aca3f0af11cc3137c6b6862a13777bae0cb06b@changeid
2025-07-10wifi: iwlwifi: mvm: remove support for iwl_wowlan_info_notif_v2Miri Korenblit3-58/+6
FWs with this version are no longer supported on any device. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.d92f63207232.I8961ffbe04d0d9439d48a17840497ac926967914@changeid
2025-07-10wifi: iwlwifi: bump minimum API version for SO/MA/TYMiri Korenblit1-1/+1
Stop supporting older FWs. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709230308.64f504f3690d.Idc95ca09101e52b4980b292945abe944c24fc5d1@changeid
2025-07-10wifi: iwlwifi: assign a FW API range for JFMiri Korenblit3-17/+28
JF device is frozen on API 77. This prevented us from bumping the minimum FW API of SO (and get rid of older FWs). This is because SO can be combined with JF and then FW API 77 should be used. Now as we have separate FW API ranges for the mac and the crf, we can define for JF its own FW API range. This will allow bumping the minimum FW API of SO Independently. Do that now. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20250709200543.1628666-3-miriam.rachel.korenblit@intel.com
2025-07-10wifi: iwlwifi: handle non-overlapping API rangesMiri Korenblit1-2/+6
The option to set an api_version_min/max also to the RF was added. In the case that both the MAC and the RF has a range defined, we take the narrower range of both. This doesn't work for non-overlapping ranges. In this case, we should just take the lower range of both. Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20250709200543.1628666-2-miriam.rachel.korenblit@intel.com
2025-07-10wifi: ath12k: allow beacon protection keys to be installed in hardwareKarthikeyan Kathirvel4-13/+48
Install beacon protection keys in hardware for AP modes only if hardware supports it, as indicated by the WMI service bit WMI_TLV_SERVICE_BEACON_PROTECTION_SUPPORT. Allow keyidx up to 7, since beacon protection uses keyidx 6 and 7. Control this feature by setting bit 0 of feature_enable_bitmap when sending the WMI_BCN_TMPL_CMDID command to firmware. Check for the beacon protection enabled bit in both tx and non-tx profiles for MBSSID cases. If set in either profile, enable the beacon protection feature in firmware for transmitted vif. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Signed-off-by: Karthikeyan Kathirvel <karthikeyan.kathirvel@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250604101620.2948103-1-karthikeyan.kathirvel@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-07-10wifi: ath12k: set RX_FLAG_SKIP_MONITOR in WBM error pathP Praneesh1-0/+2
Packets delivered to mac80211 from the WBM error path currently do not have the RX_FLAG_SKIP_MONITOR flag set in status->flag. As a result, mac80211 performs unnecessary monitor mode checks on each packet, even though these packets are not intended for monitor mode processing. In regular rx path, this flag is explicitly set to avoid such overhead. Align the WBM error path behavior by setting RX_FLAG_SKIP_MONITOR to prevent redundant per-packet checks in mac80211. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-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: P Praneesh <praneesh.p@oss.qualcomm.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250605050135.1802902-1-praneesh.p@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-07-10wifi: ath12k: pack HTT pdev rate stats structsJeff Johnson1-3/+3
In order to ensure the HTT DebugFS structs shared with firmware have matching alignment, the structs should be packed. Most of the structs are correctly packed, however the following are not: ath12k_htt_tx_pdev_rate_stats_tlv ath12k_htt_rx_pdev_rate_stats_tlv ath12k_htt_rx_pdev_rate_ext_stats_tlv So pack those structs. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: ba42b22aa336 ("wifi: ath12k: Dump PDEV transmit rate HTT stats") Fixes: a24cd7583003 ("wifi: ath12k: Dump PDEV receive rate HTT stats") Fixes: 7a3e8eec8d18 ("wifi: ath12k: Dump additional PDEV receive rate HTT stats") Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250702-debugfs_htt_packed-v1-1-07bd18b31e79@oss.qualcomm.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-07-10wifi: ath12k: update unsupported bandwidth flags in reg rulesHarshitha Prem1-3/+28
The maximum bandwidth an interface can operate in is defined by the configured country. However, currently, it is able to operate in bandwidths greater than the allowed bandwidth. For example, the Central African Republic (CF) supports a maximum bandwidth of 40 MHz in both the 2 GHz and 5 GHz bands, but an interface is still able to operate in bandwidths higher than 40 MHz. This issue arises because the regulatory rules in the regd are not updated with these restrictions received from firmware on the maximum bandwidth. Hence, update the regulatory rules with unsupported bandwidth flags based on the maximum bandwidth to ensure compliance with country-specific regulations. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Harshitha Prem <quic_hprem@quicinc.com> Signed-off-by: Amith A <quic_amitajit@quicinc.com> Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com> Link: https://patch.msgid.link/20250701135902.722851-1-quic_amitajit@quicinc.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
2025-07-10net: dsa: rzn1_a5psw: use devm to enable clocksRosen Penev1-18/+4
The remove function has these in the wrong order. The switch should be unregistered last. Simpler to use devm so that the right thing is done. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20250708014144.2514-3-rosenp@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-10net: dsa: rzn1_a5psw: add COMPILE_TESTRosen Penev1-1/+1
There's no architecture specific requirement for it to compile. Allows the bots to test compilation properly. Signed-off-by: Rosen Penev <rosenp@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250708014144.2514-2-rosenp@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-10relayfs: abolish prev_paddingJason Xing2-3/+2
Patch series "relayfs: misc changes", v5. The series mostly focuses on the error counters which helps every user debug their own kernel module. This patch (of 5): prev_padding represents the unused space of certain subbuffer. If the content of a call of relay_write() exceeds the limit of the remainder of this subbuffer, it will skip storing in the rest space and record the start point as buf->prev_padding in relay_switch_subbuf(). Since the buf is a per-cpu big buffer, the point of prev_padding as a global value for the whole buffer instead of a single subbuffer (whose padding info is stored in buf->padding[]) seems meaningless from the real use cases, so we don't bother to record it any more. Link: https://lkml.kernel.org/r/20250612061201.34272-1-kerneljasonxing@gmail.com Link: https://lkml.kernel.org/r/20250612061201.34272-2-kerneljasonxing@gmail.com Signed-off-by: Jason Xing <kernelxing@tencent.com> Reviewed-by: Yushan Zhou <katrinzhou@tencent.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Cc: Jens Axboe <axboe@kernel.dk> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-10net/mlx5e: RX, Remove unnecessary RQT redirectsTariq Toukan1-3/+1
RQTs (Receive Queue Table) should redirect traffic to the channels' RQs when they're active. Otherwise, redirect to the designated "drop RQ". RQTs are created in "inactive" state, pointing to the "drop RQ". In activate and de-activate flows, do not "deactivate" the rest of RQTs (beyond the num of channels), as they are already inactive. This cuts down unnecessary execution of FW commands (MODIFY_RQT), and improves the latency of open/close channels or configuration change. Perf: NIC: Connect-X7. Configuration: 1 combined channel, max num channels 248. Measure time for "interface up + interface down". Before: 0.313 sec After: 0.057 sec (5.5x faster) 247 MODIFY_RQT commands saved in interface up. 247 MODIFY_RQT commands saved in interface down. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1752009387-13300-6-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net/mlx5: Warn when write combining is not supportedMaor Gottlieb1-0/+3
Warn if write combining is not supported, as it can impact latency. Add the warning message to be printed only when the driver actually run the test and detect unsupported state, rather than when inheriting parent's result for SFs. Signed-off-by: Maor Gottlieb <maorg@nvidia.com> Reviewed-by: Michael Guralnik <michaelgur@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1752009387-13300-5-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net/mlx5e: Replace recursive VLAN push handling with an iterative loopGal Pressman1-21/+22
mlx5e_tc_act_vlan_add_push_action() uses tail-recursion to walk through a stack of VLAN devices. There is no need for a complicated recursion with unnecessary stack consumption and less obvious code flow, rewrite the function so that it uses a do while loop instead. Signed-off-by: Gal Pressman <gal@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1752009387-13300-4-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net/mlx5e: CT: extract a memcmp from a spinlock sectionCosmin Ratiu1-1/+4
This reduces the time the lock is held and reduces contention. Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1752009387-13300-3-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net/mlx5e: Remove unused VLAN insertion logic in TX pathCarolina Jubran5-14/+1
The VLAN insertion capability (`wqe_vlan_insert`) was never enabled on all mlx5 devices. When VLAN TX offload is advertised but this capability is not supported, the driver uses inline headers to insert the VLAN tag. To support this, the driver used to set the `MLX5E_SQ_STATE_VLAN_NEED_L2_INLINE` bit to enforce L2 inline mode when `wqe_vlan_insert` was not supported. Since the capability is disabled on all devices, this logic was always active, and the SQ flag has become redundant. L2 inline is enforced unconditionally for VLAN-tagged packets. The `skb_vlan_tag_present()` check in the else-if block of `mlx5e_sq_xmit_wqe()` is never true by this point in the TX flow, as the VLAN tag has already been inserted by the driver using inline headers. As a result, this code is never executed. Remove the redundant SQ state, dead VLAN insertion code block, and related logic. Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/1752009387-13300-2-git-send-email-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net: phy: bcm54811: PHY initializationKamil Horák - 2N1-4/+21
Reset the bit 12 in PHY's LRE Control register upon initialization. According to the datasheet, this bit must be written to zero after every device reset. Signed-off-by: Kamil Horák - 2N <kamilh@axis.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20250708090140.61355-5-kamilh@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net: phy: bcm5481x: MII-Lite activationKamil Horák - 2N1-1/+13
Broadcom PHYs featuring the BroadR-Reach two-wire link mode are usually capable to operate in simplified MII mode, without TXER, RXER, CRS and COL signals as defined for the MII. The absence of COL signal makes half-duplex link modes impossible, however, the BroadR-Reach modes are all full-duplex only. Depending on the IC encapsulation, there exist MII-Lite-only PHYs such as bcm54811 in MLP. The PHY itself is hardware-strapped to select among multiple RGMII and MII-Lite modes, but the MII-Lite mode must be also activated by software. Add MII-Lite activation for bcm5481x PHYs. Signed-off-by: Kamil Horák - 2N <kamilh@axis.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20250708090140.61355-4-kamilh@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net: phy: MII-Lite PHY interface modeKamil Horák - 2N3-0/+6
Some Broadcom PHYs are capable to operate in simplified MII mode, without TXER, RXER, CRS and COL signals as defined for the MII. The MII-Lite mode can be used on most Ethernet controllers with full MII interface by just leaving the input signals (RXER, CRS, COL) inactive. The absence of COL signal makes half-duplex link modes impossible but does not interfere with BroadR-Reach link modes on Broadcom PHYs, because they are all full-duplex only. Add MII-Lite interface mode, especially for Broadcom two-wire PHYs. Signed-off-by: Kamil Horák - 2N <kamilh@axis.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20250708090140.61355-2-kamilh@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net: usb: enable the work after stop usbnet by ip down/upZqiang1-2/+2
Oleksij reported that: The smsc95xx driver fails after one down/up cycle, like this: $ nmcli device set enu1u1 managed no $ p a a 10.10.10.1/24 dev enu1u1 $ ping -c 4 10.10.10.3 $ ip l s dev enu1u1 down $ ip l s dev enu1u1 up $ ping -c 4 10.10.10.3 The second ping does not reach the host. Networking also fails on other interfaces. Enable the work by replacing the disable_work_sync() with cancel_work_sync(). [Jun Miao: completely write the commit changelog] Fixes: 2c04d279e857 ("net: usb: Convert tasklet API to new bottom half workqueue mechanism") Reported-by: Oleksij Rempel <o.rempel@pengutronix.de> Tested-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Zqiang <qiang.zhang@linux.dev> Signed-off-by: Jun Miao <jun.miao@intel.com> Link: https://patch.msgid.link/20250708081653.307815-1-jun.miao@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10gve: make IRQ handlers and page allocation NUMA awareBailey Forrest5-17/+37
All memory in GVE is currently allocated without regard for the NUMA node of the device. Because access to NUMA-local memory access is significantly cheaper than access to a remote node, this change attempts to ensure that page frags used in the RX path, including page pool frags, are allocated on the NUMA node local to the gVNIC device. Note that this attempt is best-effort. If necessary, the driver will still allocate non-local memory, as __GFP_THISNODE is not passed. Descriptor ring allocations are not updated, as dma_alloc_coherent handles that. This change also modifies the IRQ affinity setting to only select CPUs from the node local to the device, preserving the behavior that TX and RX queues of the same index share CPU affinity. Signed-off-by: Bailey Forrest <bcf@google.com> Signed-off-by: Joshua Washington <joshwash@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com> Signed-off-by: Jeroen de Borst <jeroendb@google.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20250707210107.2742029-1-jeroendb@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net: ethernet: ti: am65-cpsw-nuss: Fix skb size by accounting for ↵Chintan Vankar1-3/+1
skb_shared_info While transitioning from netdev_alloc_ip_align() to build_skb(), memory for the "skb_shared_info" member of an "skb" was not allocated. Fix this by allocating "PAGE_SIZE" as the skb length, accounting for the packet length, headroom and tailroom, thereby including the required memory space for skb_shared_info. Fixes: 8acacc40f733 ("net: ethernet: ti: am65-cpsw: Add minimal XDP support") Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com> Signed-off-by: Chintan Vankar <c-vankar@ti.com> Link: https://patch.msgid.link/20250707085201.1898818-1-c-vankar@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net: thunderx: avoid direct MTU assignment after WRITE_ONCE()Alok Tiwari1-9/+3
The current logic in nicvf_change_mtu() writes the new MTU to netdev->mtu using WRITE_ONCE() before verifying if the hardware update succeeds. However on hardware update failure, it attempts to revert to the original MTU using a direct assignment (netdev->mtu = orig_mtu) which violates the intended of WRITE_ONCE protection introduced in commit 1eb2cded45b3 ("net: annotate writes on dev->mtu from ndo_change_mtu()") Additionally, WRITE_ONCE(netdev->mtu, new_mtu) is unnecessarily performed even when the device is not running. Fix this by: Only writing netdev->mtu after successfully updating the hardware. Skipping hardware update when the device is down, and setting MTU directly. Remove unused variable orig_mtu. This ensures that all writes to netdev->mtu are consistent with WRITE_ONCE expectations and avoids unintended state corruption on failure paths. Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Link: https://patch.msgid.link/20250706194327.1369390-1-alok.a.tiwari@oracle.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10virtio-net: xsk: rx: move the xdp->data adjustment to buf_to_xdp()Bui Quang Minh1-2/+9
This commit does not do any functional changes. It moves xdp->data adjustment for buffer other than first buffer to buf_to_xdp() helper so that the xdp_buff adjustment does not scatter over different functions. Signed-off-by: Bui Quang Minh <minhquangbui99@gmail.com> Link: https://patch.msgid.link/20250705075515.34260-1-minhquangbui99@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-07-10net: ngbevf: add link update flowMengyuan Lou1-0/+3
Add link update flow to wangxun 1G virtual functions. Get link status from pf in mbox, and if it is failed then check the vx_status, because vx_status switching is too slow. Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com> Link: https://patch.msgid.link/20250704094923.652-13-mengyuanlou@net-swift.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-11 16:30:54 +0300