linux-stable.git/Documentation/networking, branch master

docs: oa-tc6-framework: Fix link to specification

2026-08-20T20:31:54+00:00

Current link for 10BASE-T1x MAC-PHY Serial Interface Specification
doesn't work - it returns 404. Update the link to the working one.

Signed-off-by: Stefan Wahren 
Acked-by: Randy Dunlap 
Link: https://patch.msgid.link/20260818135958.17311-1-wahrenst@gmx.net
Signed-off-by: Jakub Kicinski

Merge tag 'linux-can-next-for-7.3-20260818' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next

2026-08-18T17:30:21+00:00

Marc Kleine-Budde says:

====================
pull-request: can-next 2026-08-18

The first patch is by Sean Nyekjaer, targets the tcan4x5x driver and
puts the device into sleep mode before removing the driver.

Pavel Pisa's patch fixes the colors in the documentation of the TX
buffer FSM of CTU CAN FD driver.

2 patches by Cunhao Lu add support for the rockchip 3588 SoC to the
rockchip CAN-FD driver.

Kuniyuki Iwashima contributes per-netns device unregistration for the
vxcan driver.

Eduard Bostina converts the TI HECC DT bindings doc to DT schema.

Harini T contributes 2 patches to the xilinx_can driver to document
phys and update maintainer.

A patch by bui duc phuc converts the m_can driver to use
of_property_present() for wakeup-source.

Fanbo He's patch fixes a typo in the gs_usb driver.

The last patch is by Markus Schneider-Pargmann and removed not needed
driver_data from the m_can PCI driver.

* tag 'linux-can-next-for-7.3-20260818' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next:
  can: m_can: pci: Remove driver_data
  drivers: gs_usb: gs_usb_probe(): fix typo in error message
  can: m_can: Use of_property_present() for wakeup-source
  dt-bindings: can: xilinx_can: Document phys property
  dt-bindings: net: can: Convert TI HECC to DT schema
  MAINTAINERS: Replace maintainer for Xilinx CAN driver
  can: vxcan: support per-netns device unregistration.
  docs: ctucanfd: fix swapped colors in legend for TX buffer FSM of CTU CAN FD
  can: rockchip: add RK3588 CAN support
  dt-bindings: can: rockchip: add rk3588 CAN-FD compatible
  can: tcan4x5x: put tcan into sleep when removing driver
====================

Link: https://patch.msgid.link/20260817233420.2068204-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski

docs: ctucanfd: fix swapped colors in legend for TX buffer FSM of CTU CAN FD

2026-08-17T17:20:37+00:00

The Inaccessible and Accessible legend colors has been swapped
for many years. As I have helped to clean the CTU CAN FD section
of official documentation for mass produced silicon (multiple
models of microcontrollers) with the company representatives,
I have found the problem and propagate correction bask to
the primary CTU CAN FD sources.

Signed-off-by: Pavel Pisa 
Link: https://patch.msgid.link/d775feefa1c16d7ea7f42482483c81491f75ce6c.1785574572.git.pisa@cmp.felk.cvut.cz
Signed-off-by: Marc Kleine-Budde

ixd: add devlink support

2026-08-12T20:56:51+00:00

Enable initial support for the devlink interface with the ixd driver. The
ixd hardware is a single function PCIe device. So, the PCIe adapter gets
its own devlink instance to manage device-wide resources or configuration.

$ devlink dev show
pci/0000:83:00.6

$ devlink dev info pci/0000:83:00.6
pci/0000:83:00.6:
  driver ixd
  serial_number 00-a0-c9-ff-ff-23-45-67
  versions:
      fixed:
        device.type MEV
      running:
        fw.mgmt.api 2.0

Signed-off-by: Amritha Nambiar 
Reviewed-by: Michal Swiatkowski 
Reviewed-by: Maciej Fijalkowski 
Reviewed-by: Przemek Kitszel 
Tested-by: Bharath R 
Signed-off-by: Larysa Zaremba 
Signed-off-by: Tony Nguyen

ixd: add basic driver framework for Intel(R) Control Plane Function

2026-08-12T20:56:51+00:00

Add module register and probe functionality. Add the required support to
register IXD PCI driver, as well as probe, remove and shutdown callbacks.
Enable the PCI device and request to reserve the memory resources that will
be used by the driver. Finally map the BAR0 address space.

For now, use devm_kzalloc() to allocate adapter, as it requires the least
amount of code. In a later commit, it will be replaced with a devlink
alternative.

Co-developed-by: Amritha Nambiar 
Signed-off-by: Amritha Nambiar 
Reviewed-by: Maciej Fijalkowski 
Tested-by: Bharath R 
Signed-off-by: Larysa Zaremba 
Signed-off-by: Tony Nguyen

net/mlx5: implement max_sfs parameter

2026-08-12T01:06:30+00:00

Implement max_sfs generic parameter to allow users to control the total
light-weight NIC subfunctions that can be created using devlink instead
of external vendor tools. A value of 0 will effectively disable creation
of new subfunction devices. A warning is sent to user-space via extack
(returning extack without error code is interpreted as a warning by
user-space tools). The maximum value is capped at U16_MAX.

Signed-off-by: Nikolay Aleksandrov 
Reviewed-by: David Ahern 
Reviewed-by: Alexander Lobakin 
Signed-off-by: Tariq Toukan 
Link: https://patch.msgid.link/20260806073037.3001886-3-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski

devlink: add generic device max_sfs parameter

2026-08-12T01:06:30+00:00

Add a new generic devlink device parameter (max_sfs) to control if and
how many light-weight NIC subfunctions can be created. Subfunctions are
a light-weight network functions backed by an underlying PCI function.
Their lifecycle can already be managed by devlink, but currently users
cannot enable them in the device. They can be enabled/disabled only via
external vendor tools. This parameter allows subfunctions to be enabled
(>0) or disabled (0) via devlink. A subsequent patch will add support
for max_sfs to the mlx5 driver.

Signed-off-by: Nikolay Aleksandrov 
Reviewed-by: David Ahern 
Reviewed-by: Jiri Pirko 
Reviewed-by: Aleksandr Loktionov 
Reviewed-by: Alexander Lobakin 
Signed-off-by: Tariq Toukan 
Link: https://patch.msgid.link/20260806073037.3001886-2-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski

tun/tap & vhost-net: stop tail-drop when IFF_BACKPRESSURE is set

2026-08-08T00:29:16+00:00

This commit prevents tail-drop when IFF_BACKPRESSURE is set, a qdisc is
present and the ptr_ring becomes full. Once the ring reaches capacity
after a produce attempt, the netdev queue is stopped instead of dropping
subsequent packets. Without the flag, or if no qdisc is present, the
previous tail-drop behavior is preserved.

IFF_BACKPRESSURE is added to TUN_FEATURES here and not in the patch that
defines it, so that TUNSETIFF honours the flag only once the
implementation behind it is complete.

The unconditional version of this behavior was reverted because it caused
a significant throughput drop in an IPv6 multicast testcase on Brett
Sheffield's librecast testbed [1]: with 8 iperf3 TCP threads sending, the
throughput dropped from 13.5 Gbit/s to 9.13 Gbit/s. This is why the queue
stopping is now gated on IFF_BACKPRESSURE.

If producing an entry fails anyway due to a race, tun_net_xmit() drops
the packet. Such rare races are expected because LLTX is enabled and the
transmit path operates without the usual locking.

The queue state is only touched while the device is running. The stop
itself would be harmless during teardown, as tun_net_close() sets the
same bit, but the re-check below it wakes the queue again and must not
clear that stop.

A later TUNSETIFF can clear the flag again while the device has at most
one queue. Past that point tun_set_iff() returns before it writes
tun->flags, which is how it already treats every other TUN_FEATURES bit.
For the case where the flag does change, tun_set_iff() calls
tun_force_wake_queue() for the attached tfiles, so that no queue stays
stopped without a consumer that would wake it.

The __tun_wake_queue() function of the consumer races with the producer
for waking/stopping the netdev queue, which could result in a stalled
queue. Therefore, an smp_mb__after_atomic() is introduced that pairs
with the smp_mb() of the consumer. It follows the principle of store
buffering described in tools/memory-model/Documentation/recipes.txt:

- The producer in tun_net_xmit() first sets __QUEUE_STATE_DRV_XOFF,
  followed by an smp_mb__after_atomic() (= smp_mb()), and then reads the
  ring with __ptr_ring_check_produce().

- The consumer in __tun_wake_queue() first writes zero to the ring in
  __ptr_ring_consume(), followed by an smp_mb(), and then reads the queue
  status with netif_tx_queue_stopped().

=> Following the aforementioned principle, it is impossible for the
   producer to see a full ring (and therefore not wake the queue on the
   re-check) while the consumer simultaneously fails to see a stopped
   queue (and therefore also does not wake it).

tun_net_xmit() holds only the producer_lock and can not reset cons_cnt,
which the consumer_lock protects, so the wake on the re-check leaves
stale credit behind. That is accepted as best-effort, the re-check rarely
succeeds and the next drain corrects the count.

The documentation in tuntap.rst is updated accordingly.

Benchmarks:
My own benchmarks show a slight regression in raw transmission performance
when using two sending threads. Packet loss also occurs only in the
two-thread sending case; no packet loss was observed with a single
sending thread.

Test setup:
AMD Ryzen 5 5600X at 4.3 GHz, 3200 MHz RAM, isolated QEMU threads;
Average over 50 runs @ 100,000,000 packets. SRSO and spectre v2
mitigations disabled.

Note for tap+vhost-net:
XDP drop program active in VM -> ~2.5x faster; slower for tap due to
more syscalls (high utilization of entry_SYSRETQ_unsafe_stack in perf)

+--------------------------+--------------+----------------+----------+
| 1 thread                 | Stock        | Patched with   | diff     |
| sending                  |              | fq_codel qdisc |          |
+------------+-------------+--------------+----------------+----------+
| TAP        | Received    | 1.132 Mpps   | 1.123 Mpps     | -0.8%    |
|            +-------------+--------------+----------------+----------+
|            | Lost/s      | 3.765 Mpps   | 0 pps          |          |
+------------+-------------+--------------+----------------+----------+
| TAP        | Received    | 3.857 Mpps   | 3.901 Mpps     | +1.1%    |
|            +-------------+--------------+----------------+----------+
| +vhost-net | Lost/s      | 0.802 Mpps   | 0 pps          |          |
+------------+-------------+--------------+----------------+----------+

+--------------------------+--------------+----------------+----------+
| 2 threads                | Stock        | Patched with   | diff     |
| sending                  |              | fq_codel qdisc |          |
+------------+-------------+--------------+----------------+----------+
| TAP        | Received    | 1.115 Mpps   | 1.081 Mpps     | -3.0%    |
|            +-------------+--------------+----------------+----------+
|            | Lost/s      | 8.490 Mpps   | 391 pps        |          |
+------------+-------------+--------------+----------------+----------+
| TAP        | Received    | 3.664 Mpps   | 3.555 Mpps     | -3.0%    |
|            +-------------+--------------+----------------+----------+
| +vhost-net | Lost/s      | 5.330 Mpps   | 938 pps        |          |
+------------+-------------+--------------+----------------+----------+

[1] https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/

Co-developed-by: Tim Gebauer 
Signed-off-by: Tim Gebauer 
Signed-off-by: Simon Schippers 
Link: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/
Link: https://patch.msgid.link/20260803183641.96882-6-simon.schippers@tu-dortmund.de
Signed-off-by: Jakub Kicinski

pds_core: add PLDM firmware update support via devlink flash

2026-08-06T00:59:29+00:00

Implement PLDM FW Update in the pds_core driver using the upstream
pldmfw API. This allows updating an entire PLDM FW package at once
or updating specific firmware components by name.

Flash the entire image:
  devlink dev flash pci/0000:b5:00.0 file firmware.pldmfw

Flash a specific component from the PLDM FW package:
  devlink dev flash pci/0000:b5:00.0 \
    file firmware.pldmfw component fw.cpld

Per-component update uses driver-defined component names (fw, fw.cpld,
etc.). Not all components support per-component update - devlink will
reject the request if the specified component cannot be updated.

Signed-off-by: Brett Creeley 
Signed-off-by: Nikhil P. Rao 
Link: https://patch.msgid.link/20260730-upstream_v8-v12-3-136cd174ee85@amd.com
Signed-off-by: Jakub Kicinski

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2026-07-30T19:53:19+00:00

Cross-merge networking fixes after downstream PR (net-7.2-rc6).

No conflicts.

Adjacent changes:

net/ipv4/route.c
  dbc3791e3b24 ("net: do not send ICMP/NDISC Redirects when peer allocation fails")
  7804eaa057fe ("ipv4: snapshot dst.dev in ip_rt_send_redirect() and ip_rt_get_source()")

drivers/net/tun.c
  23dad2d088df ("tun: no longer rely on RTNL in tun_fill_info()")
  c3da92af07ea ("Revert "tun/tap: add ptr_ring consume helper with netdev queue wakeup"")

drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c
  3bd438a58e91 ("octeontx2-af: Block VFs from clobbering special CGX PKIND state")
  5ba5611ef946 ("octeontx2-af: reserve 4 PKINDs for skip-size custom use")

drivers/net/wireless/ath/ath12k/core.h
drivers/net/wireless/ath/ath12k/mac.c
drivers/net/wireless/ath/ath12k/peer.c
  469d7e6077c1 ("wifi: ath12k: resolve PENDING ML peer ID from MLO_PEER_MAP HTT event")
  378e659029d5 ("wifi: ath12k: introduce host_alloc_ml_id hardware parameter")
  c42b27336eef ("wifi: ath12k: fix survey indexing across bands")

Signed-off-by: Jakub Kicinski