As correctly pointed out by Jay Vosburgh,
"This comment dates to sometime before git, when it was common for
network device drivers to lack the ability to change the MAC while the
interface is up. To the best of my knowledge, that isn't a issue
today."
Based on the discussion in the RFC linked below, I am removing the
TODO.
Link to the RFC:
https://lore.kernel.org/netdev/2001256.1782860341@famine/T/#t
Signed-off-by: Paritosh Potukuchi <paritosh.potukuchi@amd.com>
Link: https://patch.msgid.link/20260703125513.694324-1-paritosh.potukuchi@amd.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
<linux/mdio.h> itself doesn't use any of the device id structures. The
files #including <linux/mdio.h> use a variety of them:
$ git grep -l '<linux/mdio.h>' | xargs grep --color -E '\<(acpi_device_id|amba_id|ap_device_id|apr_device_id|auxiliary_device_id|bcma_device_id|ccw_device_id|cdx_device_id|coreboot_device_id|css_device_id|dfl_device_id|dmi_(device|system)_id|eisa_device_id|fsl_mc_device_id|hda_device_id|hid_device_id|hv_vmbus_device_id|i2c_device_id|i3c_device_id|ieee1394_device_id|input_device_id|ipack_device_id|isapnp_device_id|ishtp_device_id|mcb_device_id|mdio_device_id|mei_cl_device_id|mhi_device_id|mips_cdmm_device_id|of_device_id|parisc_device_id|pci_device_id|pci_epf_device_id|pcmcia_device_id|platform_device_id|pnp_(card_)?device_id|rio_device_id|rpmsg_device_id|sdio_device_id|sdw_device_id|serio_device_id|slim_device_id|spi_device_id|spmi_device_id|ssam_device_id|ssb_device_id|tb_service_id|tee_client_device_id|typec_device_id|ulpi_device_id|usb_device_id|vchiq_device_id|virtio_device_id|wmi_device_id|x86_(cpu|device)_id|zorro_device_id|cpu_feature)\>'
...
but none of them relies on <linux/mdio.h>'s #include.
<linux/mod_devicetable.h> is a bad header mixing many different device
id structures and thus is an unfortunate dependency because if e.g.
struct wmi_device_id is modified all users of <linux/mdio.h> need to be
recompiled despite none of them using struct wmi_device_id.
So drop the unused header.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/ca270a534d0f230a939a3fb4a661808b35d6436d.1783329817.git.u.kleine-koenig@baylibre.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add Static and Dynamic Interrupt Moderation (DIM) support for
Rx and Tx.
Update queue creation procedure with new data struct with the related
settings.
Add functions to collect stat for DIM, and workers to update DIM data
and settings.
Update ethtool handler to get/set the moderation settings from a user.
To avoid detach/re-attach ops, ring DIM doorbell to change settings
at run time.
By default, adaptive-rx/tx (DIM) are enabled if supported by HW.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260702220123.815018-1-haiyangz@linux.microsoft.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2026-07-01 (igc, igb)
Kohei Enju adds ethtool support for get/set hash key on igc and adds
setting of skb hash type based on values from Rx descriptor on igb.
Takashi Kozu adds ethtool support for get/set hash key on igb.
Faizal adds support for forcing link speed via ethtool when
autonegotiation is disabled on the igc driver.
* '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
igc: add support for forcing link speed without autonegotiation
igc: replace goto out with direct returns in igc_config_fc_after_link_up()
igc: move autoneg-enabled settings into igc_handle_autoneg_enabled()
igc: remove unused autoneg_failed field
igb: set skb hash type from RSS_TYPE
igb: allow configuring RSS key via ethtool set_rxfh
igb: expose RSS key via ethtool get_rxfh
igb: prepare for RSS key get/set support
igc: allow configuring RSS key via ethtool set_rxfh
igc: expose RSS key via ethtool get_rxfh
igc: prepare for RSS key get/set support
====================
Link: https://patch.msgid.link/20260701210303.1745310-1-anthony.l.nguyen@intel.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The bytes_sent and bytes_rcvd members of structs asyncppp and syncppp
are not used. Drop them.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Link: https://patch.msgid.link/20260702060420.95023-1-jirislaby@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Nimrod Oren says:
====================
selftests: drv-net: run XDP tests with both IP versions
The driver selftest environment picks a single address family for tests
which use the generic address fields. When both IPv4 and IPv6 are
available it prefers IPv6, which can leave IPv4 paths untested and hide
IPv4-only bugs.
This happened recently in the XDP selftest, where an IPv4 checksum bug
was missed when IPv6 was also configured. XDP traffic handling has
IP-version-specific code paths, and the follow-up discussion concluded
that the XDP tests should run against both IP versions [1].
This series changes NetDrvEpEnv from exposing only the initially selected
address family to allowing tests to switch the generic address fields
between IP versions. xdp.py uses this to run the XDP traffic cases over
both IPv4 and IPv6. Test variants whose required IP version is not
configured are skipped.
[1] https://lore.kernel.org/20260518143138.74839bf9@kernel.org/
====================
Link: https://patch.msgid.link/20260702062348.2123960-1-noren@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Parameterize test cases by IP version using @ksft_variants. Set the
environment's IP version at the start of each case using a new local
helper, which also handles restoring the original value via defer().
The last case is left unparameterized because it does not send traffic
or exercise IP-version-specific code.
While here, fix an int vs str comparison bug `if cfg.addr_ipver == 4`.
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Nimrod Oren <noren@nvidia.com>
Link: https://patch.msgid.link/20260702062348.2123960-3-noren@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
NetDrvEpEnv picks a single IP version at init time, preferring IPv6 when
both are configured.
Add NetDrvEpEnv.set_ipver() to reselect the IP version and recompute the
derived address fields.
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Nimrod Oren <noren@nvidia.com>
Link: https://patch.msgid.link/20260702062348.2123960-2-noren@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Tariq Toukan says:
====================
devlink: extend phys_port_name controller prefix to non-external ports
This series by Moshe includes the controller number in phys_port_name
for non-external ports with a non-zero controller, and updates the mlx5
driver to mark satellite PFs as non-external.
The controller prefix (c) in phys_port_name was previously only included
for ports marked as external. However, newer devices can have multiple
controllers within the DPU itself, even within a single host
environment. For example, a SmartNIC may have additional local PCI
physical functions that are managed by the eswitch but are not on an
external host. These ports use a non-zero controller number to
distinguish them from the eswitch manager's own functions, while the
external flag remains unset.
Patch 1 updates the devlink core to include the controller prefix in
phys_port_name for any non-zero controller, regardless of the external
flag. Documentation and kdoc are updated accordingly.
Patch 2 updates the mlx5 driver to set satellite PF devlink ports as
non-external, since they are local to the DPU. It also distinguishes
satellite PF SFs from host PF SFs when setting the external attribute.
====================
Link: https://patch.msgid.link/20260702111726.816985-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Satellite PFs are local to the DPU and are not on an external host.
Set their devlink port external attribute to false to reflect this.
For satellite PF SFs, distinguish them from host PF SFs by comparing
the SF controller number against the host PF controller
(hpf_host_number + 1). Only SFs whose controller matches the host PF
are marked external, since their PF resides on an external host.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260702111726.816985-3-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The controller prefix (c<N>) in phys_port_name is currently restricted
to external host controllers. This layout sufficed when DPUs only had a
single local controller and one or more external host controllers.
However, newer devices can have multiple controllers within the DPU
itself, even within a single host environment. To support these
topologies, allow drivers to report the controller number regardless of
the "external" flag status. Any non-zero controller number will now be
explicitly reported, even for single-host or local DPU controllers.
Existing ports with controller=0 are unaffected.
Update documentation and kdoc to clarify that a non-zero controller
number does not require the external flag to be set.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260702111726.816985-2-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Bastien Curutchet says:
====================
net: dsa: microchip: move non-common function out of ksz_common.c
This series continues the rework of the KSZ driver initiated by three
previous series (see [1], [2] & [3]).
The KSZ driver handles more than 20 switches split in several families.
This was previously handled through a common set of dsa_switch_ops
operations that used device-specific ksz_dev_ops callbacks. The three
previous series have split this common struct dsa_switch_ops into 5
to connect the ksz_dev_ops's implentations directly to the new
dsa_swicth ops.
This series continues in the same vein and moves out of ksz_common.c all
the functions that aren't truly common to all the families.
On top of this on-going rework I added PTP and periodic output support for
the KSZ8463 (which was my first goal). There are still more than 13 patches
left for all this so this series will be followed by two others and if you
want to see the full picture we can check my github ([4]).
FYI, I only have a KSZ8463 so, unfortunately, I can't test other switches.
The next series is going to add PTP support for the KSZ8463. The final one
will add periodic output support for the KSZ8463.
[1]: https://lore.kernel.org/r/20260505-clean-ksz-driver-v1-0-05d70fa42461@bootlin.com
[2]: https://lore.kernel.org/r/20260521-clean-ksz-2nd-series-v3-0-75c38971c19a@bootlin.com
[3]: https://lore.kernel.org/r/20260608-clean-ksz-3rd-v2-0-6e61b7be23c4@bootlin.com
[4]: https://github.com/bastien-curutchet/linux/tree/ksz_rework
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
====================
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-0-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The drive strength configuration is done during the setup of all
switches through a common function that then has specific behavior
depending on the switch identity.
Split the common configuration in two functions: one is dedicated to the
KSZ8 family, the other is dedicated to the KSZ9477 family.
Remove the drive strength configuration from the lan937x_setup since
the LAN937x family doesn't support it.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-10-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ksz9477_drive_strength_write() isn't used for the KSZ9477-family only.
It's also used for the KSZ87xx chip variants. This function name is
misleading.
Rename it ksz_drive_strength_write().
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-9-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ksz9477_set_default_prio_queue_mapping() dictates a KSZ9477-specific
behavior but is defined in the common section of the code.
Move its definition to the KSZ9477-specific area.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-8-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The setup of QDISC_ETS isn't the same for the KSZ8 switches than for
the other switches. It leads to is_ksz8() branches in the common code.
Move the KSZ8-specific portions into ksz8.c by creating two setup_tc()
functions, one dedicated to the KSZ87xx family that only handles the
TC_SETUP_QDISC_CBS case, one for the rest of the KSZ8 that handles both
TC_SETUP_QDISC_CBS and TC_SETUP_QDISC_ETS cases.
It remains some is_kszXXXX() branches because inside the ksz88xx family,
only the ksz88x3 switches support QDISC_ETS.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-7-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The KSZ9477 PHY errata is handled from the common ksz_r_mib_stat64().
This errata clearly belongs to the KSZ9477 family so it should be handled
from the ksz9477-specific portion of the driver.
Create a ksz9477-specific r_mib_stat64() implementation that handles
this errata.
Remove the errata handling from the common ksz_r_mib_stat64().
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-6-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ksz_get_gbit() and ksz_get_xmii() are defined in the ksz_common while
they are only used by the ksz9477 driver.
Move their definition into ksz9477.c
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-5-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ksz88xx_r_mib_stats64() is defined in ksz_common while it's clearly
ksz88xx-specific.
Move its definition in ksz8.c
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-4-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ksz_is_port_mac_global_usable() is exposed in ksz_common.h while it's
only used internally.
Make ksz_is_port_mac_global_usable() static.
Move its definition above its first call.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-3-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ksz_max_mtu() is a bit cluttered. It would be good for developers and
reviewers if they didn't need to look at a common function for hardware
they likely don't have, and which is vastly different, when they are
interested in only a specific chip.
Benefit from the fact that all families listed here have their own
dsa_switch_ops, and provide separate implementations for the
port_max_mtu() method.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-2-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Even among the ksz8 family, there are big differences in the MTU change
procedure between KSZ87xx and KSZ88xx (KSZ8463 is like KSZ88xx here).
Since we have 3 separate dsa_switch_ops for what constitutes "KSZ8", we
can split those procedures into separate functions.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260702-clean-ksz-4th-v1-1-93441e695fa4@bootlin.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Mike Rapoport says:
====================
drivers/net/ethernet: replace __get_free_pages() with kmalloc()
This is a (small) part of larger work of replacing page allocator calls
with kmalloc.
My initial intention a few month ago was to remove ugly casts [1], but then
willy pointed out that Linus objected to something like this [2] and it
looks like more than a decade old technical debt.
Largely, anything that doesn't need struct page (or a memdesc in the
future) should just use kmalloc() or kvmalloc() to allocate memory.
kmalloc() guarantees alignment, physical contiguity and working
virt_to_phys() and beside nicer API that returns void * on alloc and
doesn't require to know the allocation size on free, kmalloc() provides
better debugging capabilities than page allocator.
Another thing is that touching these allocation sites gives the reviewers
opportunity to see if a PAGE_SIZE buffer is actually needed or maybe
another size is appropriate.
For larger allocations that don't need physically contiguous memory
kvmalloc() can be a better option that __get_free_pages() because under
memory pressure it's is easier to allocate several order-0 pages than a
physically contiguous chunk with the same number of pages.
And last, but not least, removing needless calls to page allocator should
help with memdesc (aka project folio) conversion. There will be way less
places to audit to see if the user was actually using struct page.
Also in git:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git gfp-to-kmalloc/drivers-net-ethernet
[1] https://lore.kernel.org/all/20251018093002.3660549-1-rppt@kernel.org/
[2] https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/
====================
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-0-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
efx_mcdi_init() allocates a logging buffer for MCDI firmware
communication diagnostics.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-4-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
efx_siena_mcdi_init() allocates a logging buffer for MCDI firmware
communication diagnostics.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Edward Cree <ecree.xilinx@gmail.com>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-3-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
ice_gnss_read() uses get_zeroed_page() to allocate a staging buffer for
reading GNSS module data via I2C bus.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of get_zeroed_page() with kzalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-2-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
bnx2x_mcast_enqueue_cmd() allocates memory for mac filtering list using
__get_free_pages().
This memory can be allocated with kzalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kzalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260701-b4-drivers-ethernet-v1-1-58776615db6e@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
rmnet_get_endpoint() is shared by packet receive paths and
RTNL-protected control paths. The receive paths already run under RCU/BH
context through the RX handler, while the control paths reach
rmnet_get_endpoint() after obtaining the rmnet port with
rmnet_get_port_rtnl().
The helper walks port->muxed_ep[] with hlist_for_each_entry_rcu(). Pass
lockdep_rtnl_is_held() as the non-RCU protection condition so
CONFIG_PROVE_RCU_LIST can see the RTNL-protected control-path calls
while preserving the existing RCU-reader behavior for data paths.
This was found by our static analysis tool and then manually reviewed
against the current tree. The dynamic triage evidence is a
target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
to documenting the existing protection contract.
This is a lockdep annotation cleanup. It does not change endpoint
lifetime or hash updates.
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Reviewed-by: Subash Abhinov Kasiviswanathan <subash.a.kasiviswanathan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260701124017.3205729-1-runyu.xiao@seu.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The GTP PDP lookup helpers are shared by RCU-protected data and report
paths and RTNL-protected control paths such as gtp_genl_new_pdp(). The
helpers walk RCU hlists, but they do not currently pass the RTNL
condition for the control-path lookups.
Pass lockdep_rtnl_is_held() to the PDP hlist iterators. Existing
RCU-reader callers remain valid because the RCU-list macros also accept
an active RCU read-side section; the added condition only documents the
non-RCU protection already used by RTNL control paths.
This was found by our static analysis tool and then manually reviewed
against the current tree. The dynamic triage evidence is a
target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
to documenting the existing protection contract.
This is a lockdep annotation cleanup. It does not change PDP lifetime or
hash updates.
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260701123925.3193089-1-runyu.xiao@seu.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Add test_trunc exercising the OVS_ACTION_ATTR_TRUNC action. The test
verifies truncation limits in four steps: reject trunc(1) and
trunc(13) which are below ETH_HLEN, confirm normal forwarding works,
apply trunc(14) which truncates packets to the Ethernet header and
verify ping fails, then restore normal forwarding and verify recovery.
The kernel requires max_len >= ETH_HLEN (14 bytes). trunc(14) sets
OVS_CB(skb)->cutlen so pskb_trim strips the IP payload at output
time; the receiver drops the runt frame and no echo reply is
generated.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
Reviewed-by: Aaron Conole <aconole@redhat.com>
Link: https://patch.msgid.link/20260702074926.1174810-1-houminxi@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Stanislav Fomichev says:
====================
net: hold instance lock around NETDEV_DOWN and NETDEV_GOING_DOWN
NETDEV_UP and NETDEV_REGISTER already run under the per-device
instance lock. The teardown side does not. Make it symmetric so
ops-locked drivers can rely on the lock being held in both
directions.
====================
Link: https://patch.msgid.link/20260702224150.3730033-1-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The lock-state table marks UNREGISTER as unlocked without saying
why. Add a short note that many handlers release the lowers via
dev_close().
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-7-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Sprinkle a few asserts about ops lock: netif_close_many and __dev_notify_flags
should now consistently run under the lock
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-6-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
rtnl_configure_link calls __dev_change_flags() and __dev_notify_flags,
both need the instance lock. rtnl_newlink_create grabs it but stacked
devices do not. Move the lock inside rtnl_configure_link.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-5-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netif_close_many will soon assert ops lock (for locked DOWN/GOING_DOWN).
Update mtk_eth_set_dma_device to manually grab and release the ops lock.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-4-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netif_close_many will soon assert ops lock (for locked DOWN/GOING_DOWN).
Update dsa_switch_shutdown to manually grab and release the ops lock.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-3-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Mirror what call_netdevice_register_net_notifiers does but for the
teardown. Cover only DOWN and GOING_DOWN. UNREGISTER is still unlocked
because of the SW devices using dev_xxx methods.
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260702224150.3730033-2-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE5DAy15EJMCV1R6v9YGjFFmlTOEoFAmpEQsUACgkQYGjFFmlT
OEpejQ/+OQ0+5tLHUP80eHPJDMx/WBlsGozmWF9LsTIkdZjd9WgVHTbQFMnny85Q
Fnzy1vBpXR7du4tAW+0TiDT7EsFqn1oxm3l5Ccpk2zP35SrPoGaWWSK9Sz6EXkrs
Ky90sJQw8WpggcZ4AnI1uXcsCtgvtMzdX7KHa51uox8g5JWFIAL5tVqCqhPSizlU
oL7iuvWETGLITw8VBu+TDm8fo/ZgrqzW7LE/GEyS+ZaDY3/OV+51DxMDqtNlLeE/
g3V9cGwiLEKhDo5UgVdBHUHcLLMOjJcWA6J90MlQ4Hc+SoIP35JN6lJ4zaXxfoEQ
GtOFRJNFs0m5uD5xDG2RpowPVnDuO73gLNwcxyI8G3uNVnNQKng03U0l34OMwnHv
aZa2FokgjreQ+3gKGKa7YD3d9VKw3TBoQL1bmU53vDMKuNHIedORdEGJgrwk5yLc
+AfFWKsSBUmYn3KdtnJqr8mxFDkzyD754OdIIVSra2fgkugb4pC8k0soEe2FI/9c
Q/ucYyyTUR/v+/9P5ZEV7GeOWzvcvRcuMwesarVsnSIXy40KYlDWjUBZ77t3/K9p
YmFe0/LX0bh1Z1KU0IxIUTWPFT74RCbgAhYK+e0AZ2NQB2loWkg/xsWbXj+ifmH4
iV9dK1qBTpIYoOs+Cd0dABqaR/RSIrbvtS7X0h8zyP22Eh/2xl4=
=PhAT
-----END PGP SIGNATURE-----
Merge tag 'sfc-net-pullrequest-20260630' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
Lucero Palau, Alejandro says:
====================
pull request: sfc 2026-07-01
here are the last CXL core changes for enabling CXL Type2 drivers to
initialize a CXL-capable device plus the netdev sfc driver changes using
this new CXL core Type2 support.
Please pull or let me know of any problem!
SFC changes for CXL type2 enabling
* tag 'sfc-net-pullrequest-20260630' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl:
sfc: support pio mapping based on cxl
sfc: obtain and map cxl range using devm_cxl_probe_mem
sfc: Initialize cxl dpa
sfc: Map cxl regs
sfc: add cxl support
cxl: Support dpa without a mailbox
cxl: Support Type2 cxl regs mapping
====================
Link: https://patch.msgid.link/20260701113805.14072-1-alejandro.lucero-palau@amd.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
"queue_map" is a pointer to "u32" and is not modified by the
ppe_ring_queue_map_set() function, thus can be made a pointer to const to
indicate that function is treating the pointed value read-only. This in
general makes the code easier to follow and a bit safer.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Luo Jie <jie.luo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260702094908.79859-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
There is no benefit in marking "const" a pass-by-value (not a pointer)
function argument, because it is passed as a copy on the stack. No code
readability improvements, no additional compiler-time safety for misuse.
Drop such redundant "const".
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Luo Jie <jie.luo@oss.qualcomm.com>
Link: https://patch.msgid.link/20260702094908.79859-3-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Tariq Toukan says:
====================
devlink and mlx5: Support cross-function rate scheduling
This series by Cosmin adds support for cross-function rate scheduling in
devlink and mlx5.
See detailed explanation by Cosmin below [0].
[0]
devlink objects support rate management for TX scheduling, which
involves maintaining a tree of rate nodes that corresponds to TX
schedulers in hardware. 'man devlink-rate' has the full details.
The tree of rate nodes is maintained per devlink object, protected by
the devlink lock.
There exists hardware capable of instantiating TX scheduling trees
spanning multiple functions of the same physical device (and thus
devlink objects) and therefore the current API and locking scheme is
insufficient.
This patch series changes the devlink rate implementation and API to
allow supporting such hardware and managing TX scheduling trees across
multiple functions of a physical device.
Modeling this requires having devlink rate nodes with parents in other
devlink objects. A naive approach that relies on the current
one-lock-per-devlink model is impossible, as it would require in some
cases acquiring multiple devlink locks in the correct order.
The solution proposed in this patch series makes use of the recently
introduced shared devlink instance [1] to manage rate hierarchy changes
across multiple functions.
V1 of this patch series was sent a long time ago [2], using a different
approach of storing rates in a shared rate domain with special locking
rules. This new approach uses standard devlink instances and nesting.
The first part of the series adds support to devlink rates for
maintaining the rate tree across multiple functions.
The second part changes the mlx5 implementation to make use of this (and
cleans up remnants of the previous approach, involving rate domains).
The neat part about using the shared devlink object is that it works for
SFs as well, which are already nested in their parent PF instances. So
with this series, complex scheduling trees spanning multiple SFs across
multiple PFs of the same NIC can now be supported.
====================
Link: https://patch.msgid.link/20260701073254.754518-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
It seems rates were not documented in the mlx5-specific file, so add
examples on how to limit VFs and groups and also provide an example of
the intended way to achieve cross-esw scheduling.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-15-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Adds a Python selftest using the YNL devlink API to verify the devlink
rate ops. The test requires a bond device given in the config as NETIF
containing two PFs. Test setup will then create 1 VF on each PF and
verify the various rate commands.
./devlink_rate_cross_esw.py
TAP version 13
1..3
ok 1 devlink_rate_cross_esw.test_same_esw_parent
ok 2 devlink_rate_cross_esw.test_cross_esw_parent
ok 3 devlink_rate_cross_esw.test_tx_rates_on_cross_esw
Tests will be skipped when the preconditions aren't met, when the
devlink API is too old or when the devices don't appear to support
cross-esw scheduling (detected via EOPNOTSUPP).
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-14-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Up to now, rate groups could only contain vports from the same E-Switch.
This patch relaxes that restriction if the device supports it
(HCA_CAP.esw_cross_esw_sched == true) and the right conditions are met:
- Link Aggregation (LAG) is enabled.
- The E-Switches are from the same shared devlink device.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-13-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
E-Switch QoS domains were added with the intention of eventually
implementing shared qos domains to support cross-esw scheduling in the
previous approach ([1]), but they are no longer necessary in the new
approach.
Remove QoS domains and switch to using the shd lock for protecting
against concurrent QoS modifications.
Enable the supported_cross_device_rate_nodes devlink ops attribute so
that all calls originating from devlink rate acquire the shd lock. Only
the additional entry points into QoS need to acquire the shd lock.
The wrinkle is that since shd can be NULL (e.g. on older HW without
serial number available), there needs to be a fallback locking
mechanism. The devlink instance lock cannot be used, as some code paths
into QoS (get, set & modify vport rate) happen with RTNL held, and the
existing devlink -> RTNL order prevents devlink lock usage there.
The other two options are either esw->state_lock or a new lock as
fallback when shd is NULL. This patch adds esw->state_lock, which
implies:
- 3 new lock/unlock helper pairs to acquire/release the missing lock:
- esw_qos_{,un}lock: acquire/release esw->state_lock when shd is NULL.
- esw_qos_shd_{,un}lock: when esw->state_lock is already held.
- esw_qos_devlink_{,un}lock: when shd is already held.
- esw_assert_qos_lock_held now asserts esw->state_lock is held when shd
is NULL.
Use the corresponding lock/unlock function in all places where either
shd or state_lock would need to be acquired.
Document all of this trickery next to esw_assert_qos_lock_held.
Enabling supported_cross_device_rate_nodes now is safe, because
mlx5_esw_qos_vport_update_parent rejects cross-esw parent updates.
This will change in the next patch.
[1]
https://lore.kernel.org/netdev/20250213180134.323929-1-tariqt@nvidia.com/
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-12-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In commit [1] the concept of the root node in the qos hierarchy was
removed due to a bug with how tx_share worked. The side effect is that
in many places, there are now corner cases related to parent handling.
However, since that change, support for tc_bw was added and now, with
upcoming cross-esw support, the code is about to become even more
complicated, increasing the number of such corner cases.
Bring back the concept of the root node, to which all esw vports and
nodes are connected to. This benefits multiple operations which can
assume there's always a valid parent and don't have to do ternary
gymnastics to determine the correct esw to talk to.
As side effect, there's no longer a need to store the groups in the
qos domain, since normalization can simply iterate over all children of
the root node. Normalization gets simplified as a result.
There should be no functionality changes as a result of this change.
[1] commit 330f0f6713 ("net/mlx5: Remove default QoS group and attach
vports directly to root TSAR")
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-11-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Qos cleanup is a complex affair, because of the two modes of operation
(legacy and switchdev).
Leaf QoS is removed:
1. In legacy mode by esw_vport_cleanup() -> mlx5_esw_qos_vport_disable()
2. In switchdev mode by mlx5_esw_offloads_devlink_port_unregister() ->
mlx5_esw_qos_vport_update_parent(). A little later in the same flow, the
calls in 1 happen but they are noops.
Zooming out a bit, from both mlx5_eswitch_disable_locked() and
mlx5_eswitch_disable_sriov() the leaves are destroyed before the nodes,
which is the reverse of what should be.
For SFs there's no devl_rate_nodes_destroy() call to unparent the
affected leaf.
Sanitize all of this by:
1. Destroying nodes before leaves in both legacy and switchdev mode.
2. Only removing vport qos from esw_vport_cleanup(), reachable from both
legacy and switchdev and also reachable by SF removal.
3. Unexpose mlx5_esw_qos_vport_update_parent(), which becomes internal
to qos.
4. Remove the WARN in mlx5_esw_qos_vport_disable().
This also takes care of a theoretical corner case, when
mlx5_esw_qos_vport_update_parent() tried to reattach the vport to
the original parent on failure, which can fail as well, leaving the
vport in a broken state.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-10-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Previously, the master device of the uplink netdev was queried for its
maximum link speed from the QoS layer, requiring the uplink_netdev mutex
and possibly the RTNL (if the call originated from the TC matchall
layer).
Acquiring these locks here is risky, as lock cycles could form. The
locking for the QoS layer is about to change, so to avoid issues,
replace the code querying the LAG's max link speed with the existing
infrastructure added in commit [1].
This simplifies this part and avoids potential lock cycles.
One caveat is that there's a new edge case, when the bond device is not
fully formed to represent the LAG device, the speed isn't calculated and
is left at 0. This now handled explicitly.
[1] commit f0b2fde980 ("net/mlx5: Add support for querying bond
speed")
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-9-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
This commit makes use of the building blocks previously added to
implement cross-device rate nodes.
A new 'supported_cross_device_rate_nodes' bool is added to devlink_ops
which lets drivers advertise support for cross-device rate objects.
If enabled and if there is a common shared devlink instance, then:
- all rate objects will be stored in the top-most common nested instance
and
- rate objects can have parents from other devices sharing the same
common instance.
Storing rates in the common shared ancestor is safe, because it is
reference counted by its nested devlink instances, so it's guaranteed to
outlive them. Furthermore, the shared devlink infra guarantees a given
nested devlink hierarchy is managed by the same driver.
The parent devlink from info->ctx is not locked, so none of its mutable
fields can be used. But parent setting only requires comparing devlink
pointer comparisons. Additionally, since the shared devlink is locked,
other rate operations cannot concurrently happen.
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-8-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Currently, a devlink rate's parent device is assumed to be the same as
the one where the devlink rate is created.
This patch changes that to allow rate commands to accept an additional
argument that specifies the parent dev. This will allow devlink rate
groups with leafs from other devices.
Example of the new usage with ynl:
Creating a group on pci/0000:08:00.1 with a parent to an already
existing pci/0000:08:00.1/group1:
./tools/net/ynl/pyynl/cli.py --spec \
Documentation/netlink/specs/devlink.yaml --do rate-new --json '{
"bus-name": "pci",
"dev-name": "0000:08:00.1",
"rate-node-name": "group2",
"rate-parent-node-name": "group1",
"parent-dev": {
"bus-name": "pci",
"dev-name": "0000:08:00.1"
}
}'
Setting the parent of leaf node pci/0000:08:00.1/65537 to
pci/0000:08:00.0/group1:
./tools/net/ynl/pyynl/cli.py --spec \
Documentation/netlink/specs/devlink.yaml --do rate-set --json '{
"bus-name": "pci",
"dev-name": "0000:08:00.1",
"port-index": 65537,
"parent-dev": {
"bus-name": "pci",
"dev-name": "0000:08:00.0"
},
"rate-parent-node-name": "group1"
}'
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260701073254.754518-7-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
