summaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)Author
2026-05-26wifi: iwlwifi: mld: fix NAN max channel switch time unitIsrael Kozitz
The max_channel_switch_time in wiphy_nan_capa is in microseconds, but the value was set to 4, which is only 4 microseconds instead of the intended 4 milliseconds. Fix by using 4 * USEC_PER_MSEC. Signed-off-by: Israel Kozitz <israel.kozitz@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260510234534.cb3c05e5d334.I89d9f336aaf388c6e48769de5fe1e5db19295057@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: Do not declare NAN support for Extended Key IDIlan Peer
Do not declare support for Extended Key ID for NAN, as defined in section 7.4 in the WiFi Aware specification v4.0 (in order to support security association upgrade). Signed-off-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260510234534.42f0e92d0ee1.Ic3e47a926539a1d8f20103c40ebe5cfeaf671a96@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: Do not declare support for NDPEIlan Peer
Do not declare support for NAN Data Path Extension attribute as this is handled by user space and should be set by it. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260510234534.a76eb7235116.I160f1232e51711d5e2c063f0e1539ef71db50e1e@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: Fix number of antennas in NAN capabilitiesIlan Peer
Instead of hardcoding the number of supported antennas for Tx/Rx, set them according to hardware capabilities. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Link: https://patch.msgid.link/20260510234534.26f8653d44a3.Ib8b9769e7a598b01f6285bd0782aa3bf13f144a2@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: extract NAN capabilities setting to a functionMiri Korenblit
There are now quite a lot of capabilities to set, so move it to a dedicated function, for better clarity. Link: https://patch.msgid.link/20260510234534.da1f380ced3b.I02013e9d5946a1b3372d2fcd570057fdb4416b65@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: use host rate for NAN management framesMiri Korenblit
Frames that are sent to an NMI station are always NAN management frames. Therefore there is no need to configure TLC for such a station. Always use host rate for the frames going to that station. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.fb7272ddbb45.I843dba36f52363bc7e9c81f937547ead12147539@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: add peer schedule supportJohannes Berg
Add support for NAN peer schedule configuration and update. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260510234534.ede42401c3ee.I8e483edd1e917dfa59901b520db595cea28906e3@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: implement NAN peer station managementJohannes Berg
Implement peer station management for NAN, i.e. support for adding, removing, and updating NMI and NDI stations. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260510234534.cbf6bac4744f.I3bd01266e47f24fb7f1240db62ac3bd47c479127@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: add NAN schedule command supportJohannes Berg
Add the NAN schedule command API definition and implementation of the schedule updates. Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.95fabd44a598.I7cbe877f3b13a44554d95e56b10d930dde4704c9@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: add NAN link managementJohannes Berg
The firmware requires links for NAN which mac80211 doesn't use, so introduce a new NAN link data structure that the driver has for itself only, and handle the link command sending code for NAN using this data structure, most of the bss_conf data isn't used for NAN anyway, so those structures aren't useful. With that, add, activate, deactivate or remove links depending on the local NAN schedule updates. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260510234534.39ee3533ef30.I81ff6dc02e912396040f922e21888fd94b3c26e6@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: support NAN and NAN_DATA interfacesJohannes Berg
Until now we maintained the NAN vif in the driver only. The fw used the AUX MAC for sync and discovery operations. But when we want to configure a local schedule, we need to add the MAC first. NAN_DATA interfaces are not added to the FW. Instead, the local address of these interfaces are configured to the FW via the NAN MAC. Add the add/remove/update operations for the NAN interface, and fill the NAN special parameters in it. Note that this doesn't fully implement the schedule change, but only the addition/removal of the NAN MAC. The full schedule management implementation will come in a later patch. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Co-developed-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20260510234534.dd12944c140b.I3578198660a533faf9f6a94432ef2114f4a9dfae@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: disable queue hang detection for NAN dataJohannes Berg
Since peers on NAN data might just use ULW and/or break the schedule, disable queue hang detection for them. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.9886987db700.Ifd879478bc30af25de0eada6143dbc3e6a548068@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: tlc: separate from link STAJohannes Berg
While NAN stations have the deflink link STA and that even carries their information, having link STAs mostly implies having real links, and NAN muddies that by having stations with deflink carrying their capabilities and links at the NAN level, but no link stations corresponding to NAN links. Separate out the data needed to build TLC commands into a new struct iwl_mld_tlc_sta_capa data structure so that the whole data usage in the TLC code is clarified and we won't make assumptions, say about being able to look up the link of an interface from the (NAN) link sta correctly, which would result in a link but not with a chanctx. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.2c6589aab9db.I01729ec8be4687884831fc8761bf3fd8bba83056@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: set NAN phy capabilitiesMiri Korenblit
Copy the HT, VHT and HE capabilities from the sbands: - The HT capabilities from the 2.4 GHz sband (there is no difference between the bands anyway). - The VHT capabilities from the 5 GHz sband, obviously. - The HE capabilities from the 2.4 GHz and for NL80211_IFTYPE_STATION. Fix it up to include also the needed 5 GHz bits. For HE, there are bits that are band-dependent and iftype-dependent. For those set to what makes most sense, and leave a comment to re-visit. Reviewed-by: Johannes Berg <johannes.berg@intel.com> Link: https://patch.msgid.link/20260510234534.3a5e5251dbaf.I566e1749cd17baa672bdd43712114e434f810a69@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: validate sta_mask before ffs() in BA session handlersJunrui Luo
Three BA session handlers use ffs(ba_data->sta_mask) - 1 to derive a station ID without checking that sta_mask is non-zero. When sta_mask is zero, ffs() returns 0 and the subtraction wraps to 0xFFFFFFFF, causing an out-of-bounds access on fw_id_to_link_sta[]. Add WARN_ON_ONCE(!ba_data->sta_mask) guards before each ffs() call, consistent with the existing check in iwl_mld_ampdu_rx_start(). Reported-by: Yuhao Jiang <danisjiang@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Junrui Luo <moonafterrain@outlook.com> Link: https://patch.msgid.link/SYBPR01MB788115C6CE873271A9A15A25AF51A@SYBPR01MB7881.ausprd01.prod.outlook.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: remove unused header inclusionsJay Ng
Remove header files that are included but provide no symbols, types, or macros used by the including translation unit. In iwl-trans.c, fw/api/tx.h defines TX command structures (iwl_tx_cmd, iwl_tx_resp, TX_CMD_* flags) used by the PCIe TX path, not by the transport core itself. Similarly, iwl-fh.h defines Flow Handler register addresses and DMA-related constants (FH_*, RFH_*, TFD_*) that are consumed by PCIe-specific code, none of which are referenced in iwl-trans.c. In iwl-nvm-parse.c, fw/acpi.h defines ACPI/SAR/GEO/PPAG interfaces (iwl_acpi_*, iwl_sar_*, iwl_geo_*). No references to any of these interfaces exist in this file. Signed-off-by: Jay Ng <jayng9663@gmail.com> Link: https://patch.msgid.link/20260408034413.1875915-1-jayng9663@gmail.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mvm: fix race condition in PTP removalJunjie Cao
iwl_mvm_ptp_remove() calls cancel_delayed_work_sync() only after ptp_clock_unregister() and clearing ptp_data state (ptp_clock, ptp_clock_info, last_gp2). This creates a race where the delayed work iwl_mvm_ptp_work() can execute between ptp_clock_unregister() and cancel_delayed_work_sync(), observing partially cleared PTP state. Move cancel_delayed_work_sync() before ptp_clock_unregister() to ensure the delayed work is fully stopped before any PTP cleanup begins. Cc: stable@vger.kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Junjie Cao <junjie.cao@intel.com> Link: https://patch.msgid.link/20260212125035.1345718-1-junjie.cao@intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26wifi: iwlwifi: mld: fix race condition in PTP removalJunjie Cao
iwl_mld_ptp_remove() calls cancel_delayed_work_sync() only after ptp_clock_unregister() and clearing ptp_data state (ptp_clock, last_gp2, wrap_counter). This creates a race where the delayed work iwl_mld_ptp_work() can execute between ptp_clock_unregister() and cancel_delayed_work_sync(), observing partially cleared PTP state. Move cancel_delayed_work_sync() before ptp_clock_unregister() to ensure the delayed work is fully stopped before any PTP cleanup begins. Cc: stable@vger.kernel.org Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: Junjie Cao <junjie.cao@intel.com> Link: https://patch.msgid.link/20260212125035.1345718-2-junjie.cao@intel.com Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
2026-05-26net: enetc: dynamically allocate rxmsg based on VF countWei Fang
The constant ENETC_MAX_NUM_VFS is defined as 2 when enabling support for LS1028A. This works for LS1028A because its ENETC hardware supports up to 2 VFs. However, ENETC v4 has varying VF capabilities depending on the SoC: i.MX94 standalone ENETC: 0 VFs i.MX94 internal ENETC: 3 VFs i.MX952: 1 VF Using a fixed ENETC_MAX_NUM_VFS for memory allocation leads to over-allocation on SoCs with fewer or no VF support. To better match hardware capabilities and avoid unnecessary memory usage, change rxmsg memory allocation from a fixed-size array to dynamic allocation based on the actual VF count retrieved via pci_sriov_get_totalvfs(). Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-13-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: use MADDR_TYPE for MAC filter array sizeWei Fang
The mac_filter array in struct enetc_pf is sized as ENETC_MAX_NUM_MAC_FLT, defined as (ENETC_MAX_NUM_VFS + 1) * MADDR_TYPE. This resulted in an array of 6 elements (for 2 VFs), but only the first 2 entries are actually used. The PF driver maintains MAC filters for unicast (UC) and multicast (MC) addresses, indexed by the enum enetc_mac_addr_type (UC=0, MC=1). The code only iterates over MADDR_TYPE (2) entries and directly accesses mac_filter[UC] and mac_filter[MC]. The extra space allocated for (ENETC_MAX_NUM_VFS * MADDR_TYPE) entries is never used because VF MAC filtering is not implemented yet. Remove the ENETC_MAX_NUM_MAC_FLT macro and size the array as MADDR_TYPE, reducing the allocation from 6 to 2 entries. This saves 48 bytes per PF and better reflects the actual usage. This change has no functional impact. Future VF MAC filtering support will move mac_filter into struct enetc_si, allowing each SI (PF or VF) to maintain its own independent filter table. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-12-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: add generic helper to initialize SR-IOV resourcesWei Fang
The upcoming ENETC v4 PF driver will support SR-IOV, and its logic for initializing VF resources is identical to the existing ENETC v1 PF implementation. To avoid code duplication across PF drivers, factor out the common SR-IOV initialization logic into the enetc-pf-common driver. Add enetc_init_sriov_resources() to handle: - Querying the total number of VFs supported by the device via pci_sriov_get_totalvfs() - Allocating memory for the VF state array (struct enetc_vf_state) The implementation uses devm_kcalloc() instead of kzalloc() to simplify memory management. This automatically frees VF state memory when the PF device is removed, eliminating the need for explicit cleanup in error and remove paths. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-11-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: add CBDR setup/teardown hooks to enetc_si_ops for VF supportWei Fang
The upcoming ENETC v4 VF will share the enetc-vf driver with the existing v1 VF. However, ENETC v4 uses a revised CBDR (command BD ring) setup/teardown API that differs from v1. To support both versions in the same driver, add setup_cbdr() and teardown_cbdr() function pointers to struct enetc_si_ops. This allows each hardware version to register its own CBDR implementation: - ENETC v1 VF registers enetc_setup_cbdr/enetc_teardown_cbdr (existing) - ENETC v4 VF will register enetc4_setup_cbdr/enetc4_teardown_cbdr Update the enetc-vf driver to call CBDR operations through si->ops instead of directly invoking the v1 functions. This enables runtime selection of the correct CBDR backend based on hardware version. Changes: - Add setup_cbdr() and teardown_cbdr() hooks to struct enetc_si_ops - Register v1 CBDR functions in enetc_vsi_ops - Replace direct calls with si->ops->setup_cbdr() and si->ops->teardown_cbdr() in enetc_vf.c No functional changes to existing v1 VF behavior. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-10-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: align v1 CBDR API with v4 for VF driver sharingWei Fang
The upcoming ENETC v4 VF will share the enetc-vf driver with the v1 VF. However, ENETC v4 introduces different CBDR (command BD ring) setup and teardown semantics that are incompatible with v1. To support both versions in the same driver, the .setup_cbdr() and .teardown_cbdr() hooks will be added to struct enetc_si_ops, allowing the driver to register version-specific implementations. So refactor the v1 CBDR functions to match the v4-style interface (taking struct enetc_si* instead of individual parameters), enabling them to be registered via si_ops in the subsequent patch. Changes: - Update enetc_setup_cbdr() and enetc_teardown_cbdr() prototypes to take 'struct enetc_si *' as the sole parameter - Extract parameters (dev, hw) from the enetc_si structure within the function implementations - ENETC_CBDR_DEFAULT_SIZE has always been used as the number of command BDs, and there is no need to adjust the size of the command BD ring. Therefore, ENETC_CBDR_DEFAULT_SIZE is moved into the enetc_setup_cbdr() - Update all call sites in enetc_pf.c and enetc_vf.c No functional changes. This prepares for adding v4-specific CBDR handling in subsequent patches. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-9-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: add VF-PF messaging support for IP minor revision queryWei Fang
For ENETC v4, different SoCs use different minor revisions, such as i.MX95 v4.1, i.MX94 v4.3, and i.MX952 v4.6. Unlike the PF, the VF does not have access to a global register that exposes the IP minor revision. In the current driver model, the VF must select the appropriate driver data based on this revision information. To support this requirement, the VF now sends a minor revision query message to the PF through the VSI-to-PSI mailbox mechanism. The PF responds with the IP minor revision so that the VF can match the correct driver data. This patch adds PF-side support for replying to the minor revision message and VF-side support for sending the query. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-8-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: convert mailbox messages to new formatsWei Fang
On the LS1028A platform, the PF-VF mailbox was only used to update the VF's MAC address. The original message format is minimal, lacks a clear structure, and provides no means for the receiver to validate message integrity, making it difficult to extend for new features. With the introduction of i.MX ENETC v4, the interaction between PF and VF has become significantly more complex. Typical deployments now include scenarios where the PF is controlled by an M core while the VF is driven by either the Linux kernel or DPDK, or where the PF is controlled by the Linux kernel while the VF is controlled by DPDK. These heterogeneous driver combinations require a unified and extensible message format to ensure compatibility across different operating environments. This patch introduces a newly defined PF-VF message structure and converts the existing MAC-update mechanism to use the new format. The redesigned message layout provides: - extensibility to support future PF-VF features on ENETC v4, - consistent framing for all message types, - improved data integrity checking, - a common protocol usable across Linux, M core firmware, and DPDK. Additional PF-VF message types will be added in subsequent patches. Note that switch to the new message format will not affect ENETC v1 (LS1028A). Due to a hardware limitation of ENETC v1, the ENETC PF and VFs can only be controlled by the same OS. If the PF is controlled by the Linux kernel driver, then the VFs must also be controlled by the Linux kernel driver. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-7-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: use read_poll_timeout() for VF mailbox pollingWei Fang
Replace the manual do-while polling loop in enetc_msg_vsi_send() with the standard read_poll_timeout() helper to simplify the code. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-6-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: integrate enetc_msg.c into enetc-pf-common driverWei Fang
Move enetc_msg.c from the fsl-enetc driver to the nxp-enetc-pf-common driver so that SR-IOV mailbox handling can be shared between ENETC v1 and v4 PF drivers. Changes: - Move enetc_msg.o compilation from fsl-enetc to nxp-enetc-pf-common - Export enetc_sriov_configure() with EXPORT_SYMBOL_GPL for use by both PF drivers The fsl-enetc driver now depends on nxp-enetc-pf-common for SR-IOV functionality. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-5-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: relocate SR-IOV configuration helper for common PF supportWei Fang
Move enetc_sriov_configure() from enetc_pf.c to enetc_msg.c to prepare for integrating enetc_msg.c into the enetc-pf-common driver, where it will be shared between ENETC v1 and v4 PF drivers. Since enetc_msg_psi_init() and enetc_msg_psi_free() are now only called from enetc_sriov_configure() within the same file, make them static. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-4-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: move VF message handlers to enetc_msg.cWei Fang
Move enetc_msg_pf_set_vf_primary_mac_addr() and enetc_msg_handle_rxmsg() to enetc_msg.c to consolidate VF mailbox message handling logic. Make enetc_msg_handle_rxmsg() static since it's only called from enetc_msg_task() within the same file. This prepares for integrating enetc_msg.c into the enetc-pf-common driver to be shared between ENETC v1 and v4 PF drivers. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-3-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: enetc: use enetc_set_si_hw_addr() for setting MAC addressWei Fang
Replace enetc_pf_set_primary_mac_addr() with the generic enetc_set_si_hw_addr() function. This prepares for moving enetc_msg_pf_set_vf_primary_mac_addr() to the enetc-pf-common driver, where it can be shared between ENETC v1 and v4 PF drivers. Signed-off-by: Wei Fang <wei.fang@nxp.com> Link: https://patch.msgid.link/20260522092438.1264020-2-wei.fang@nxp.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26mv88e6xxx: Remove locks for 6352's has_serdesFidan Aliyeva
There is no register access anymore in mv88e6352_g2_scratch_port_has_serdes. So, remove the locks surrounding the function. Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Link: https://patch.msgid.link/20260521202924.727929-5-fidan.aliyeva.ext@ericsson.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26mv88e6xxx: Use cached config3 in 6352 has_serdesFidan Aliyeva
1. Refactor mv88e6352_g2_scratch_port_has_serdes to use the cached scratch config3 value instead of reading it everytime. 2. Remove err<0 check from mv88e6352_phylink_get_caps as it is never true anymore Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Link: https://patch.msgid.link/20260521202924.727929-4-fidan.aliyeva.ext@ericsson.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26mv88e6xxx: Cache scratch config3 of 6352Fidan Aliyeva
Changes: 1. Add g2_scratch_config3 member to mv88e6xxx_chip. 2. Add mv88e6352_g2_cache_global_scratch_config3 which reads the CONFIG3 value from the scratch register and caches it. 3. Call this function in mv88e6352_reset. Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Link: https://patch.msgid.link/20260521202924.727929-3-fidan.aliyeva.ext@ericsson.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26mv88e6xxx: Add mv88e6352_reset for 6352 familyFidan Aliyeva
1. Add mv88e6352_reset which calls the previous ops->reset function - mv88e6352_g1_reset. 2. Make all 6352 family use this new function as ops->reset Co-developed-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Thomas Eckerman <thomas.eckerman.ext@ericsson.com> Signed-off-by: Fidan Aliyeva <fidan.aliyeva.ext@ericsson.com> Link: https://patch.msgid.link/20260521202924.727929-2-fidan.aliyeva.ext@ericsson.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: mdio: realtek-rtl9300: Link I/O functions in info structureMarkus Stockhausen
The MDIO controller registers of the different devices of the Realtek Otto switch series are very similar. Nevertheless each device will need to feed the whole command data distributed over the controller registers slightly different. E.g. the combined C22/command register has different field layouts. On RTL930x bits 24-20 define the to-be-accessed C22 register number while on RTL839x this is stored in bits 9-5. Thus there need to be device specific read/write functions that are called dynamically. Add them into the info structure and make use of them where needed. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260521175918.1494797-10-markus.stockhausen@gmx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: mdio: realtek-rtl9300: Add port mask registerMarkus Stockhausen
MDIO controller commands work on ports. These are converted by the driver and hardware forth and back to bus/address. For write commands a port mask register needs to be filled. Each bit tells the controller to which PHY the write will be issued. Setting multiple bits allows to program multiple PHYs in one step. The driver will not make use of this parallel write feature. But it must at least fill the bit of the target port that it wants to write to. Depending on the SOC type and the number of supported PHYs this is either one or two 32 bit port mask registers. The driver currently only supports the 28 port RTL930x SOCs. So provide only the mask register for the lower 32 ports. Add it to the register structure and make use of it where needed. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260521175918.1494797-9-markus.stockhausen@gmx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: mdio: realtek-rtl9300: Add I/O registerMarkus Stockhausen
The MDIO data that needs to be written or read to registers of the controller is handled by an I/O register. Add that to the register structure and make use of it where needed. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260521175918.1494797-8-markus.stockhausen@gmx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: mdio: realtek-rtl9300: Add command/C22 registerMarkus Stockhausen
Command issuing/status bits and C22 data share the same register. In the future the number of places where this register is used will be: - One generic command helper/runner for all devices that will access the command bits of the register - 8 device specific C22 read/write functions that will access the C22 data fields. Thus name the register c22_data to align with the existing c45_data register. This way all device specific helpers will have a common view on the to-be-fed data. Add the register to the existing structure and make use of it where needed. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260521175918.1494797-7-markus.stockhausen@gmx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: mdio: realtek-rtl9300: Add register structureMarkus Stockhausen
The MDIO controller of the Realtek Otto switches has either 4 or 7 command registers. This depends on the number of supported ports. These registers are "scattered" around the MMIO block and their addresses depend on the specific model. Nevertheless all command registers share a common pattern: - A mask register with one bit per addressed port (remark: the driver internally works on ports instead of bus/address) - A I/O data register that transfers the to be read/written data - A C45 registers that takes devnum and regnum - A C22 register that also includes run and status bits (remark: this also takes the Realtek proprietary C22 PHY page) Provide an additional structure for these command registers so it can be reused in two places. 1. For defining the register addresses in the regmap. 2. For defining the to be read/written register data This will finally result in access patterns like static int otto_emdio_run_cmd(u32 cmd, struct rtl_mdio_cmd_regs *cmd_regs, ...) { regmap_write(regmap, priv->info->reg->cmd_regs.c45_data, cmd_regs->c45_data); ... } static int otto_emdio_9300_write_c45(...) { struct otto_emdio_cmd_regs cmd_regs = { .c45_data = ... .io_data = ..., .port_mask = ..., }; return otto_emdio_run_cmd(RTL9300_CMD_WRITE_C45, &cmd_regs, ...); } As a first step start with the C45 register. This one takes the devnum/regnum data that is stored in the high/low 16 bits. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260521175918.1494797-6-markus.stockhausen@gmx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: mdio: realtek-rtl9300: Add pages to info structureMarkus Stockhausen
The Realtek ethernet MDIO controller has a proprietary paging feature that is closely aligned with Realtek based PHYs. These PHY know "pages" for C22 access. Those can be switched via reads/writes to register 31. Usually the paged access must be programmed in four steps. 1. read/save page register 2. change "page" register 31 3. read/write data register (on the given page) 4. restore page register The controller can run all this in hardware with one single request from the driver. It is given the page, the register and the data and takes care of all the rest. This reduces CPU load. The number of supported pages depend on the model. This is either 4096 for low port count SOCs (up to 28 ports) or 8192 for high port count SOCs (up to 56 ports). There is however one special page that allows to pass through all C22 commands directly to the PHY - without any caching. This so called raw page is dependent of the hardware. It is the highest supported page number minus 1. Provide the number of supported pages as a device specific property. This new "num_pages" aligns with the existing properties and gives an better insight into the hardware layout than just defining the number of the raw page. The later directly derives from that and can be accessed with the new RAW_PAGE() macro. Make use of it where needed. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260521175918.1494797-5-markus.stockhausen@gmx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: mdio: realtek-rtl9300: Add ports to info structureMarkus Stockhausen
The ethernet MDIO controller in the Realtek Otto series has a very special command register style. Instead of working with bus/address it works on ethernet port numbers. For this the controller is initialized via mapping registers that tell which port is mapped to which bus/address. Every request to the driver is then converted as follows 1. Kernel calls driver with bus/address 2. Driver converts bus/address to port and issues command 3. Hardware maps port back to bus/address The number of ports is different for each device. Make this configurable by adding a property to the info structure. Switch the existing usage of MAX_PORTS to this new property where needed. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260521175918.1494797-4-markus.stockhausen@gmx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: mdio: realtek-rtl9300: Add device specific info structureMarkus Stockhausen
Device properties of the RTL930x SOCs are hardcoded into the MDIO driver. This must be relaxed to support additional devices like the RTL838x or RTL839x. These do not have 4 SMI buses but 1 or 2 instead. To support multiple devices establish an info structure that contains individual variations of each series. As a first use case add the number of buses into this structure and use it where needed. Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260521175918.1494797-3-markus.stockhausen@gmx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: mdio: realtek-rtl9300: enhance documentation & namingMarkus Stockhausen
The Realtek ethernet MDIO driver currently only serves SOCs from the Realtek RTL930x series. This is only one lineup of the Realtek Otto switch series that also knows RTL838x, RTL839x, RTL931x devices. All of these share similar hardware with comparable MMIO access logic but have individual variations. Important to note - Controller works on switch ports instead of buses and addresses. - Devices incorporate additional MDIO hardware. E.g. - an auxiliary MDIO controller for GPIO expanders [1] - a MDIO style SerDes controller [2] To avoid future confusion enhance the driver documentation and function naming. Make clear what this driver is about and what parts are generic and what parts are device specific. For this rename the function and structure prefix as follows: - for generic functions use otto_emdio_ - for device specific helpers use e.g. otto_emdio_9300_ This prefix naming tries to align with the watchdog timer [3]. It paves the way so that drivers for the other Realtek Otto MDIO controllers can be added in future commits using the same naming convention. Remark 1: The read/write functions are kept device specific for now because they will only fit the RTL930x SOCs. Renaming will take place as soon as the I/O handling will be generalized. Remark 2: The driver name "mdio-rtl9300" is kept for now. [1] https://git.openwrt.org/openwrt/openwrt/tree/target/linux/realtek/patches-6.18/723-net-mdio-Add-Realtek-Otto-auxiliary-controller.patch [2] https://git.openwrt.org/openwrt/openwrt/tree/target/linux/realtek/files-6.18/drivers/net/mdio/mdio-realtek-otto-serdes.c [3] https://elixir.bootlin.com/linux/v7.0/source/drivers/watchdog/realtek_otto_wdt.c Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de> Link: https://patch.msgid.link/20260521175918.1494797-2-markus.stockhausen@gmx.de Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-26net: team: fix NULL pointer dereference in team_xmit during mode changeWeiming Shi
__team_change_mode() clears team->ops with memset() before restoring safe dummy handlers via team_adjust_ops(). A concurrent team_xmit() running under RCU on another CPU can read team->ops.transmit during this window and call a NULL function pointer, crashing the kernel. The race requires a mode change (CAP_NET_ADMIN) concurrent with transmit on the team device. BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Call Trace: team_xmit (drivers/net/team/team_core.c:1853) dev_hard_start_xmit (net/core/dev.c:3904) __dev_queue_xmit (net/core/dev.c:4871) packet_sendmsg (net/packet/af_packet.c:3109) __sys_sendto (net/socket.c:2265) The original code assumed that no ports means no traffic, so mode changes could freely memset()/memcpy() the ops. AF_PACKET with forced carrier breaks that assumption. Prevent the race instead of making it safe: replace memset()/memcpy() with per-field updates that never touch transmit or receive. Those two handlers are managed solely by team_adjust_ops(), which already installs dummies when tx_en_port_count == 0 (always true during mode change since no ports are present). WRITE_ONCE/READ_ONCE prevent store/load tearing on the handler pointers. synchronize_net() before exit_op() drains in-flight readers that may still reference old mode state from before port removal switched the handlers to dummies. Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://patch.msgid.link/20260521081159.1491563-3-bestswngs@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-25eth: dpaa2: constify dpaa2_ethtool_stats and dpaa2_ethtool_extrasLen Bao
The 'dpaa2_ethtool_stats' and 'dpaa2_ethtool_extras' structures are initialized in their declarations and never changed. So, constify them to reduce the attack surface. Before the patch (size dpaa2-ethtool.o): text data bss dec hex 33433 5992 0 39425 9a01 After the patch (size dpaa2-ethtool.o): text data bss dec hex 34937 4488 0 39425 9a01 Signed-off-by: Len Bao <len.bao@gmx.us> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com> Link: https://patch.msgid.link/20260523150737.36988-1-len.bao@gmx.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-25net: ibm: emac: Use napi_gro_receive() for Rx packetsRosen Penev
emac_poll_rx() already runs in NAPI context and TAH-equipped EMACs set CHECKSUM_UNNECESSARY on verified frames, which lets GRO coalesce TCP segments without a software checksum on the merge path. Replace the per-poll rx_list batched with netif_receive_skb_list() with direct napi_gro_receive() calls so the stack can merge segments into super-skbs and skip a full traversal per packet -- a meaningful win on the slow 4xx-class CPUs this driver targets. Small routing speed improvement tested on a Cisco Meraki MX60W: Tested with iperf3 Before: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 494 MBytes 414 Mbits/sec 839 sender [ 5] 0.00-10.04 sec 492 MBytes 411 Mbits/sec receiver After: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 510 MBytes 428 Mbits/sec 580 sender [ 5] 0.00-10.04 sec 508 MBytes 424 Mbits/sec receiver Traffic to and from the router seems to be slow no matter what: Tested with iperf3 --bidir Before: [ ID][Role] Interval Transfer Bitrate Retr [ 8][TX-C] 0.00-10.00 sec 297 MBytes 249 Mbits/sec 35 sender [ 8][TX-C] 0.00-10.00 sec 293 MBytes 245 Mbits/sec receiver [ 10][RX-C] 0.00-10.00 sec 184 MBytes 154 Mbits/sec 0 sender [ 10][RX-C] 0.00-10.00 sec 184 MBytes 154 Mbits/sec receiver After: [ ID][Role] Interval Transfer Bitrate Retr [ 8][TX-C] 0.00-10.00 sec 295 MBytes 248 Mbits/sec 31 sender [ 8][TX-C] 0.00-10.00 sec 294 MBytes 246 Mbits/sec receiver [ 10][RX-C] 0.00-10.00 sec 181 MBytes 152 Mbits/sec 0 sender [ 10][RX-C] 0.00-10.00 sec 181 MBytes 152 Mbits/sec receiver Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20260521215908.257118-1-rosenp@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-25devlink: pass param values by pointerRatheesh Kannoth
union devlink_param_value grows substantially once U64 array parameters are added to devlink (from 32 bytes to over 264 bytes). devlink_nl_param_value_fill_one() and devlink_nl_param_value_put() copy the union by value in several places. Passing two instances as value arguments alone consumes over 528 bytes of stack; combined with deeper call chains the parameter stack can approach 800 bytes and trip CONFIG_FRAME_WARN more easily. Switch internal helpers and exported driver APIs to pass pointers to union devlink_param_value rather than passing the union by value. Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Acked-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Arthur Kiyanovski <akiyano@amazon.com> #for ena Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260521095303.2395584-4-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-25net/mlx5e: Reduce stack use reading PCIe congestion thresholdsRatheesh Kannoth
union devlink_param_value grew when U64 array parameters were added. Keeping union devlink_param_value val[4] in mlx5e_pcie_cong_get_thresh_config() exceeded the compiler's -Wframe-larger-than limit. Reuse one union: call devl_param_driverinit_value_get() once per MLX5 PCIe congestion threshold and assign each vu16 to the corresponding mlx5e_pcie_cong_thresh member. Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com> Link: https://patch.msgid.link/20260521095303.2395584-3-rkannoth@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-25net/mlx5: Add SPF function type for page managementMoshe Shemesh
Add MLX5_SPF to enum mlx5_func_type so SPFs get their own page counter, and add the corresponding WARN check at page cleanup. Wait for SPF pages to be reclaimed during ECPF teardown, alongside the existing host PF and VF page waits. SPF page requests are always identified by vhca_id, so the legacy func_id_to_type() path is not reached for satellite PFs. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260521110843.367329-13-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-25net/mlx5: Add FDB peer miss rules for satellite PFsMoshe Shemesh
Add satellite PF (SPF) vports to the FDB peer miss rules flow. Introduce mlx5_esw_for_each_spf_vport() macro to iterate SPF vports. Signed-off-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260521110843.367329-12-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-22 05:27:44 +0000