The current eMDIO MDC rate is 558 kHz on i.MX95 B0. This is very low,
but also very compatible. However, for example NXP TJA1120 PHY needs
at minimum 1 MHz MDC clock and 558 kHz does not work with that PHY.
As a minimum change, increase the MDC clock to 2.5 MHz which matches
the 802.3 specification. Also, even old PHYs like LAN8210Ai, KSZ8794,
DP83822 support up to 2.5 MHz MDC clock frequency, and it covers the
NXP TJA1120 as well. There is no known rationale for why the 558 kHz
was picked when the eMDIO driver was added.
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260924180607.60932-1-marex@nabladev.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Théo Lebrun says:
====================
net: macb: fix close races (and RX refill error handling)
The context-swapping series [0] has been ongoing for a while. The most
interesting part is a proper hardware shutdown sequence, which is truly
lacking in other parts of the MACB driver: at close, at suspend and in
the HRESP error task.
Instead of introducing that sequence for a new feature, apply it now to
fix the main offender, the close path. That fixes the races listed in
patch 3 and will allow the sequence to be reused later.
The first two patches are also fixes, but not related to the shutdown
sequence: they address allocation-failure codepaths. They are sent
alongside patch 3 because they touch the same code and would cause
merge conflicts if applied separately.
Now, let me list issues I'm aware of that we do *not* fix here, to make
the scope explicit:
- HRESP task should sync with all other contexts. It frees buffers
under the feet of the whole driver. The hardware shutdown sequence
will help.
- Suspend callback is also racy with BH primitives. We'll be able to
reuse the hardware shutdown sequence.
- Even if we assume tasks are frozen, the phylink ops aren't and might
trigger between suspend and resume callbacks. Here we need to
(1) early return in phylink ops and (2) at resume put the HW in its
proper state according to phylink ops that occured.
- Alloc failure codepaths aren't perfect outside open. Hardware and
ring buffers are left in a sad state. We can probably do better.
[0]: https://lore.kernel.org/all/20260812-macb-context-v9-0-7ddbf5f715e0@bootlin.com/
====================
Link: https://patch.msgid.link/20260925-macb-close-v2-0-360efa565914@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The macb_close() operation is facing races as it disables IRQs late in
its sequence and keeps BH primitives alive while shutdown.
Non exhaustive list of races that could occur:
- macb_tx_error_task() could be scheduled and access the buffers freed
by macb_close().
- macb_tx_error_task() or macb_hresp_error_task() might re-enable
interrupts after the IDR write in macb_close().
- macb_close() calls napi_disable() meaning that if
macb_tx_error_task() occurs later, it will deadlock on napi_disable()
that shouldn't be called if NAPI is already disabled.
- macb_hresp_error_task() might reinit every RX/TX ring under
macb_close()'s foot.
- macb_interrupt() might re-enable NAPI just after it has been
disabled by macb_close().
Instead, disable all our primitives one by one:
- (1) mask and sync on IRQ handlers,
- (2) drain any scheduled bp->hresp_err_bh_work,
- (3) drain any scheduled queue->tx_error_task,
- (4) drain queue->napi_rx/napi_tx,
- (5) drain bp->tx_lpi_work.
Careful! Ordering is important because our scheduling primitives can
wake each other up. Recap table:
| | enable/disable | schedule |
| |----|-------|-------|------|----|----|--------|-----|
| |IRQs|napi_tx|napi_rx|tx_lpi|napi|napi|tx_error|hresp|
| Context | | | | task | rx | tx | task |task |
|===============|====|=======|=======|======|====|====|========|=====|
| open | X | X | X | | | | | |
| link_up | X | | | | | | | |
| link_down | X | | | | | | | |
| close | X | X | X | | | | | |
| enable_tx_lpi | | | | X | | | | |
| swap | X | X | X | X | | | | |
| suspend | X | X | X | | | | | |
| resume | X | X | X | | | | | |
|---------------|----|-------|-------|------|----|----|--------|-----|
| irq & netpoll | X | | | | X | X | X | X |
|---------------|----|-------|-------|------|----|----|--------|-----|
| napi_rx | X | | | | X | | | |
| napi_tx | X | | | X | | X | | |
|---------------|----|-------|-------|------|----|----|--------|-----|
| tx_error_task | X | X | | | | | | |
| hresp task | X | | | | | | | |
As example, one ordering constraint that can be deduced from the table:
napi_tx can schedule tx_lpi_task meaning napi_tx must be disabled
before tx_lpi_task, else we risk napi_tx re-enabling tx_lpi_task after
it has been disabled by macb_close().
We do *not* use IDR masking to shutdown IRQs because that risks
conflicting with BH primitives we have not disabled yet. For example if
we writel(IDR) in macb_close() and napi_rx is pending then IRQs might
be unmasked by the NAPI poll. As for why we do not use disable_irq():
we will have situations where we are quiesced but want to listen to
some IRQs and (minor reason) we register shared IRQ handlers so we
shouldn't disable the full IRQ line.
Instead we introduce a bool that tells macb_interrupt() to self-disarm.
Its default value is true as we start closed. It gets set to false
while interface is active. Reading into my crystal ball, we'll reuse
that flag in suspend/WOL, set_ringparam and change_mtu (context swap).
Note that old IRQ handler tried preventing a race with close by
self-disarming based on netif_running(). This might work, but it does
not prevent a race with the error codepath of macb_open() which needs
to run with IRQs dis-armed but netif_running() returns true during that
time.
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20260925-macb-close-v2-3-360efa565914@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gem_rx_refill() is responsible for Rx SKB allocation, including at open,
but its prototype indicates a void return value.
Therefore we change the code to propagate allocation and DMA mapping
errors back up the stack, making sure the open fails if no descriptors
were allocated. Change all those to return errno-style ints:
- gem_rx_refill()
- its parent gem_init_rx_ring()
- its grand-parent gem_init_rings()
- the macbgem_ops.mog_init_rings function pointer
- its grand-uncle macb_init_rings()
We tolerate some allocation failures: we accept running with the rx ring
only partially filled with successful descriptors. It is important we
refuse the zero-valid-descriptor case: nothing would ever trigger a
refill, which only happens once a frame has been received.
Theoretical bugfix, never encountered in practice. To reproduce,
introduce memory pressure (less than 512 SKBs of free memory) and open
the interface. I expect the last queue to be unusable because it has
zero usable rx buffers.
Note that other callers of refill (resume, HRESP error task, NAPI)
cannot do anything useful with that error and keep their best-effort
refill, hoping it will improve.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260925-macb-close-v2-2-360efa565914@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The refill logic is simple: iterate over all pending rx slots, allocate
SKB (& DMA map) if needed and hand it off to the hardware by clearing
the RX_USED flag.
If the refill operation fails mid-way, it early returns leaving the
remaining slots untouched. In an initialised ring that is safe: a slot
is either owned by the hardware holding a valid buffer, or
software-owned (RX_USED set) waiting for refill to hand it a new one.
When slots have never been initialised however, we are in trouble.
After dma_alloc_coherent() of the rx ring buffer, all slots have NULL
pointers and RX_USED cleared meaning HW will try using them. Ensure
this does not happen by setting the RX_USED flag on all slots before
calling refill at buffer alloc, in gem_init_rx_ring(). That way even if
refill fails on an alloc/dma_map, the HW won't try using NULL pointers
as buffers.
Note we tweak gem_rx() and macb_rx_pending(): their previous stop
condition was only if desc was RX_USED. Now it must be either RX_USED
or we got out of the range of successfully allocated descriptors
(detected using the rx_tail and rx_prepared_head cursors).
Otherwise gem_rx() could consume unallocated buffers.
Theoretical bugfix, never encountered in practice. To reproduce,
introduce memory pressure (less than 512 SKBs of free memory) and open
the interface.
Note that this codepath also hits at resume, on HRESP errors and on
set_ringparam (while interface is running).
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://patch.msgid.link/20260925-macb-close-v2-1-360efa565914@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
James Hilliard says:
====================
net: stmmac: add Allwinner H616 EMAC1 support
The H616 secondary EMAC supports RMII at 10/100 Mbps and uses a separate
system-control clock register at offset 0x34. Add its binding and a
sun8i stmmac variant using that register. A distinct compatible without
an older fallback prevents the driver from using EMAC0's clock register.
EMAC1 connects internally to the co-packaged AC200 or AC300 EPHY and has
no external PHY pins. Leave PHY initialization to the PHY driver instead
of using the H3 internal-PHY controls. The RMII-only variant does not
expose the RGMII clock-delay properties.
First move the MAC software reset from probe to the DMA reset callback,
after PHY initialization. This lets the MAC and its MDIO bus remain
registered when the PHY driver or one of its suppliers is not ready yet.
Mask interrupts before requesting reset and clear DMA and interrupt state
even if it times out. Keep the separate H3 MDIO-mux reset sequence
unchanged.
The AC200/AC300 EPHY driver and package bindings are already in
net-next. This series separates the H616 EMAC1 MAC driver and binding
support from the earlier combined series. PWM, MFD and device-tree
enablement are being handled separately.
====================
Link: https://patch.msgid.link/20260927-submit-h616-emac1-v1-v6-0-e64971f4e414@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The H616 secondary EMAC uses a separate system-control clock register
and supports only RMII at 10/100 Mbps. It connects internally to the
co-packaged AC200 or AC300 EPHY and has no external PHY pins.
Add an EMAC1 variant using the dedicated register and enable only RMII.
Leave PHY initialization to the PHY driver instead of using the H3
internal-PHY controls. No RX or TX clock delays are configured for this
RMII-only variant.
Co-developed-by: Richard Genoud <richard.genoud@bootlin.com>
Signed-off-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Alastair D'Silva <alastair@d-silva.org>
Tested-by: Alastair D'Silva <alastair@d-silva.org>
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://patch.msgid.link/20260927-submit-h616-emac1-v1-v6-3-e64971f4e414@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The H616 secondary EMAC uses a separate system-control clock register
and supports only RMII at 10/100 Mbps. Add its distinct compatible
without an older fallback, since using the primary EMAC clock register
would not work.
Constrain the PHY interface mode to RMII, matching the hardware.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://patch.msgid.link/20260927-submit-h616-emac1-v1-v6-2-e64971f4e414@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The MAC software reset needs a running receive clock from the PHY.
Resetting the MAC at the end of probe therefore fails when the PHY driver
has not been loaded or its probe has deferred on a missing supplier. The
failure removes the MAC and its MDIO bus, so loading the missing driver
later cannot recover the interface without reprobing the MAC.
Perform the software reset in the DMA reset callback instead. The stmmac
core calls it during hardware setup after attaching and initializing the
PHY, and resumes a suspended PHY before reopening or resuming the MAC.
Mask interrupts before requesting the reset and retain the existing
DMA and interrupt-register clearing even if the reset times out. Return
reset errors through the normal hardware-setup error path.
Remove the unconditional reset from probe. Keep the separate H3 MDIO-mux
reset after switching the mux and powering the selected PHY, since it is
needed to latch the selected interface before MDIO accesses.
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Link: https://patch.msgid.link/20260927-submit-h616-emac1-v1-v6-1-e64971f4e414@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Smatch combines the return values together and wants all the callers
to handle the positive values so it leads to static checker warnings.
Add a comment explaining the return values.
Generally functions which return non-standard values should have a
comment.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Link: https://patch.msgid.link/09f24cefc214455305543a0528ceae6349c77419.1790357822.git.error27@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Lawrence Lee says:
====================
ipv6: update NUD_FAILED neighbors from NA messages
Neighbor Advertisements for existing NUD_FAILED entries are currently
ignored. This can leave a first-hop router with an unusable neighbor after
the host becomes reachable and announces itself, particularly when
forwarding is offloaded away from the kernel and traffic destined to the
FAILED neighbor is unable to trigger the kernel's normal neighbor
resolution process.
Allowing neighbor entries to be updated from NAs already received by the
kernel is preferable since it creates less work compared to periodically
probing FAILED neighbors (e.g. using NTF_EXT_MANAGED).
Extend accept_untracked_na to treat FAILED entries like absent entries.
Require a target link-layer address, IPv6 forwarding, and acceptance by the
sysctl, including its source-prefix check in mode 2. Recover the entry only
to STALE, including for solicited NAs, to maintain parity with handling of
non-existent neighbor cache entries.
Patch #1 implements the behavior and updates RFC 9131-related comments and
accept_untracked_na documentation.
Patch #2 extends ndisc_unsolicited_na_test.sh to cover FAILED-entry
recovery and each acceptance gate, including in-prefix and out-of-prefix
mode 2.
Thanks to Ido Schimmel for feedback on the original RFC.
====================
Link: https://patch.msgid.link/cover.1790127207.git.lfqlee314@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Seed a FAILED neighbor before triggering an unsolicited NA. Verify that
the entry transitions to STALE and learns the advertised link-layer
address only when drop_unsolicited_na is disabled, accept_untracked_na
mode 1 or in-prefix mode 2 is enabled, and IPv6 forwarding is enabled.
Verify that disabling each gate keeps the entry in FAILED without a
link-layer address.
Mark the seed externally learned and disable carrier-based eviction so
the entry cannot be garbage-collected before the NA arrives. Require the
marker after processing to prove that a recovered entry was updated in
place instead of deleted and recreated.
Keep the NA source, target, and neighbor key fixed for the mode 2 cases.
Vary the prefix configured on the router to exercise the source-prefix
check without changing the entry under test.
Arm packet capture before bringing up the host interface and starting
DAD. Wait for the capture to become ready and for tcpdump to exit so the
NA cannot be missed and receive processing is complete before checking
the neighbor entry.
Preserve the return code from test_unsolicited_na_common() before
constructing the test description. The array assignment previously reset
the return code to zero and caused existing cases to report false success.
Link: https://lore.kernel.org/r/20260813233344.445265-1-lfqlee314@gmail.com
Signed-off-by: Lawrence Lee <lfqlee314@gmail.com>
Link: https://patch.msgid.link/ce40008682ed26ab039168a5fcb515eff8d30c3a.1790127207.git.lfqlee314@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Transition a FAILED neighbor entry to STALE upon receipt of an NA
message on routers when accept_untracked_na is enabled. This extends the
RFC 9131 accept_untracked_na behavior so that FAILED entries are treated
the same as non-existent entries.
RFC 4861 section 7.3.3 says that an entry should be deleted when address
resolution fails. Linux instead retains the entry in NUD_FAILED, so
treating it as untracked is consistent with the protocol model.
Trying to resolve FAILED neighbors via periodic probing (e.g. using
NTF_EXT_MANAGED) is more work compared to this approach which uses
information in NAs that the kernel may already be receiving. Note that
because this behavior in IPv6 is dependent on the accept_untracked_na
sysctl setting, this approach is more conservative than IPv4 which
transitions FAILED neighbors to STALE by default upon receiving GARPs.
Link: https://lore.kernel.org/r/20260813233344.445265-1-lfqlee314@gmail.com
Signed-off-by: Lawrence Lee <lfqlee314@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/6be400e601f4ffa59e47ddb5daa33ecdd85dd88b.1790127207.git.lfqlee314@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Arthur Crepin Leblond says:
====================
w5100: restore GPIO-based link detection
In the previous version of the w5100 driver, the LINKLED pin could be
wired to a GPIO to detect the link status changes via an interrupt.
This only works on w5500 as it is the only one documenting its LINKLED
pin to hold the link status (on w5100 the LINKLED pin is changing with
RX/TX activity).
This series of patches is bringing back the link status detection on
w5500 using the Link Status bit of the PHY Configuration Register.
Additionally, the LINKLED pin can also be wired to detect link status
changes and read the register in the interrupt handler.
====================
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-0-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Detect the carrier state on the w5500 Ethernet controller using the
Link Status bit from the PHY Configuration register (PHYCFGR).
On w5100/w5200, which lack this register, get_link() is not implemented
and the carrier state is not reported (netif_carrier_(on|off) is not
called).
For the w5500, add an optional interrupt, wired to the LINKLED pin of
the device, to detect link status changes with a read of the PHYCFGR
register and update of the carrier state with netif_carrier_(on|off).
If this interrupt is not set in the DT binding, get_link() is not
implemented and the carrier state is not reported
(netif_carrier_(on|off) is not called).
The interrupt handler and the PHYCFGR register readings are
synchronized using a mutex.
A few changes are also brought for the bring-up/teardown
synchronization:
- The net device is registered last in the probe() function so no
operation can be performed before the probing is finished
- The net device is unregistered first in remove()
- dev_name is now used instead of netdev_name
- w5100_stop() calls cancel_work_sync() and flush_work() to make sure
there is no race condition or unfinished work
- w5100_suspend() calls w5100_stop()
- w5100_resume() calls w5100_open()
- The main irq is not automatically enabled in w5100_probe() but in
w5100_open() and disabled in w5100_stop()
Commit dacf281771 ("w5100: remove unused gpio link detection")
dropped the link_gpio/link_irq handling on the grounds that no
devicetree user passed a "link" gpio at the time and that it used the
old gpio interface.
This isn't a plain revert of that removal: link detection is now done
using a second interrupt rather than a gpio with a documented DT
binding.
Set the WIZNET entry as DRIVER and add drivers/net/ethernet/wiznet in
MAINTAINERS file.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Fixes: dacf281771 ("w5100: remove unused gpio link detection")
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-3-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add an optional link status interrupt which can be connected to the
LINKLED pin on the device to detect link status changes. This second
interrupt is only supported on wiznet,w5500.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-2-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert the Wiznet w5x00 SPI Ethernet controller binding from
plain text to DT schema.
Change the trigger type from edge-falling to low to match the driver
implementation.
Add wiznet,w5100.yaml entry in MAINTAINERS.
Signed-off-by: Arthur Crepin Leblond <arthur@marmottus.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260924-wiznet-link-gpio-v11-1-42a332517b30@marmottus.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After reclaiming, the Tx poll asks to be polled again. That extra poll
finds nothing to do and does not reduce the interrupt rate.
Complete the NAPI and unmask the ring interrupt right after the reclaim.
On a CM4 this raises 60 byte pktgen Tx from about 187k to 224k pps and
saves about 5% of one core at TCP line rate.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260928121454.901306-1-nb@tipi-net.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Replace if/else blocks using regmap_set_bits()/regmap_clear_bits() with
the simpler regmap_assign_bits() calls in the lantiq gswip, mt7530 and
qca8k drivers.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://patch.msgid.link/20260924083538.461887-1-peng.fan@oss.nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Use IP_LOCAL_PORT_RANGE to limit a socket to 8 ports, bind 8 sockets
to port 0 and check they get 8 distinct ports and the 9th bind fails
with EADDRINUSE. Run it for the four combinations of reuse options on
the sockets:
none (existing test)
SO_REUSEPORT
SO_REUSEADDR
SO_REUSEADDR + SO_REUSEPORT
TCP passes all four. Before the udp fix UDP only passes the first
one: the scan hands out a port already taken by a socket with the
same reuse options, so fewer than 8 distinct ports come back and the
9th bind succeeds.
# ./ip_local_port_range.sh
Before:
ok 13 ip_local_port_range.ip4_udp.exhaust_8_port_range
not ok 14 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseport
not ok 15 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr
not ok 16 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr_reuseport
ok 49 ip_local_port_range.ip6_udp.exhaust_8_port_range
not ok 50 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseport
not ok 51 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr
not ok 52 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr_reuseport
After:
ok 13 ip_local_port_range.ip4_udp.exhaust_8_port_range
ok 14 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseport
ok 15 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr
ok 16 ip_local_port_range.ip4_udp.exhaust_8_port_range_reuseaddr_reuseport
ok 49 ip_local_port_range.ip6_udp.exhaust_8_port_range
ok 50 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseport
ok 51 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr
ok 52 ip_local_port_range.ip6_udp.exhaust_8_port_range_reuseaddr_reuseport
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260928023145.301855-2-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Observed with two independent servers in the same process:
fd1 = socket(AF_INET, SOCK_DGRAM, 0);
setsockopt(fd1, SOL_SOCKET, SO_REUSEPORT, ...);
bind(fd1, port 0); /* got 40000 */
fd2 = socket(AF_INET, SOCK_DGRAM, 0);
setsockopt(fd2, SOL_SOCKET, SO_REUSEPORT, ...);
bind(fd2, port 0); /* got 40000 as well */
Both sockets end up on the same port and join the same reuseport
group, so each of them takes part of the other's datagrams. The same
port sharing happens with SO_REUSEADDR, without the reuseport group.
udp_lib_lport_inuse() keeps the reuse rules when it scans for a free
port: a socket with SO_REUSEADDR set, or one with SO_REUSEPORT and
the same uid, is not a conflict, so its port is never marked in the
bitmap and the scan can hand it out again. Those rules only make
sense when the user asks for a specific port. bind(0) wants a free
port and has no way to know whose port it lands on.
TCP already does this: inet_csk_find_open_port() passes relax=false
and reuseport_ok=false, so the scan treats every port in use as a
conflict whatever options the sockets have. Commit aacd9289af
("tcp: bind() use stronger condition for bind_conflict") did it for
SO_REUSEADDR and commit 0643ee4fd1 ("inet: Fix get port to handle
zero port number with soreuseport set") for SO_REUSEPORT.
Do the same for UDP: ignore both options during a scan, keep them
for an explicit port.
This changes bind(0) for SO_REUSEADDR sockets once the port range is
full: it used to share a port and now fails with EADDRINUSE, like
TCP. Sharing a port on purpose when the range is full is a feature,
TCP has net.ipv4.ip_autobind_reuse for it, off by default. UDP can
get the same knob later, this patch only fixes the scan.
Fixes: ba418fa357 ("soreuseport: UDP/IPv4 implementation")
Cc: stable+noautosel@kernel.org # bind() behaviour change
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Link: https://patch.msgid.link/20260928023145.301855-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When disconnecting a device while firmware is not present on the system,
usbatm_usb_disconnect() waits for the heavy_init thread to finish:
wait_for_completion(&instance->thread_exited);
If CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled, missing firmware
causes request_firmware() to fall back to sysfs/udevd. This creates a
circular dependency during disconnect:
1. usb_disconnect() holds device_lock(&udev->dev).
2. usbatm_usb_disconnect() waits for instance->thread to exit.
3. instance->thread waits for request_firmware() sysfs fallback.
4. udevd receives the firmware uevent and attempts to read sysfs
attributes (e.g. serial), blocking on device_lock(&udev->dev).
Furthermore, the fallback wait uses wait_for_completion_killable_timeout(),
which ignores the non-fatal SIGTERM signal sent by usbatm_usb_disconnect().
Because speedtch and cxacru probe multiple candidate firmware files
sequentially, each file stalls for the 60-second fallback timeout,
triggering hung task timeouts (>120s) reported by syzbot.
Switch to request_firmware_direct() to probe firmware files directly from
the filesystem without falling back to user-mode helper.
Cc: stable+noautosel@kernel.org # untested fix to a driver init path race
Reported-by: syzbot+9ca2c9f85bd8b5e46516@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9ca2c9f85bd8b5e46516
Signed-off-by: Matvey Valigura <valigurasm@gmail.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260924050654.15347-1-valigurasm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stanislav Fomichev says:
====================
net: consolidate devmem net_iov freelist and DMA handling
Follow up on the recently merged devmem gen_pool removal by consolidating
devmem's net_iov freelist and DMA-address handling.
- move devmem freelist to index-based approach with push/pop helpers
- switch devmem to public memory-provider helpers and reject DMA
addresses that cannot be represented
- decode stored DMA addresses for TX on 32-bit systems with 64-bit
dma_addr_t
====================
Link: https://patch.msgid.link/20260925201522.254717-1-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
On 32-bit architectures where dma_addr_t is wider than unsigned long,
page_pool_set_dma_addr_netmem() stores page-aligned DMA addresses shifted
by PAGE_SHIFT. The net_iov branch of __skb_frag_dma_map() adds byte offsets
to the encoded value, so the NIC is programmed with an invalid DMA address.
This can trigger an IOMMU fault or DMA from unintended memory.
Consolidate DMA address encoding, decoding, and representability checks in
netmem helpers. Use the common decoder from the page pool and net_iov TX
paths so both interpret stored addresses consistently.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260925201522.254717-4-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Use public memory-provider helpers for DMA address storage and page-pool
association instead of open-coding page_pool state and accounting.
Zero the net_iov array because net_mp_niov_set_page_pool() ORs
PP_SIGNATURE into pp_magic. Reject DMA addresses that cannot be
represented in net_iov metadata.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260925201522.254717-3-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Move devmem's freelist to an index-based approach similar to io_uring.
This halves the memory requirements for the freelist.
Reviewed-by: Mina Almasry <almasrymina@google.com>
Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260925201522.254717-2-sdf@fomichev.me
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The Marvell PHY driver consumes marvell,reg-init as one or more
<page register mask value> tuples. Define the property so dtbs_check
validates the existing board descriptions.
Existing users have no compatible or just "ethernet-phy-ieee802.3-c22"
so this has to go into the generic ethernet-phy.yaml schema. Marking it
deprecated both for that reason and because opaque register
initialization values are discouraged in DT.
Assisted-by: LLM
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260925140410.1157036-2-robh@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
sock_sendmsg_nosec() runs in syscall context but calls BUG_ON() if
proto_ops->sendmsg() returns -EIOCBQUEUED. Crashing the kernel on an
unexpected return value is dangerous for production workloads.
This risk is real: any signed integer overflow in a sendmsg handler
that returns 0xfffffdef (-529, -EIOCBQUEUED) triggers this BUG_ON. In
one month, two such bugs were reported in PF_PACKET, reachable by
a local user with CAP_NET_RAW in a user namespace:
- Commit 73e594c19b ("af_packet: Don't cast tpacket_hdr.tp_len to int
in tpacket_parse_header().")
- In review ("net/packet: prevent TX_RING byte count overflow")
https://lore.kernel.org/netdev/20260925124829.6595-1-ilkka.lappetelainen@gmail.com/
Replace the BUG_ON with DEBUG_NET_WARN_ON_ONCE() to retain debug and
syzbot coverage, and return -EIO so that -EIOCBQUEUED does not leak to
userspace or trigger the BUG_ON(ret == -EIOCBQUEUED) in VFS callers of
sock_write_iter() such as new_sync_write().
Failing gracefully is safe because the original reason for the BUG_ON
is gone. It was added in commit 599bd19bdc ("fs: don't allow to complete
sync iocbs through aio_complete") and commit d8725c86ae ("get rid of the
size argument of sock_sendmsg()") to prevent an async completion from
corrupting a caller's on-stack kiocb. Commit 1b78414047 ("net: Remove
iocb argument from sendmsg and recvmsg") removed that on-stack kiocb.
More recently commit fcc77d33a3 ("net: Remove support for AIO on
sockets") removed socket AIO support entirely.
Signed-off-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20260928020420.3097018-1-willemdebruijn.kernel@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Callers of __pktgen_NN_threads() only check whether a pktgen_dev was
found. Returning the pointer exposes it outside the helper even though
neither caller uses the object itself.
Return bool instead and keep the pktgen_dev pointer internal to the
helper.
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Reviewed-by: Ivy Lopez <skunkolee@gmail.com>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260927135406.3969970-1-nicoyip.dev@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fix two invalid name-prefixes in the specs:
- It's PHY_UPSTREAM_MAC, not PHY_UPSTREAMMAC.
- It's PHY_UPSTREAM_PHY, not PHY_UPSTREAMPHY.
- It's OVPN_MODE_P2P, not OVPN_MODEP2P.
- It's OVPN_MODE_MP, not OVPN_MODEMP.
CC: Andrew Lunn <andrew@lunn.ch>
CC: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-10-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fix a typo in the naming of a cls-flags constant.
The correct name for TCA_CLS_FLAGS_NOT_IN_HW is "not-in-hw",
not "not-in-nw".
CC: Jamal Hadi Salim <jhs@mojatatu.com>
CC: "Jonas Köppeler" <j.koeppeler@tu-berlin.de>
Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-9-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Use the correct naming for enum members:
- In feature-flags, it's NL80211_FEATURE_ND_RANDOM_MAC_ADDR,
so "nd-random-mac-addr", not "no-random-mac-addr".
- In commands, it's NL80211_CMD_UNEXPECTED_4ADDR_FRAME,
so "unexpected-4addr-frame", not "unexpected-4-addr-frame".
CC: Joe Damato <joe@dama.to>
CC: Shaikh Kamaluddin <shaikhkamal2012@gmail.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-8-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Correct the values for enum ethtool_module_fw_flash_status:
- ETHTOOL_MODULE_FW_FLASH_STATUS_STARTED is 1, not 0.
- ETHTOOL_MODULE_FW_FLASH_STATUS_IN_PROGRESS is 2, not 1.
- ETHTOOL_MODULE_FW_FLASH_STATUS_COMPLETED is 3, not 2.
- ETHTOOL_MODULE_FW_FLASH_STATUS_ERROR is 4, not 3.
Re-align the YNL spec by explicitly setting the first value to 1.
CC: Andrew Lunn <andrew@lunn.ch>
CC: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-7-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
enum ethtool_c33_pse_ext_state is misaligned with YNL:
- ETHTOOL_C33_PSE_EXT_STATE_OVLD_DETECTED is 6.
- ETHTOOL_C33_PSE_EXT_STATE_PD_DLL_POWER_TYPE is 7 (not in YNL).
- ETHTOOL_C33_PSE_EXT_STATE_POWER_NOT_AVAILABLE is 8, not 7.
- ETHTOOL_C33_PSE_EXT_STATE_SHORT_DETECTED is 9, not 8.
In commit c8149739af ("netlink: specs: Expand the PSE netlink command
with C33 new features") the PD_DLL_POWER_TYPE enum member was skipped,
leading incorrect values for power-not-available and short-detected.
As PD_DLL_POWER_TYPE is not used, then skip it, but set the value for
power-not-available to 8.
CC: Andrew Lunn <andrew@lunn.ch>
CC: Oleksij Rempel <o.rempel@pengutronix.de>
Reviewed-by: Kory Maincent <kory.maincent@bootlin.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-6-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The correct type for resource-scope is flags, not enum:
- DEVLINK_RESOURCE_SCOPE_DEV is _BITUL(0) aka. 1, not 0.
- DEVLINK_RESOURCE_SCOPE_PORT is _BITUL(1) aka. 2, not 1.
This patch also removes "enum-as-flags", as it is now redundant,
these changes does not change the generated policy.
Before this patch, this generated devlink-user.c function call:
devlink_resource_scope_str(DEVLINK_RESOURCE_SCOPE_DEV) returned "port",
not "dev", as it didn't use ffs() to convert the value.
CC: Jiri Pirko <jiri@resnulli.us>
CC: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-5-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Correct the names of `enum net_device_flags` constants:
- IFF_POINTOPOINT should be "pointopoint", not "point-to-point".
- IFF_NOTRAILERS should be "notrailers", not "no-trailers".
- IFF_NOARP should be "noarp", not "no-arp".
- IFF_ALLMULTI should be "allmulti", not "all-multi".
- IFF_AUTOMEDIA should be "automedia", not "auto-media".
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-4-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
YNL enum ifla-inet6-stats got misaligned with C, as two commits
reordered the enum.
In commit b4a11b2033 ("net: fix IPSTATS_MIB_OUTPKGS increment in
OutForwDatagrams."), IPSTATS_MIB_OUTPKTS was renamed to _OUTREQUESTS
and a new _OUTPKTS was as the last entry.
In commit 652e2c7778 ("net: reorganize IP MIB values (II)"), the
IPSTATS_MIB_* enum was reorganized for data locality.
Neither of these commits updated the YNL spec.
This changed uAPI, as IPSTATS_MIB_* is used as indicies in an u64 array,
exported as IFLA_INET6_STATS by inet6_fill_ifla6_stats_attrs().
This patch updates ifla-inet6-stats to reflect both of these commits.
Next time we want to reorganize these counters we should properly apply
mapping as to maintain the current order on the netlink side.
While touching these entries, also remove the dash from ect{0,1}-pkts,
so that they align with the C naming.
This pre-existing issue was identified by Sashiko during review of
commit 2b0aecb7b2 ("netlink: specs: rt-link: add accept-ra-min-lft").
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260831093458.472180-1-ast%40fiberby.net
CC: Heng Guo <heng.guo@windriver.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-3-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The YNL "ipv4-devconf" enum is misaligned with the IPV4_DEVCONF_* enum.
IPV4_DEVCONF_* starts at 1, ipv4-devconf starts at 0.
$ git grep -B3 -A1 IPV4_DEVCONF_FORWARDING include/
inc../uapi/linux/ip.h-/* index values for the variables in ipv4_devconf */
inc../uapi/linux/ip.h-enum
inc../uapi/linux/ip.h-{
inc../uapi/linux/ip.h: IPV4_DEVCONF_FORWARDING=1,
inc../uapi/linux/ip.h- IPV4_DEVCONF_MC_FORWARDING,
Re-align the YNL spec by explicitly setting the first value to 1.
This misalignment has been present since the spec was added in
commit b2f63d904e ("doc/netlink: Add spec for rt link messages").
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260925213918.204767-2-ast@fiberby.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Dismantle two netns holding a dummy and a netkit pair registered in
opposite order. unregister_netdevice_many_notify() takes the instance
locks of all the devices at once, nesting the two kinds of devices one
way for the first netns and the other way for the second. With lockdep
enabled this used to trigger a circular locking report.
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260926041832.1649675-2-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
netdev_lockdep_set_classes() puts dev->lock in a separate lockdep class,
by type (netkit vs dummy etc), with the intent of keeping the instance
locks of individual devices as independent from each other as possible.
In practice it does the opposite. lockdep only calls the cmp_fn for locks
of the same class, so netdev_lock_cmp_fn() never gets a say when devices
from different classes are nested. Instead lockdep records a dependency
between the classes, and reports a circular locking problem as soon as
the nesting happens the other way round, e.g. when devices are unregistered
in a batch.
======================================================
WARNING: possible circular locking dependency detected
7.3.0-rc3+ #26 Not tainted
------------------------------------------------------
kworker/u256:1/326 is trying to acquire lock:
ff110000104fce28 (&dev_instance_lock_key#6){+.+.}-{4:4}, at:
unregister_netdevice_many_notify+0x1141/0x1c30
but task is already holding lock:
ff110000127f2e28 (&dev_instance_lock_key#7){+.+.}-{4:4}, at:
unregister_netdevice_many_notify+0x1141/0x1c30
-> #1 (&dev_instance_lock_key#7){+.+.}-{4:4}:
__lock_acquire+0x767/0xd60
lock_acquire.part.0+0xd0/0x260
__mutex_lock+0x17d/0x1f20
unregister_netdevice_many_notify+0x1141/0x1c30
default_device_exit_batch+0x3ee/0x520
ops_undo_list+0x2cc/0x8a0
cleanup_net+0x442/0x9c0
process_one_work+0x951/0x1ab0
worker_thread+0x5a6/0xd10
kthread+0x339/0x430
ret_from_fork+0x4a4/0x6f0
ret_from_fork_asm+0x1a/0x30
-> #0 (&dev_instance_lock_key#6){+.+.}-{4:4}:
check_prev_add+0xeb/0xe60
validate_chain+0x598/0x900
__lock_acquire+0x767/0xd60
lock_acquire.part.0+0xd0/0x260
__mutex_lock+0x17d/0x1f20
unregister_netdevice_many_notify+0x1141/0x1c30
default_device_exit_batch+0x3ee/0x520
ops_undo_list+0x2cc/0x8a0
cleanup_net+0x442/0x9c0
process_one_work+0x951/0x1ab0
worker_thread+0x5a6/0xd10
kthread+0x339/0x430
ret_from_fork+0x4a4/0x6f0
ret_from_fork_asm+0x1a/0x30
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&dev_instance_lock_key#7);
lock(&dev_instance_lock_key#6);
lock(&dev_instance_lock_key#7);
lock(&dev_instance_lock_key#6);
*** DEADLOCK ***
locks held by kworker/u256:1/326: 6, last CPU#6:
#0: ff11000001c2b540 ((wq_completion)netns){+.+.}-{0:0}, at:
process_one_work+0x117c/0x1ab0
#1: ffa0000001a3fd18 (net_cleanup_work){+.+.}-{0:0}, at:
process_one_work+0x8ce/0x1ab0
#2: ffffffff98f53288 (pernet_ops_rwsem){++++}-{4:4}, at:
cleanup_net+0xc1/0x9c0
#3: ffffffff98f6ede0 (rtnl_mutex){+.+.}-{4:4}, at:
default_device_exit_batch+0x92/0x520
#4: ff1100001321ae28 (&dev_instance_lock_key#7){+.+.}-{4:4}, at:
unregister_netdevice_many_notify+0x1141/0x1c30
We can't put all devices in the same class, that'd be too permissive.
netdev_nl_queue_create_doit() and netdev_nl_bind_tx_doit() lock
a virtual device (netkit) before a physical device, without rtnl_lock.
We can never allow locking in the opposite order even under rtnl_lock.
cmp_fn cannot enforce this sort of rule: lockdep keys its chain cache on
the sequence of lock classes, so with a single class both orders hash
to the same chain and only whichever happens first is validated.
netdev_lock_cmp_fn() itself has another source of false-negatives.
lockdep calls it from within __lock_acquire(), with the recursion counter
already raised, so lock_is_held_type() always returns LOCK_STATE_UNKNOWN,
which means lockdep_rtnl_is_held() always returns true / held.
Use rtnl_is_locked(), which looks at the mutex directly and does
work from that context. We may still miss a bad case if some other
process is holding the lock, not us, but that's better than the
100% false negative rate of lockdep_rtnl_is_held().
One last thing, lockdep compares the address of the cmp function,
so it can't be a static inline - that would work similarly to having
separate classes, again. Move it to a source file.
Tested by nesting two instance locks from a module, one scenario per boot
since the first splat turns debug_locks off:
first second rtnl reported
-----------------------------------------------------------
virt->virt no recursive locking
virt->virt yes -
virt->phys no -
virt->phys yes -
phys->virt no - (records the edge)
phys->virt yes - (records the edge)
phys->phys no recursive locking
phys->phys yes -
virt->phys phys->virt no, no circular dependency
virt->phys phys->virt no, yes circular dependency
virt->phys phys->virt yes, no circular dependency
virt->phys phys->virt yes, yes circular dependency
phys->virt virt->phys no, no circular dependency
phys->virt virt->phys yes, yes circular dependency
virt->virt virt->virt yes, no recursive locking
phys->phys phys->phys yes, no recursive locking
(netkit and dummy stood in for the virtual devices, virtio_net and
netdevsim for the physical ones.)
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Link: https://patch.msgid.link/20260926041832.1649675-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Daniel Zahka says:
====================
eth: mpnic: initial support for Meta Platforms NIC
Meta Platforms NIC is the second-generation NIC from Meta. There are
quite a few high-level similarities to fbnic, but all of the CSRs and
descriptors have been reshuffled, and new features have been added.
Since the device is sufficiently different from fbnic, and the design of
our FW is minimal, we have decided a separate driver is appropriate.
Major new features compared to fbnic will take a while to land. This
series includes only the bare-bones Tx/Rx datapath.
Our high-level patch sequence and plan for the upcoming series is:
1. Core datapath (this series)
2. Basic offloads, RSS, and counters
3. Firmware mailbox support
4. Base ethtool operations
This patch series was prepared in part with these LLM prompts:
https://github.com/kuba-moo/ai-prompts/blob/main/driver-upstreaming-prompts.md
The prompts were used to distill our fully-featured OOT driver into this
minimal Tx/Rx capable upstream driver. We then performed human review on
the output to create this posting. Jakub has made the prompts public in
case people would like to take a look.
v1: https://lore.kernel.org/r/20260922-linux-mpnic-v1-0-236844f53072@gmail.com
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
====================
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-0-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
A frame arrives as a run of completion descriptors: one header
address/length descriptor, one address/length descriptor per payload
page, and a metadata descriptor that closes the frame. The frame is
assembled in an xdp_buff as the descriptors come in and handed to the
stack when the metadata descriptor arrives.
A page holds several frames, so rather than taking a reference per
frame the driver takes a batch of references when it starts handing the
page out and returns whatever is left over once the device moves on to
the next one. Payload fragments that turn out to be contiguous within
one page are merged so that a frame spread over a page does not eat one
skb fragment slot per descriptor.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-8-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The Rx side of a queue triad is a header queue, a payload queue and a
completion queue. With HDS not active yet, frames are split between the
two buffer queues at a fixed header boundary: everything up to 1536
bytes lands in the header page, the rest goes to the payload page. Small
frames therefore never touch the payload queue, and several of them
share one header page.
The device is set to leave headroom and tailroom for XDP and
skb_shared_info respectively.
Both queues draw from one page pool per triad and post buffer
descriptors to the device in batches.
Even though we do not support XDP yet, use the XDP APIs for tracking
pre-skb buffers. The XDP buffer handling helpers save us from
reimplementing the same logic in the driver.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-7-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Register the network interface and let it transmit skbs.
The typical TWQ descriptor sequence for an skb is: 1 primary metadata,
followed by 0 or more non-last address + length (A/L) descriptors,
terminated by an always present last A/L descriptor.
The device does not write a Tx completion unless it is requested in the
primary metadata desc. The xmit path sets this bit when the stack does
not report netdev_xmit_more(). This can create a problem if the last
packet in a burst is dropped by the driver. To deal with that case, the
driver latches the last metadata for which a completion was not
requested, and uses this to request a completion and flush queued
packets when one is dropped.
There is no link state yet, so carrier follows the administrative
state.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-6-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Point the hardware at the descriptor rings and provide functions for
turning the Tx queues on and off.
Teardown has to wait for the DMA engines to go idle before the ring
memory can be freed: disabling a queue only stops the device picking up
new work, it does not tell us that the work already fetched has been
retired. Each block exposes an idle bitmap per queue, and every one of
the four blocks a packet passes through on its way out has to report
idle before the descriptors are safe to free.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-5-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Queues come in triads of two work queues and one completion queue. The
Tx triad only uses the first work queue for now, the second one will be
used for the XDP ring later.
Add the ring structures, the per NAPI vector allocation of triads,
descriptor memory and interrupts, and the completion processing. The
completion queue does not report one entry per packet, it reports a
work queue head, so a single completion can release many packets.
Nothing enables the queues in hardware or submits anything to them yet,
that comes with the next two changes.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-4-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Request one vector for FW generated interrupts and then one vector per
CPU to use for the completion queues. Nothing requests a handler yet,
that comes with the NAPI vectors.
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-3-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Perform one time register initialization during mpnic_probe(). These CSR
settings are either static configs that only need to be set once, or
pulses for zeroizing on chip SRAMs, which also only need to be done
once.
This initialization is idempotent and does not require any matching
deinitialization in the remove path. We can unbind and re-bind the
driver and perform the same initialization without problems.
Signed-off-by: Mohsin Bashir <mohsin.bashr@gmail.com>
Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Link: https://patch.msgid.link/20260924-linux-mpnic-v2-2-4badc9b58b9e@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
