airoha_alloc_gdm_device() initializes the txq_lock[] array iterating
over ARRAY_SIZE(dev->txq_lock). ARRAY_SIZE() expands to
sizeof(dev->txq_lock) / sizeof((dev->txq_lock)[0]), but on UP builds
(CONFIG_SMP unset, CONFIG_DEBUG_SPINLOCK unset) arch_spinlock_t is an
empty struct, so sizeof(spinlock_t) is zero and the expression is a
compile-time division by zero (undefined behavior), reported by clang
as "division by zero is undefined [-Wdivision-by-zero]".
Since the array is statically sized with AIROHA_NUM_NETDEV_TX_RINGS,
use the named constant as loop bound instead of ARRAY_SIZE().
Fixes: 78a35725e5 ("net: airoha: defer GDM3/GDM4 WAN mode and GDM2 loopback to QoS offload")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607311850.6p0ZUVq4-lkp@intel.com/
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://patch.msgid.link/20260731-airoha-spinlock-array-fix-v1-1-863a7e239a5f@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
IFLA_MACVLAN_BC_QUEUE_LEN accepts any u32 and becomes
port->bc_queue_len_used, the only bound on port->bc_queue. rtnetlink checks
CAP_NET_ADMIN against the target netns only, so a user who unshares a
user+net namespace, creates a veth and puts a macvlan on it can set the
backlog to 0xffffffff and flood broadcast frames until the host dies:
Out of memory: Killed process 141 (su) UID:0
Kernel panic - not syncing: System is deadlocked on memory
Call Trace:
vpanic (kernel/panic.c:650)
panic (kernel/panic.c:787)
out_of_memory (mm/oom_kill.c:1166)
__alloc_frozen_pages_noprof (mm/page_alloc.c:4914)
alloc_pages_mpol (mm/mempolicy.c:2490)
folio_alloc_noprof (mm/mempolicy.c:2591)
filemap_fault (mm/filemap.c:3565)
A fixed upper bound does not work. Deployments carrying 600-800 real-time
audio streams run bc_queue_len=100000, and no constant serves both cases:
the queue counts skbs, not bytes, and the frame size is attacker-chosen too
(up to ETH_MAX_MTU on a veth the caller creates).
Gate the elevated range on CAP_NET_ADMIN in the initial user namespace
instead. A backlog of that size is a host-wide tuning decision, and an
unprivileged owner of a namespace it created itself should not be able to
make it; privileged configurations keep working unchanged..
Cc: stable+noautosel@kernel.org # local DoS by userns are a dime a dozen
Reported-by: AutonomousCodeSecurity@microsoft.com
Link: https://lore.kernel.org/r/20260706212556.3199234-1-xmei5@asu.edu
Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
Link: https://patch.msgid.link/20260729200621.2521588-1-xmei5@asu.edu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kuniyuki Iwashima says:
====================
geneve: Support per-netns device unregistration.
Patch 1 is a prep patch to make patch 2 clean, which
adds a per-netns mutex for geneve linked lists.
Patch 3 supports per-netns netdev unreg by using
unregister_netdevice_queue_net().
====================
Link: https://patch.msgid.link/20260731164612.2148830-1-kuniyu@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
geneve_exit_rtnl_net() iterates geneve devices whose sockets
are in the dying netns and queues them for destruction.
So the devices may reside in different netns.
Let's use unregister_netdevice_queue_net() to support per-netns
device unregistration.
list_del() is changed to list_del_init() to avoid queueing the
same device twice.
Even after geneve_exit_rtnl_net() queues a cross-netns geneve
device, geneve_dellink() can be called concurrently for it.
In such a case, __rtnl_net_unlock() will perform the unregistration.
Note that geneve uses register_pernet_subsys() instead of _device(),
so default_device_exit_batch() guarantees that the async per-netns
works are flushed before ->exit().
Tested:
1. Create geneve device across two netns.
# ip netns add ns1
# ip netns add ns2
# ip -n ns1 link add geneve0 link-netns ns2 type geneve external
2. Run bpftrace to check that geneve_uninit() is called between
->exit_rtnl() and ->exit().
# bpftrace -e '#include <linux/netdevice.h>
kprobe:geneve_uninit {
$dev = (struct net_device *)arg0;
printf("PID: %d | DEV: %s%s\n", pid, $dev->name, kstack());
}
kprobe:geneve_exit_rtnl_net,
kprobe:geneve_exit_net {
printf("PID: %d%s\n", pid, kstack());
}'
3. Remove the netns where the geneve socket resides
# ip netns del ns2
Now, we can see geneve0 is unregistered by per-netns work
instead of cleanup_net() and it finishes before ->exit() to
avoid WARN_ON_ONCE(!list_empty(&gn->sock_list)) there.
PID: 571
geneve_exit_rtnl_net+5
ops_undo_list+702
cleanup_net+1122
process_scheduled_works+2538
...
PID: 1047 | DEV: geneve0
geneve_uninit+5
unregister_netdevice_many_notify+7129
unregister_netdevice_many_net+1050
rtnl_net_work_func+136
process_scheduled_works+2538
...
PID: 571
geneve_exit_net+5
ops_undo_list+1064
cleanup_net+1122
process_scheduled_works+2538
...
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260731164612.2148830-4-kuniyu@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
struct geneve_dev.net is the netns where the backend geneve
socket resides.
struct geneve_dev is linked to the geneve_net.geneve_list of
the socket's netns.
During netns dismantle or module unload, geneve_exit_rtnl_net()
iterates the list and queues devices for destruction regardless
of devices' netns.
Moreover, a socket can be shared by multiple geneve devices in
different netns, and geneve_open() and geneve_stop() modify
geneve_sock.vni_list and geneve_net.sock_list.
Thus, once RTNL is removed, the three lists can be modified
concurrently from different netns due to device removal and
link-up/down.
Let's protect them with per-netns mutex.
geneve_newlink() is still protected by rtnl_net_lock()s, so
acquiring gn->lock twice in geneve_find_dev() and
geneve_configure() is not a problem.
Note that udp_tunnel_notify_add_rx_port() is moved outside of
the mutex, otherwise gn->lock -> utn->lock ordering would trigger
AB-BA deadlock in geneve_offload_rx_ports(), which acquires
gn->lock under utn->lock. Even without gn->lock, geneve_sock_add()
and geneve_offload_rx_ports() are still serialised with (per-netns)
RTNL, so there is no race.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260731164612.2148830-3-kuniyu@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Currently, geneve->sock[46].hlist[46] is unliked from
geneve_sock.vni_list in geneve_stop() and geneve_sock.refcnt is
decremented for each socket later in __geneve_sock_release().
The following patch will introduce a mutex in geneve_net to
protect geneve_sock.{refcnt,vni_list}.
However, udp_tunnel_notify_del_rx_port() must be outside of the
lock to avoid AB-BA deadlock.
To make the change cleaner, let's move hlist_del_init_rcu()
from geneve_stop() to __geneve_sock_release().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Link: https://patch.msgid.link/20260731164612.2148830-2-kuniyu@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Dipayaan Roy says:
====================
net: mana: add ethtool private flag for full-page RX buffers
On some ARM64 platforms with 4K PAGE_SIZE, utilizing page_pool
fragments for allocation in the RX refill path (~2kB buffer per
fragment) causes 15-20% throughput regression under high connection
counts (>16 TCP streams at 180+ Gbps). Using full-page buffers on
these platforms shows no regression and restores line-rate
performance.
This behavior is observed on a single platform; other platforms
perform better with page_pool fragments, indicating this is not a
page_pool issue but platform-specific.
This series adds an ethtool private flag "full-page-rx" to let the
user opt in to one RX buffer per page:
ethtool --set-priv-flags eth0 full-page-rx on
There is no behavioral change by default. The flag can be persisted
via udev rule for affected platforms.
====================
Link: https://patch.msgid.link/20260729063347.3388035-1-dipayanroy@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
On some ARM64 platforms with 4K PAGE_SIZE, page_pool fragment
allocation in the RX refill path can cause 15-20% throughput
regression under high connection counts (>16 TCP streams).
Add an ethtool private flag "full-page-rx" that allows the user to
force one RX buffer per page, bypassing the page_pool fragment path.
This restores line-rate (180+ Gbps) performance on affected platforms.
Usage:
ethtool --set-priv-flags eth0 full-page-rx on
There is no behavioral change by default. The flag must be explicitly
enabled by the user or udev rule.
The existing single-buffer-per-page logic for XDP and jumbo frames is
consolidated into a new helper mana_use_single_rxbuf_per_page() which
is now the single decision point for both the automatic and
user-controlled paths.
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Signed-off-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
Link: https://patch.msgid.link/20260729063347.3388035-3-dipayanroy@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Maxime Chevallier says:
====================
net: stmmac: Cleanup rx coalescing computation when using RIWT
Currently when configuring interrupt coalescing on devices that relies
on the Receive Interrupt Watchdog Timer feature of dwmac, the
computation of the RIWT timings leads to off-by-one values when
reporting the timings back to userspace.
RIWT works by arming a watchdog timer upon receiving frames with the RI
bit not set in the descriptor. The timer duration is expressed in units
of 256 stmmac clock ticks, and therefore requires a bit of computation
to derive it :
riwt = (rx_usecs * n_clk_ticks_per_usec) / 256
and conversely
rx_usecs = (riwt * 256) / n_clk_ticks_per_usec
This computation as-is leads to a consistent off-by-one when setting
then getting back the rx-usecs value due to rounding errors (by truncation):
ethtool -C eth1 rx-usecs 42
ethtool -c eth1
-> reports rx-usecs: 41
Let's use DIV_ROUND_CLOSEST instead for the computations. It does have
one side effect, the accepted boundaries for rx-usecs also shifts by one
now, going from [16us, 246us] to [15us, 245us]. For that reason, I'm not
targeting the net tree here, and it's overall a very small issue.
====================
Link: https://patch.msgid.link/20260802114015.214212-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When reading the rx-usecs coalescing parameters on a dwmac variant that
uses the RIWT for RX interrupt coalescing, we convert the riwt value to
usecs :
- One riwt cycle is 256 clock ticks, we compute how many ticks in $riwt
cycles
- divide that by how many ticks in a microsecond, and we get the
rx-usecs.
The opposite computation is done when setting the rx-usecs param.
Because of the 256 ratio, we're subjected to off-by-one errors in the
value read-back, which can be reliably measured on i.mx8MP :
$ ethtool -C eth1 rx-usecs 102
$ ethtool -c eth1
Coalesce parameters for eth1:
[...]
rx-usecs: 101
Let's be more explicit about the rounding for the riwt to usec
computations by using DIV_ROUND_CLOSEST, which solves the off-by-one.
This does change the boundaries of accepted rx-usecs parameters, as the
previously accepted values were in the 16-246 us range, and now fall
into the 15-245 range on imx8mp.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260802114015.214212-3-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Receive Interrupt Watchdog Timer is an RX interrupt coalescing mechanism
used by some variants of dwmac. It allows waiting a bit before
triggering the rx interrupts, allowing for batch processing.
The RIWT is configured with a granularity of 256 stmmac clk ticks. Let's
add a comment for that and wrap the raw "1000000" into USEC_PER_SEC, as
we're computing "how many clock cycles in one microsec" with that step.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260802114015.214212-2-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add a reconfig_tx_stall test that detects the possibility of a TX stall
after ring reconfiguration. The key observation is that drivers using
netif_tx_start_all_queues() are prone to experiencing a stall when
reconfiguration completes compared to drivers using
netif_tx_wake_all_queues(). start_all_queues only clears DRV_XOFF, while
wake_all_queues also calls __netif_schedule() to kick the qdisc. Without
the kick, qdisc backlog present at reconfig time can stay stuck until a
new trigger is issued.
The test caps the TX ring at 64 entries so it fills quickly, then
installs FQ on a target TX queue and sends UDP packets with SO_TXTIME
scheduled in the future. With napi_defer_hard_irqs slowing completions,
the small ring can fill when FQ releases the burst, leaving requeued
qdisc backlog with no FQ timer to rescue it. A subsequent ring reconfig
must wake the queues to drain the backlog. Simply starting the queues can
leave it stuck.
Some drivers lack backpressure on the TX path and may not be able to
build up the qdisc backlog the test relies on. In that case report an
expected failure (xfail) instead of a hard failure.
Testing on some of the existing drivers: Driver-A does not have the bug,
Driver-B has the bug, Driver-C had the bug but it is fixed now.
Driver-A:
./drivers/net/ring_reconfig.py -t reconfig_tx_stall
TAP version 13
1..1
Sent 1024 SO_TXTIME packets (+100ms)
Backlog before reconfig: 1176378 bytes
ok 1 ring_reconfig.reconfig_tx_stall
Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
Driver-B:
TAP version 13
1..1
Sent 128 SO_TXTIME packets (+100ms)
Sent 128 SO_TXTIME packets (+200ms)
Backlog before reconfig: 148372 bytes
Check| At ./drivers/net/ring_reconfig.py, line 397, in reconfig_tx_stall:
Check| ksft_eq(0, backlog,
Check failed 0 != 148372 qdisc backlog stuck on queue 1 after ring ....
not ok 1 ring_reconfig.reconfig_tx_stall
Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
Driver-C:
TAP version 13
1..1
Sent 128 SO_TXTIME packets (+100ms)
Backlog before reconfig: 192278 bytes
ok 1 ring_reconfig.reconfig_tx_stall
Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
Signed-off-by: Mohsin Bashir <hmohsin@meta.com>
Link: https://patch.msgid.link/20260731021543.1058526-1-mohsin.bashr@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Maxime Chevallier says:
====================
net: stmmac: only use MAC loopback for selftests
stmmac selftests currently use PHY loopback when a PHY is attached, and
fallback to MAC loopback otherwise. PHY loopback however isn't ideal nor
necessary for the tests we are running, that only stress the internal
stmmac features.
Some PHYs bring the carrier state down when in loopback mode, which will
prevent any packet transmission even for ourselves, making selftests
fail for non-stmmac related reasons.
Let's rely only on MAC-side loopback for selftests, making it clear that
any problem found with stmmac selftests are indeed caused by the stmmac
driver, and not external factors.
This was tested on :
- Cyclone V with RGMII link to KSZ9031
- Cyclone V with 1000BaseX
- imx8mp with RGMII link to KSZ9131
- stm32mp157& with RGMII link to RTL8211F
- Allwinner H2+ with an internal PHY
====================
Link: https://patch.msgid.link/20260728155728.1193169-1-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
For flow-control testing in loopback mode, we don't need to ask what the
PHY is currently using as pause/asym settings. The PHY is no longer
involved in selftest, we rely strictly on MAC loopback. We therefore
only need to know if the MAC supports Symmetric pause for the test, as
we exercise both TX and RX pause support in the selftest.
Remove phydev requirement for flowcontrol selftest as well as the
AsymPause requirement.
With that, we can also drop the linux/phy.h include.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://patch.msgid.link/20260728155728.1193169-3-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stmmac selftests validate the internal behaviour of the various IPs,
using local loopback. The current logic is relies on PHY-side local
loopback if a PHY is attached, with a fallback to MAC loopback
otherwise.
However, PHY loopback is currently fragile especially for stmmac that
may require RXC to be provided from the PHY. Some PHYs shutdown RXC
while in loopback, while others will report carrier off when in local
loopback. This also fails when using SFP setup with a module that embeds
a PHY, that may also fail to enter loopback.
MAC loopback is done at the GMII level on dwmac, allowing the internal
to be just as meaningful as PHY-loopback testing.
Let's simplify stmmac selftests by only relying on MAC-side local
loopback, which makes the selftests runnable on a wider HW variety.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260728155728.1193169-2-maxime.chevallier@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Breno Leitao says:
====================
net: convert rawv6, ieee802154, phonet and tls getsockopt to sockopt_t
Now that sockopt_init_user() was already merged, builds a user-backed
sockopt_t from the __user pair. A getsockopt leaf can then take
a sockopt_t behind a thin __user wrapper: the wrapper builds it, calls
the leaf, and writes the length back to optlen. The leaf copies with
copy_to_iter() instead of copy_to_user().
Convert four more leaves the way udp and raw already were: ipv6 raw
(do_rawv6_getsockopt), ieee802154 dgram, phonet pep, and tls
(do_tls_getsockopt and its per-option helpers).
Converting phonet surfaced a pre-existing bug: pep_getsockopt() clamps the
length it reports but writes a full int with put_user(), overrunning an
optval buffer shorter than sizeof(int). It is fixed in its own patch, with
a Fixes: tag, before the phonet conversion, so it can be backported alone.
The last patch adds getsockopt_iter selftest fixtures for rawv6,
ieee802154, phonet and tls, checking the returned length and errno across
exact, oversized and short buffers, an unknown optname and a bad level.
For full motivation about these changes, please check the initial thread
at link
https://lore.kernel.org/all/20260401-getsockopt-v2-0-611df6771aff@debian.org/#t
====================
Link: https://patch.msgid.link/20260729-getsockopt_phase4-v4-0-c44576757c17@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add fixtures for the newly converted getsockopt leaves:
- rawv6: IPV6_HDRINCL / IPV6_CHECKSUM int paths + a SOL_RAW
unknown-optname case that reaches do_rawv6_getsockopt().
- tls: TLS_TX_ZEROCOPY_RO, the TLS_TX crypto_info round-trip at
the base and full cipher sizes, the NULL-optval and short
buffer EINVAL paths, and an unknown optname. It skips when
the kernel lacks TLS or AES-GCM.
Each fixture pins the returned-length / errno semantics across exact,
oversized and short buffers and an unknown optname. The semantics are
unchanged by the sockopt_t conversion, so the tests pass both before and
after the leaf conversions.
ieee802154 and phonet are not covered: their CONFIG options are absent
from the net selftest target config, so the cases would only ever skip.
Acked-by: Rémi Denis-Courmont <remi@remlab.net>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Joe Damato <joe@dama.to>
Signed-off-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260729-getsockopt_phase4-v4-7-c44576757c17@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Continue converting the proto-layer getsockopt callbacks to the sockopt_t
interface, converting do_tls_getsockopt() and its per-option helpers to
take a sockopt_t.
The thin tls_getsockopt() wrapper keeps its __user signature for now: it
builds a user-backed sockopt_t with sockopt_init_user(), calls the helper,
and writes the returned length back to optlen. The helpers use
copy_to_iter() instead of copy_to_user(); the NULL optval check in the
TLS_TX/TLS_RX path is preserved by testing the iterator user buffer.
No functional change.
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Reviewed-by: Joe Damato <joe@dama.to>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Signed-off-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260729-getsockopt_phase4-v4-6-c44576757c17@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Continue converting the proto-layer getsockopt callbacks to the
sockopt_t interface, splitting pep_getsockopt() into a
do_pep_getsockopt() helper that takes a sockopt_t.
The thin pep_getsockopt() wrapper keeps its __user signature for now:
it builds a user-backed sockopt_t with sockopt_init_user(), calls the
helper, and writes the returned length back to optlen. The helper uses
copy_to_iter() instead of copy_to_user(). No functional change.
Acked-by: Rémi Denis-Courmont <remi@remlab.net>
Reviewed-by: Joe Damato <joe@dama.to>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Signed-off-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260729-getsockopt_phase4-v4-5-c44576757c17@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
pep_getsockopt() clamps the reported length to the caller's buffer with
min_t(), but then stores the value with put_user(val, (int __user *)
optval), which always writes sizeof(int) bytes. A getsockopt() call with
an optlen smaller than sizeof(int) thus reports the clamped length yet
writes a full int, one to three bytes past the user buffer.
Write the value with copy_to_user() bounded by len, so at most optlen
bytes are copied, matching the length reported back to userspace.
Fixes: 02a47617cd ("Phonet: implement GPRS virtual interface over PEP socket")
Acked-by: Rémi Denis-Courmont <remi@remlab.net>
Reviewed-by: Joe Damato <joe@dama.to>
Acked-by: Stanislav Fomichev <sdf@fomichev.me>
Signed-off-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260729-getsockopt_phase4-v4-4-c44576757c17@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Zxyan Zhu says:
====================
net: stmmac: Fix PHY attach when custom PCS is in use
This series fixes the issue where stmmac platforms using a custom PCS
via the pcs_init callback fail to probe when no phy-handle is specified
in the device tree.
Patch 1 skips the PHY attach in stmmac when a custom PCS is already
configured via priv->hw->phylink_pcs and phy_addr is invalid, avoiding
the "no phy found" error for platforms that manage link state entirely
through the PCS.
Patch 2 is Russell King's phylink patch that relaxes phylink_expects_phy()
to allow PHYs to be attached in 802.3z inband mode.
====================
Link: https://patch.msgid.link/20260729074237.2624940-1-zxyan0222@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that we have proper decision making for inband mode support which
makes it a "best efforts" feature based on the capabilities of the PHY
and PCS, we can relax whether we expect and permit a PHY to be
attached. This is especially true for the 2500BASE-X case which some
PHYs use without inband on their host side interface for 2.5G speeds,
but use inband for slower speeds switching to SGMII on their host side
interface.
We already have such a case for some qcom-ethqos setups, although
qcom-ethqos overrides phylink's inband settings by accessing the PCS
directly at the moment. This should allow qcom-ethqos to transition to
defaulting to inband when 2500BASE-X or SGMII is specified in its DTS.
Allow PHYs to be attached when inband mode has been specified, which
will be necessary to allow inband mode to be used on qcom-ethqos.
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Zxyan Zhu <zxyan0222@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260729074237.2624940-3-zxyan0222@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When a platform provides a custom PCS via the pcs_init callback,
the MAC's phylink_pcs is already configured. In this case, no
traditional PHY device is needed.
Without this, stmmac_init_phy() falls through to the no-phy-node
path and errors out with "no phy found" when the DT has no
phy-handle for such interfaces.
Skip the PHY attach when priv->hw->phylink_pcs is set and
phy_addr is invalid.
Fixes: f0ef433fc2 ("net: stmmac: introduce pcs_init/pcs_exit stmmac operations")
Signed-off-by: Zxyan Zhu <zxyan0222@gmail.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260729074237.2624940-2-zxyan0222@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netxen_init_module() registers the netdevice and inetaddr notifiers before
registering the PCI driver. If pci_register_driver() fails, the function
returns the error directly and leaves both notifiers registered.
That leaves notifier callbacks installed for a module that failed to load.
Mirror the module exit path on this failure and unregister the notifiers
before returning the error.
Cc: stable+noautosel@kernel.org # untested fix to unlikely driver error path
Signed-off-by: Can Peng <pengcan@kylinos.cn>
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/20260728032046.121631-2-pengcan@kylinos.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In ngbe_irq_enable(), the code subsequently calls wx_intr_enable() to
enable interrupts. However, the preceding comment incorrectly stated
"mask interrupt", which means disabling or blocking interrupts.
This patch corrects the comment to "unmask interrupt" to accurately
reflect the actual behavior of the code. No functional changes are
introduced.
Signed-off-by: Jiawen Wu <jiawenwu@trustnetic.com>
Link: https://patch.msgid.link/147244C2750FF990+20260730065409.50807-1-jiawenwu@trustnetic.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch adds two static helpers in drivers/net/phy/phy-c45.c to
configure and read back master-slave roles for non BASE-T1 Clause 45
PHYs via the 10GBASE-T AN control/status registers.
These helpers are wired into genphy_c45_config_aneg() and
genphy_c45_read_status(). This changes the observable ethtool output
for drivers using the generic c45 read path.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
Link: https://patch.msgid.link/20260728073106.1515-3-javen_xu@realsil.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The XGMAC DMA_MODE register has an INTM field (bits 13:12) that
controls interrupt routing behavior for DMA transfer completion
events:
00 (default): sbd_perch_* are pulse signals, sbd_intr_o is also
asserted for each completion event.
01: sbd_perch_* are level signals, sbd_intr_o is NOT
asserted for packet transfer completion events.
When multi-MSI is enabled, per-channel TX/RX interrupts are expected
to arrive on their dedicated lines. In the default INTM=00 mode,
sbd_intr_o also fires for DMA completion events, but the multi-MSI
handler stmmac_mac_interrupt() only processes MAC-layer events (LPI,
PMT, timestamps) and returns IRQ_NONE for every DMA completion
interrupt, resulting in a continuous stream of unhandled interrupts
on the common IRQ.
Hardware verification with XGMAC and multi-MSI enabled:
INTM=00: 5.4 million common IRQ interrupts in 3 seconds, ~1.8
million IRQ_NONE returns per second.
INTM=01: 0 common IRQ interrupts, per-channel IRQs work normally,
10G line rate works correctly.
Set INTM to mode 1 when multi-MSI is enabled. This matches the
existing GMAC4 implementation.
XGMAC multi-MSI has never worked correctly since it was introduced.
Signed-off-by: Zxyan Zhu <zxyan0222@gmail.com>
Reviewed-by: Qingfang Deng <qingfang.deng@linux.dev>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260729023653.1162763-1-zxyan0222@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Bastien Curutchet says:
====================
net: dsa: microchip: add PTP support for KSZ8463
This series adds PTP support for the KSZ8463.
The KSZ8463 differs quite a lot from other KSZ switches supporting PTP:
it has a different interrupt logic and a different 'PTP engine'.
This third iteration addresses two more Sashiko comments from v2. I
didn't address some other Sashiko comments, I said why in the v2 thread.
Patches 1 to 4 add interrupt support for the KSZ8463
Patches 5 to 10 add the PTP support for the KSZ8463
====================
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-0-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The KSZ8463 switch supports PTP but it's not supported by the driver.
Add L2 two-step PTP support for the KSZ8463. IPv4 and IPv6 layers aren't
supported. Neither is one-step PTP. Use KSZ8463-specific implementations
of the .get_ts_info and .port_hwtstamp_set callbacks.
The pdelay_req and pdelay_resp timestamps share one interrupt bit status
while they're located in two different registers. So introduce
last_tx_is_pdelayresp to keep track of the last sent event type. This
flag is set by the xmit worker right before sending the packet and then
used in the interrupt handler to retrieve the timestamp location.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-10-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Detection of L2 PTP frames needs to be enabled for PTP to work at the L2
layer. The bit enabling this detection is set by default on the switches
currently supported by the driver, but it is unset by default on the
KSZ8463 for which support will be added in upcoming patches.
Explicitly enable the detection of L2 PTP frames for all switches when
PTP is enabled.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-9-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KSZ8463 uses the KSZ9893 DSA TAG driver. However, the KSZ8463 doesn't
use the tail tag to convey timestamps to the host as KSZ9893 does. It
uses the reserved fields in the PTP header instead.
Add a KSZ8463-specific DSA_TAG driver to handle KSZ8463 timestamps.
There is no information in the tail tag to distinguish PTP packets from
others so use the ptp_classify_raw() helper to find the PTP packets and
extract the timestamp from their PTP headers.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-8-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KSZ8795 and KSZ9893 have very similar tag handling in the xmit path,
leading to code duplication.
There are only two differences between the two ksz*_xmit():
- the KSZ8795 doesn't handle priorities between frames
- ksz8795_xmit() directly returns the SKB instead of calling
ksz_defer_xmit(). Yet, ksz_defer_xmit() also returns directly the SKB
if no clone is present inside the SKB. Clones are only created by the KSZ
driver when the PTP feature is enabled. Since KSZ8795 doesn't support
PTP, returning the SKB directly or ksz_defer_xmit() is the same.
The upcoming support for the KSZ8463 also requires a similar xmit().
Gather the common code from ksz8795_xmit() and ksz9893_xmit() into a new
ksz_common_xmit() function that takes three input arguments:
- do_tstamp to tell whether ksz_xmit_timestamp() should be called
- prio to give the priority tag (if any)
- override_mask to give the location of the override bit (if any)
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-7-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Upcoming patch reduces code duplication between KSZ8795 and KSZ9893 by
introducing a common xmit() function. This rework needs the KSZ8795
handlers to be implemented below ksz_defer_xmit().
Do the move now to reduce the noise in next patch.
No functionnal change is intended in this patch.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-6-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In KSZ8463 register's layout, the offset between port 1 and port 2
registers isn't the same in the generic control register area than in
the PTP register area. The get_port_addr() always uses the same offset
so it doesn't work when it's used to access PTP registers.
Adapt the port offset in get_port_addr() when the accessed register is
in the PTP area.
Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
Link: https://patch.msgid.link/20260727-ksz-new-ptp-v3-5-caba39e680e3@bootlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
