kernel/git/next/linux-next.git/Documentation/networking/devlink, branch master

devlink: print controller prefix for non-zero controller

2026-07-08T09:23:49+00:00

The controller prefix (c) 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 Reviewed-by: Parav Pandit Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260702111726.816985-2-tariqt@nvidia.com Signed-off-by: Paolo Abeni

net/mlx5: Document devlink rates

2026-07-07T09:31:27+00:00

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 Reviewed-by: Carolina Jubran Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260701073254.754518-15-tariqt@nvidia.com Signed-off-by: Paolo Abeni

devlink: Allow rate node parents from other devlinks

2026-07-07T09:31:26+00:00

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 Reviewed-by: Carolina Jubran Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260701073254.754518-8-tariqt@nvidia.com Signed-off-by: Paolo Abeni

devlink: Update nested instance locking comment

2026-07-07T09:31:26+00:00

In commit [1] a comment about nested instance locking was updated. But there's another place where this is mentioned, so update that as well. [1] commit 0061b5199d7c ("devlink: Reverse locking order for nested instances") Signed-off-by: Cosmin Ratiu Reviewed-by: Carolina Jubran Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260701073254.754518-2-tariqt@nvidia.com Signed-off-by: Paolo Abeni

docs: net: fix minor issues with devlink docs

2026-06-15T22:42:53+00:00

Update devlink documentation to match current code: - describe health reporter defaults (it's currently under "callbacks"), best-effort auto-dump, and port-scoped reporters - fix generic parameter names and values - fix nested devlink setup wording and registration ordering Link: https://patch.msgid.link/20260613165846.2913092-3-kuba@kernel.org Signed-off-by: Jakub Kicinski

Documentation: networking: devlink: stmmac: fix typo in phc_coarse_adj

2026-05-15T00:12:40+00:00

"Functionnal" should be "Functional". Signed-off-by: Avinash Duduskar Link: https://patch.msgid.link/20260512133214.1773502-1-avinash.duduskar@gmail.com Signed-off-by: Jakub Kicinski

devlink: Document resource scope filtering

2026-04-09T02:55:39+00:00

Document the scope parameter for devlink resource show, which allows filtering the dump to device-level or port-level resources only. Signed-off-by: Or Har-Toov Reviewed-by: Moshe Shemesh Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260407194107.148063-13-tariqt@nvidia.com Signed-off-by: Jakub Kicinski

devlink: Document port-level resources and full dump

2026-04-09T02:55:39+00:00

Document the port-level resource support and the option to dump all resources, including both device-level and port-level entries. Signed-off-by: Or Har-Toov Reviewed-by: Shay Drori Reviewed-by: Moshe Shemesh Reviewed-by: Jiri Pirko Signed-off-by: Tariq Toukan Link: https://patch.msgid.link/20260407194107.148063-10-tariqt@nvidia.com Signed-off-by: Jakub Kicinski

documentation: networking: add shared devlink documentation

2026-03-14T20:08:50+00:00

Document shared devlink instances for multiple PFs on the same chip. Signed-off-by: Jiri Pirko Link: https://patch.msgid.link/20260312100407.551173-13-jiri@resnulli.us Signed-off-by: Jakub Kicinski

net/mlx5: implement swp_l4_csum_mode via devlink params

2025-11-21T03:01:22+00:00

swp_l4_csum_mode controls how L4 transmit checksums are computed when using Software Parser (SWP) hints for header locations. Supported values: 1. default: device will choose between full_csum or l4_only. Driver will discover the device's choice during initialization. 2. full_csum: calculate L4 checksum with the pseudo-header. 3. l4_only: calculate L4 checksum without the pseudo-header. Only available when swp_l4_csum_mode_l4_only is set in mlx5_ifc_nv_sw_offload_cap_bits. Note that 'default' might be returned from the device and passed to userspace, and it might also be set during a devlink_param::reset_default() call, but attempts to set a value of default directly with param-set will be rejected. The l4_only setting is a dependency for PSP initialization in mlx5e_psp_init(). Reviewed-by: Aleksandr Loktionov Signed-off-by: Daniel Zahka Link: https://patch.msgid.link/20251119025038.651131-5-daniel.zahka@gmail.com Signed-off-by: Jakub Kicinski