* Re: [PATCH net-next v4 00/14] net: sleepable ndo_set_rx_mode
From: Stanislav Fomichev @ 2026-04-02 15:06 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Stanislav Fomichev, netdev, davem, edumazet, pabeni
In-Reply-To: <20260401203831.6deee0e4@kernel.org>
On 04/01, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 18:19:00 -0700 Stanislav Fomichev wrote:
> > sleepable ndo_set_rx_mode
>
> Appears not to be "buildable" on 32bit x86 tho..
> --
> pw-bot: cr
This is what I get for writing unit tests :-(
^ permalink raw reply
* Re: [PATCH net v4 0/2] stmmac crash/stall fixes when under memory pressure
From: Jakub Kicinski @ 2026-04-02 15:05 UTC (permalink / raw)
To: Sam Edwards
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Maxime Coquelin, Alexandre Torgue, Russell King (Oracle),
Maxime Chevallier, Ovidiu Panait, Vladimir Oltean, Baruch Siach,
Serge Semin, Giuseppe Cavallaro, netdev, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260401041929.12392-1-CFSworks@gmail.com>
On Tue, 31 Mar 2026 21:19:27 -0700 Sam Edwards wrote:
> - Changed patch 2 to tolerate dirty stragglers up to a critical threshold (the
> same threshold tolerated by the zero-copy path), to avoid nuisance looping
> during OOM conditions (thanks Jakub)
I meant we need both a threshold, and a delay :(
^ permalink raw reply
* Re: [PATCH net-next] net-timestamp: take track of the skb when wait_for_space occurs
From: Jason Xing @ 2026-04-02 15:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, willemb, netdev, Jason Xing,
Yushan Zhou
In-Reply-To: <CANn89iK-e1=yQhN0t48Cm7ru9cYwKwBw1_DDRcVffX91s4wWNA@mail.gmail.com>
On Thu, Apr 2, 2026 at 10:24 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Thu, Apr 2, 2026 at 1:58 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
> >
> > From: Jason Xing <kernelxing@tencent.com>
> >
> > Tag the skb in tcp_sendmsg_locked() when wait_for_space occurs even
> > though it might not carry the last byte of the sendmsg.
> >
> > If we don't do so, we might be faced with no single timestamp that
> > can be received by application from the error queue. The following steps
> > reproduce this:
> > 1) skb A is the current last skb before entering wait_for_space process
> > 2) tcp_push() pushes A without any tag
> > 3) A is transmitted from TCP to driver without putting any skb carring
> > timestamps in the error queue, like SCHED, DRV/HARDWARE.
> > 4) sk_stream_wait_memory() sleeps for a while and then returns with an
> > error code. Note that the socket lock is released.
> > 5) skb A finally gets acked and removed from the rtx queue.
> > 6) continue with the rest of tcp_sendmsg_locked(): it will jump to(goto)
> > 'do_error' label and then 'out' label.
> > 7) at this moment, skb A turns out to be the last one in this send
> > syscall, and miss the following tcp_tx_timestamp() opportunity before
> > the final tcp_push
> > 8) application receives no timestamps this time
> >
> > The original commit ad02c4f54782 ("tcp: provide timestamps for partial writes")
> > says it is best effort. Now it's time to cover the only potential point
> > to avoid missing record.
> >
> > The side effect is obvious that we might record more than one time for a
> > single send syscall since the skb that we keep track of in this scenario
> > might not be the last one. But tracing more than one skb is not a bad
> > thing since there is an emerging/promissing trend to do a detailed
> > packet granularity monitor.
>
> This is rather weak/lazy, especially if you do not know how long the
> thread is put to sleep?
Thanks for the review!
I actually thought about how to recognize which one should be the last
skb in each send syscall. But it turns out that much more complicated
work needs to be done which hurts the stack and common structures like
tcp_sock. That's why I gave up and instead chose a much simpler way to
minimize the impact.
>
> >
> > Thanks to the great ID, namely, tskey, application that is responsible
> > for the collect/sort of timestamps leverages it to put that record in
> > between two consecutive send syscalls correctly.
> >
> > Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
> > Signed-off-by: Jason Xing <kernelxing@tencent.com>
> > ---
> > net/ipv4/tcp.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> > index 516087c622ad..2db80d75cfa4 100644
> > --- a/net/ipv4/tcp.c
> > +++ b/net/ipv4/tcp.c
> > @@ -1411,9 +1411,11 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
> > wait_for_space:
> > set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
> > tcp_remove_empty_skb(sk);
> > - if (copied)
> > + if (copied) {
> > + tcp_tx_timestamp(sk, &sockc);
> > tcp_push(sk, flags & ~MSG_MORE, mss_now,
> > TCP_NAGLE_PUSH, size_goal);
> > + }
> >
> > err = sk_stream_wait_memory(sk, &timeo);
> > if (err != 0)
>
> I think non blocking model should be used by modern applications,
> especially ones caring about timestamps.
Please note that BPF timestamping has already been merged. It's a
standalone script that monitors all kinds of flows and discovers those
strange/unexpected behaviors. So we normally don't take a look at the
implementation of each application before spotting any exceptions.
Besides, sometimes monitoring the latency of the host doesn't have
much to do with the mode of application. People might want to observe
more deeper into the underlying layer. Right now, without the patch,
the monitor possibly ends up missing the record of this send syscall,
which has been reliably reproduced by Yushan.
>
> This patch has performance implications.
>
> tcp_tx_timestamp() is quite big and was inlined because it had a single caller.
>
> After this patch, it is no longer inlined.
>
> scripts/bloat-o-meter -t vmlinux.before vmlinux.after
> add/remove: 2/0 grow/shrink: 0/1 up/down: 239/-192 (47)
> Function old new delta
> tcp_tx_timestamp - 223 +223
> __pfx_tcp_tx_timestamp - 16 +16
> tcp_sendmsg_locked 4560 4368 -192
> Total: Before=29652698, After=29652745, chg +0.00%
That's right and I really appreciate your recent great effort trying
to mitigate the impact of function calls.
My take is that it is a trade off. Adding one more track of the skb
(which adds a function call) actually doesn't hurt much especially for
this scenario and the last skb scenario. This path basically is not
that hot. There are some left things to be done to improve the
socket/BPF timestamping feature. And I plan to push more patches
(sure, very carefully) to enhance the ability of BPF timestamping to
observe TCP which is inevitable to add some extra functions and if
statements.
I'm wondering if the above makes sense to you.
Thanks,
Jason
^ permalink raw reply
* [PATCH v2] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
From: Julian Braha @ 2026-04-02 14:58 UTC (permalink / raw)
To: davem, peppe.cavallaro, alexandre.torgue, mcoquelin.stm32, linux,
kuba
Cc: netdev, linux-arm-kernel, linux-kernel, Julian Braha,
Russell King (Oracle)
There are already 'if STMMAC_ETH' and 'STMMAC_PLATFORM'
conditions wrapping these config options, making the
'depends on' statements duplicate dependencies (dead code).
I propose leaving the outer 'if STMMAC_PLATFORM...endif' and
'if STMMAC_ETH...endif' conditions, and removing the
individual 'depends on' statements.
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
v2: add back default STMMAC_PLATFORM for DWMAC_GENERIC
Link to v1: https://lore.kernel.org/all/20260331125817.117091-1-julianbraha@gmail.com/
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index c2cb530fd0a2..e3dd5adda5ac 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -20,7 +20,6 @@ if STMMAC_ETH
config STMMAC_SELFTESTS
bool "Support for STMMAC Selftests"
depends on INET
- depends on STMMAC_ETH
default n
help
This adds support for STMMAC Selftests using ethtool. Enable this
@@ -29,7 +28,6 @@ config STMMAC_SELFTESTS
config STMMAC_PLATFORM
tristate "STMMAC Platform bus support"
- depends on STMMAC_ETH
select MFD_SYSCON
default y
help
@@ -336,7 +334,6 @@ config DWMAC_IMX8
config DWMAC_INTEL_PLAT
tristate "Intel dwmac support"
depends on OF && COMMON_CLK
- depends on STMMAC_ETH
help
Support for ethernet controllers on Intel SoCs
@@ -371,7 +368,7 @@ config DWMAC_VISCONTI
help
Support for ethernet controller on Visconti SoCs.
-endif
+endif # STMMAC_PLATFORM
config STMMAC_LIBPCI
tristate
@@ -381,7 +378,7 @@ config STMMAC_LIBPCI
config DWMAC_INTEL
tristate "Intel GMAC support"
default X86
- depends on X86 && STMMAC_ETH && PCI
+ depends on X86 && PCI
depends on COMMON_CLK
depends on ACPI
help
@@ -420,4 +417,4 @@ config STMMAC_PCI
If you have a controller with this interface, say Y or M here.
If unsure, say N.
-endif
+endif # STMMAC_ETH
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v7] selftests: net: add tests for PPP
From: Jakub Kicinski @ 2026-04-02 14:55 UTC (permalink / raw)
To: Andrew Lunn
Cc: Qingfang Deng, Paolo Abeni, Dianne Skoll, Shuah Khan,
David S. Miller, Eric Dumazet, Simon Horman, Felix Maurer,
Sebastian Andrzej Siewior, Matthieu Baerts (NGI0), linux-kernel,
linux-kselftest, linux-ppp, netdev, Paul Mackerras, Jaco Kroon
In-Reply-To: <24aea6cc-d599-4935-8a75-34f38b852d1e@lunn.ch>
On Thu, 2 Apr 2026 16:37:01 +0200 Andrew Lunn wrote:
> > > ln -n /usr/lib64/pppd/2.5.1/pppoe.so /etc/ppp/plugins/rp-pppoe.so
> > >
> > > should solve?
> >
> > Hard links will also work.
> > Alternatively, if your rp-pppoe version is 4.0, you can use the new
> > option `-g` to specify the full path of the pppoe.so plugin.
>
> It should be possible for anybody to run these self tests. So we don't
> want specially crafted setups, but generic setups which will work for
> as many people as possible.
+1 let's try not to tweak the underlying OS.
^ permalink raw reply
* Re: [PATCH] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
From: Russell King (Oracle) @ 2026-04-02 14:48 UTC (permalink / raw)
To: Julian Braha
Cc: Jakub Kicinski, manabian, davem, peppe.cavallaro,
alexandre.torgue, mcoquelin.stm32, netdev, linux-arm-kernel,
linux-kernel
In-Reply-To: <cec5001d-7ac7-4b21-a3d6-6052e1d8fc87@gmail.com>
On Thu, Apr 02, 2026 at 03:47:24PM +0100, Julian Braha wrote:
> Whoops! You're right, good catch. Looks like I've been staring at too
> many 'depends on' lately...
>
> I'll send out a v2 - thanks for reviewing Jakub!
Feel free to keep my r-b.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net v6 4/4] macsec: Support VLAN-filtering lower devices
From: Sabrina Dubroca @ 2026-04-02 14:48 UTC (permalink / raw)
To: Cosmin Ratiu, Paolo Abeni
Cc: netdev, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Simon Horman, Stanislav Fomichev, Shuah Khan,
linux-kselftest, Dragos Tatulea
In-Reply-To: <20260330130130.989236-5-cratiu@nvidia.com>
2026-03-30, 16:01:30 +0300, Cosmin Ratiu wrote:
> @@ -2616,14 +2616,22 @@ static int macsec_update_offload(struct net_device *dev, enum macsec_offload off
> if (!ops)
> return -EOPNOTSUPP;
>
> - macsec->offload = offload;
> -
> ctx.secy = &macsec->secy;
> ret = offload == MACSEC_OFFLOAD_OFF ? macsec_offload(ops->mdo_del_secy, &ctx)
> : macsec_offload(ops->mdo_add_secy, &ctx);
> - if (ret) {
> - macsec->offload = prev_offload;
> + if (ret)
> return ret;
> +
> + /* Remove VLAN filters when disabling offload. */
> + if (offload == MACSEC_OFFLOAD_OFF) {
> + vlan_drop_rx_ctag_filter_info(dev);
> + vlan_drop_rx_stag_filter_info(dev);
> + }
> + macsec->offload = offload;
> + /* Add VLAN filters when enabling offload. */
> + if (prev_offload == MACSEC_OFFLOAD_OFF) {
> + vlan_get_rx_ctag_filter_info(dev);
> + vlan_get_rx_stag_filter_info(dev);
Paolo pointed me to the sashiko review for this patch
https://sashiko.dev/#/patchset/20260330130130.989236-1-cratiu%40nvidia.com
A simple way to trigger this is to do s/VLAN_N_VID/500/ in
nsim_vlan_rx_*_vid.
For example:
echo 1 > /sys/bus/netdevsim/new_device
ip link add link eni1np1 macsec0 type macsec
ip link add link macsec0 macsec0.1 type vlan id 1
ip link add link macsec0 macsec0.1000 type vlan id 1000
ip link set macsec0 type macsec offload mac
cat /sys/kernel/debug/netdevsim/netdevsim1/ports/0/vlan # empty
If this happens on a real device, the VLAN filters will be broken. I'm
not sure what the right behavior would be:
1. reject the request to enable offload
2. switch to promiscuous mode
OTOH maybe we don't need to care, since __netdev_update_features also
(kind of) ignores those errors:
echo 1 > /sys/bus/netdevsim/new_device
ethtool -K eni1np1 rx-vlan-filter off
ip link add link eni1np1 eni1np1.1 type vlan id 1
ip link add link eni1np1 eni1np1.1000 type vlan id 1000
cat /sys/kernel/debug/netdevsim/netdevsim1/ports/0/vlan # empty as expected
ethtool -K eni1np1 rx-vlan-filter on # succeeds
ethtool -k eni1np1 | grep rx-vlan-filter # "rx-vlan-filter: on"
cat /sys/kernel/debug/netdevsim/netdevsim1/ports/0/vlan # still empty because id=1000 was rejected
# and everything got rolled back
ip link add link eni1np1 eni1np1.123 type vlan id 123 # succeeds
cat /sys/kernel/debug/netdevsim/netdevsim1/ports/0/vlan # only "ctag 123"
[at this point running
ip link del eni1np1.1
or
ethtool -K eni1np1 rx-vlan-filter off
will splat because vlan_filter_push_vids did a rollback/never added
id=1, and now we call vlan_kill_rx_filter_info, but that's specific to
this vid limit]
--
Sabrina
^ permalink raw reply
* [PATCH net-next] net: stmmac: qcom-ethqos: set clk_csr
From: Russell King (Oracle) @ 2026-04-02 14:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-stm32,
Mohd Ayaan Anwar, netdev, Paolo Abeni
The clocks for qcom-ethqos return a rate of zero as firmware manages
their rate. According to hardware documentation, the clock which is
fed to the slave AHB interface can range between 50 to 100MHz for
non-RGMII and 30 to 75MHz for boards with a RGMII interfaces.
Currently, stmmac uses an undefined divisor value. Instead, use
STMMAC_CSR_60_100M which will mean we meet IEEE 802.3 specification
since this will generate:
714kHz @ 30MHz
1.19MHz @ 50MHz
1.79MHz @ 75MHz
2.42MHz @ 100MHz
This gives MDC rates within the IEEE 802.3 specification, although the
30MHz case is particularly slow.
Selecting the next lowest divisor, STMMAC_CSR_35_60M, which is /26
will give:
1.15MHz @ 30MHz
1.92MHz @ 50MHz
2.88MHz @ 75MHz (exceeding 802.3 spec)
3.85MHz @ 100MHz (exceeding 802.3 spec)
Unfortunately, this divisor makes the upper bound of both ranges exeed
the IEEE 802.3 specification, and thus we can not use it without knowing
for certain what the current CSR clock rate actually is.
So, STMMAC_CSR_60_100M is the best fit for all boards based on the
information provided thus far.
Link: https://lore.kernel.org/r/acGhQ0oui+dVRdLY@oss.qualcomm.com
Link: https://lore.kernel.org/r/acw1habUsiSqlrky@oss.qualcomm.com
Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index ad3a983d2a08..ac7d6d3e205a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -764,6 +764,12 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
qcom_ethqos_set_sgmii_loopback(ethqos, true);
ethqos_set_func_clk_en(ethqos);
+ /* The clocks are controlled by firmware, so we don't know for certain
+ * what clock rate is being used. Hardware documentation mentions that
+ * the AHB slave clock will be in the range of 50 to 100MHz, which
+ * equates to a MDC between 1.19 and 2.38MHz.
+ */
+ plat_dat->clk_csr = STMMAC_CSR_60_100M;
plat_dat->bsp_priv = ethqos;
plat_dat->set_clk_tx_rate = ethqos_set_clk_tx_rate;
plat_dat->dump_debug_regs = rgmii_dump;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] stmmac: cleanup dead dependencies on STMMAC_PLATFORM and STMMAC_ETH in Kconfig
From: Julian Braha @ 2026-04-02 14:47 UTC (permalink / raw)
To: Jakub Kicinski
Cc: manabian, davem, peppe.cavallaro, alexandre.torgue,
mcoquelin.stm32, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260401185814.45dfc444@kernel.org>
Whoops! You're right, good catch. Looks like I've been staring at too
many 'depends on' lately...
I'll send out a v2 - thanks for reviewing Jakub!
^ permalink raw reply
* [PATCH net 1/1] net: sched: act_csum: validate nested VLAN headers
From: Ren Wei @ 2026-04-02 14:46 UTC (permalink / raw)
To: netdev
Cc: jhs, jiri, davem, edumazet, kuba, pabeni, horms, elibr, yifanwucs,
tomapufckgml, yuantan098, bird, enjou1224z, caoruide123, n05ec
In-Reply-To: <cover.1774892775.git.caoruide123@gmail.com>
From: Ruide Cao <caoruide123@gmail.com>
tcf_csum_act() walks nested VLAN headers directly from skb->data when an
skb still carries in-payload VLAN tags. The current code reads
vlan->h_vlan_encapsulated_proto and then pulls VLAN_HLEN bytes without
first ensuring that the full VLAN header is present in the linear area.
If only part of an inner VLAN header is linearized, accessing
h_vlan_encapsulated_proto reads past the linear area, and the following
skb_pull(VLAN_HLEN) may violate skb invariants.
Fix this by requiring pskb_may_pull(skb, VLAN_HLEN) before accessing and
pulling each nested VLAN header. If the header still is not fully
available, drop the packet through the existing error path.
Fixes: 2ecba2d1e45b ("net: sched: act_csum: Fix csum calc for tagged packets")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Ruide Cao <caoruide123@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/sched/act_csum.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
index 213e1ce9d2da..a9e4635d899e 100644
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -604,8 +604,12 @@ TC_INDIRECT_SCOPE int tcf_csum_act(struct sk_buff *skb,
protocol = skb->protocol;
orig_vlan_tag_present = true;
} else {
- struct vlan_hdr *vlan = (struct vlan_hdr *)skb->data;
+ struct vlan_hdr *vlan;
+ if (!pskb_may_pull(skb, VLAN_HLEN))
+ goto drop;
+
+ vlan = (struct vlan_hdr *)skb->data;
protocol = vlan->h_vlan_encapsulated_proto;
skb_pull(skb, VLAN_HLEN);
skb_reset_network_header(skb);
--
2.34.1
^ permalink raw reply related
* [PATCH net v3] ipvs: fix MTU check for GSO packets in tunnel mode
From: Yingnan Zhang @ 2026-04-02 14:46 UTC (permalink / raw)
To: horms, ja
Cc: pablo, fw, phil, davem, edumazet, kuba, pabeni, netdev, lvs-devel,
netfilter-devel, coreteam, linux-kernel, Yingnan Zhang
Currently, IPVS skips MTU checks for GSO packets by excluding them with
the !skb_is_gso(skb) condition. This creates problems when IPVS tunnel
mode encapsulates GSO packets with IPIP headers.
The issue manifests in two ways:
1. MTU violation after encapsulation:
When a GSO packet passes through IPVS tunnel mode, the original MTU
check is bypassed. After adding the IPIP tunnel header, the packet
size may exceed the outgoing interface MTU, leading to unexpected
fragmentation at the IP layer.
2. Fragmentation with problematic IP IDs:
When net.ipv4.vs.pmtu_disc=1 and a GSO packet with multiple segments
is fragmented after encapsulation, each segment gets a sequentially
incremented IP ID (0, 1, 2, ...). This happens because:
a) The GSO packet bypasses MTU check and gets encapsulated
b) At __ip_finish_output, the oversized GSO packet is split into
separate SKBs (one per segment), with IP IDs incrementing
c) Each SKB is then fragmented again based on the actual MTU
This sequential IP ID allocation differs from the expected behavior
and can cause issues with fragment reassembly and packet tracking.
Fix this by properly validating GSO packets using
skb_gso_validate_network_len(). This function correctly validates
whether the GSO segments will fit within the MTU after segmentation. If
validation fails, send an ICMP Fragmentation Needed message to enable
proper PMTU discovery.
Fixes: 4cdd34084d53 ("netfilter: nf_conntrack_ipv6: improve fragmentation handling")
Signed-off-by: Yingnan Zhang <342144303@qq.com>
---
v3:
- Fixed compilation error (removed extra closing brace in IPv6 function)
- Fixed indentation to match kernel style
v2: https://lore.kernel.org/netdev/20260402030541.27855-1-342144303@qq.com/
v1: https://lore.kernel.org/netdev/20260401152228.31190-1-342144303@qq.com/
---
net/netfilter/ipvs/ip_vs_xmit.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index 3601eb86d..a4ca7cad0 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -111,8 +111,8 @@ __mtu_check_toobig_v6(const struct sk_buff *skb, u32 mtu)
*/
if (IP6CB(skb)->frag_max_size > mtu)
return true; /* largest fragment violate MTU */
- }
- else if (skb->len > mtu && !skb_is_gso(skb)) {
+ } else if (skb->len > mtu &&
+ !(skb_is_gso(skb) && skb_gso_validate_network_len(skb, mtu))) {
return true; /* Packet size violate MTU size */
}
return false;
@@ -232,8 +232,9 @@ static inline bool ensure_mtu_is_adequate(struct netns_ipvs *ipvs, int skb_af,
return true;
if (unlikely(ip_hdr(skb)->frag_off & htons(IP_DF) &&
- skb->len > mtu && !skb_is_gso(skb) &&
- !ip_vs_iph_icmp(ipvsh))) {
+ skb->len > mtu && !ip_vs_iph_icmp(ipvsh) &&
+ !(skb_is_gso(skb) &&
+ skb_gso_validate_network_len(skb, mtu)))) {
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
htonl(mtu));
IP_VS_DBG(1, "frag needed for %pI4\n",
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net-next v3 0/7] Decouple receive and transmit enablement in team driver
From: Jakub Kicinski @ 2026-04-02 14:45 UTC (permalink / raw)
To: Marc Harvey
Cc: Jiri Pirko, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260402-teaming-driver-internal-v3-0-e8cfdec3b5c2@google.com>
On Thu, 02 Apr 2026 06:24:13 +0000 Marc Harvey wrote:
> Allow independent control over receive and transmit enablement states
> for aggregated ports in the team driver.
>
> The motivation is that IEE 802.3ad LACP "independent control" can't
> be implemented for the team driver currently. This was added to the
> bonding driver in commit 240fd405528b ("bonding: Add independent
> control state machine").
>
> This series also has a few patches that add tests to show that the old
> coupled enablement still works and that the new decoupled enablement
> works as intended (4, 5, and 7).
>
> There are three patches with small fixes as well, with the goal of
> making the final decouplement patch clearer (1, 2, and 3).
Sounds like Jiri asked for changes, when you respin could you run
shellcheck and clean up the warnings? We ignore SC2317 SC2329 FWIW
selftests confuse the checker.
^ permalink raw reply
* Re: [PATCH v7 2/3] PCI: AtomicOps: Do not enable without support in root port
From: Gerd Bayer @ 2026-04-02 14:44 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Helgaas, Jay Cornwall, Felix Kuehling, Ilpo Järvinen,
Christian Borntraeger, Niklas Schnelle, Gerald Schaefer,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev, Sven Schnelle,
Leon Romanovsky, Alexander Schmidt, linux-s390, linux-pci,
linux-kernel, netdev, linux-rdma, stable, Gerd Bayer
In-Reply-To: <20260401172757.GA226107@bhelgaas>
On Wed, 2026-04-01 at 12:27 -0500, Bjorn Helgaas wrote:
> On Mon, Mar 30, 2026 at 03:09:45PM +0200, Gerd Bayer wrote:
> > When inspecting the config space of a Connect-X physical function in an
> > s390 system after it was initialized by the mlx5_core device driver, we
> > found the function to be enabled to request AtomicOps despite the
> > system's root-complex lacking support for completing them:
> >
> > 1ed0:00:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx]
> > Subsystem: Mellanox Technologies Device 0002
> > [...]
> > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
> > AtomicOpsCtl: ReqEn+
> > IDOReq- IDOCompl- LTR- EmergencyPowerReductionReq-
> > 10BitTagReq- OBFF Disabled, EETLPPrefixBlk-
> >
> > Turns out the device driver calls pci_enable_atomic_ops_to_root() which
> > defaulted to enable AtomicOps requests even if it had no information
> > about the root port that the PCIe device is attached to.
> >
> > Change the logic of pci_enable_atomic_ops_to_root() to fully traverse the
> > PCIe tree upwards, check that the bridge devices support delivering
> > AtomicOps transactions, and finally check that there is a root port at
> > the end that does support completing AtomicOps.
> >
> > Reported-by: Alexander Schmidt <alexs@linux.ibm.com>
> > Cc: stable@vger.kernel.org
> > Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()")
> > Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
>
> OK, I think this is set to go. It sounds like there are no RCiEPs
> that we need to worry about.
>
> I think pci_enable_atomic_ops_to_root() will end up more readable if
> we check for the Root Port first and explicitly as in the modified
> version. I *think* it's equivalent but can't easily test it. What do
> you think?
At first sight it appears counter-intuitive to test the root-port's
capabilities before traversing the hierarchy - but with the explicit
read of the root port's DEVCAP2, we avoid the dependency to work on the
cap read within the while-loop.
My testing is somewhat limited, too - but I've verified that the
results with your patch (+ a small nit - see below) are the same as
with my version:
- ConnectX-5 Ex on s390: AtomicsOpsCtl: ReqEn-
- ConnectX-6 Dc on x86_64: AtomicsOpsCtl: ReqEn+
>
> commit 2f3f32f2c180 ("PCI: Enable AtomicOps only if Root Port supports them")
> Author: Gerd Bayer <gbayer@linux.ibm.com>
> Date: Mon Mar 30 15:09:45 2026 +0200
>
> PCI: Enable AtomicOps only if Root Port supports them
>
> When inspecting the config space of a Connect-X physical function in an
> s390 system after it was initialized by the mlx5_core device driver, we
> found the function to be enabled to request AtomicOps despite the Root Port
> lacking support for completing them:
>
> 00:00.1 Ethernet controller: Mellanox Technologies MT2894 Family [ConnectX-6 Lx]
> Subsystem: Mellanox Technologies Device 0002
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
> AtomicOpsCtl: ReqEn+
>
> On s390 and many virtualized guests, the Endpoint is visible but the Root
> Port is not. In this case, pci_enable_atomic_ops_to_root() previously
> enabled AtomicOps in the Endpoint even though it couldn't tell whether
> the Root Port supports them as a completer.
>
> Change pci_enable_atomic_ops_to_root() to fail if there's no Root Port or
> the Root Port doesn't support AtomicOps.
>
> Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()")
> Reported-by: Alexander Schmidt <alexs@linux.ibm.com>
> Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Cc: stable@vger.kernel.org
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 135e5b591df4..515f565a4a70 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3675,8 +3675,7 @@ void pci_acs_init(struct pci_dev *dev)
> */
> int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
> {
> - struct pci_bus *bus = dev->bus;
> - struct pci_dev *bridge;
> + struct pci_dev *root, *bridge;
> u32 cap, ctl2;
>
> /*
> @@ -3705,35 +3704,35 @@ int pci_enable_atomic_ops_to_root(struct pci_dev *dev, u32 cap_mask)
> return -EINVAL;
> }
>
> - while (bus->parent) {
> - bridge = bus->self;
> + root = pcie_find_root_port(dev);
> + if (!root)
> + return -EINVAL;
>
> - pcie_capability_read_dword(bridge, PCI_EXP_DEVCAP2, &cap);
> + pcie_capability_read_dword(bridge, PCI_EXP_DEVCAP2, &cap);
You want to read DEVCAP2 on root here, bridge is still unitialized.
> + if ((cap & cap_mask) != cap_mask)
> + return -EINVAL;
>
> + bridge = pci_upstream_bridge(dev);
> + while (bridge != root) {
> switch (pci_pcie_type(bridge)) {
> - /* Ensure switch ports support AtomicOp routing */
> case PCI_EXP_TYPE_UPSTREAM:
> - case PCI_EXP_TYPE_DOWNSTREAM:
> - if (!(cap & PCI_EXP_DEVCAP2_ATOMIC_ROUTE))
> - return -EINVAL;
> - break;
> -
> - /* Ensure root port supports all the sizes we care about */
> - case PCI_EXP_TYPE_ROOT_PORT:
> - if ((cap & cap_mask) != cap_mask)
> - return -EINVAL;
> - break;
> - }
> -
> - /* Ensure upstream ports don't block AtomicOps on egress */
> - if (pci_pcie_type(bridge) == PCI_EXP_TYPE_UPSTREAM) {
> + /* Upstream ports must not block AtomicOps on egress */
> pcie_capability_read_dword(bridge, PCI_EXP_DEVCTL2,
> &ctl2);
> if (ctl2 & PCI_EXP_DEVCTL2_ATOMIC_EGRESS_BLOCK)
> return -EINVAL;
> + fallthrough;
> +
> + /* All switch ports need to route AtomicOps */
> + case PCI_EXP_TYPE_DOWNSTREAM:
> + pcie_capability_read_dword(bridge, PCI_EXP_DEVCAP2,
> + &cap);
> + if (!(cap & PCI_EXP_DEVCAP2_ATOMIC_ROUTE))
> + return -EINVAL;
> + break;
> }
>
> - bus = bus->parent;
> + bridge = pci_upstream_bridge(bridge);
> }
>
> pcie_capability_set_word(dev, PCI_EXP_DEVCTL2,
Thanks,
Gerd
^ permalink raw reply
* Re: [PATCH net-next v2] ppp: update Kconfig help message
From: Julian Braha @ 2026-04-02 14:43 UTC (permalink / raw)
To: Qingfang Deng, linux-ppp, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Eric Biggers, netdev,
linux-kernel
Cc: Paul Mackerras, Dianne Skoll, Jaco Kroon, James Carlson
In-Reply-To: <20260402050053.144250-1-qingfang.deng@linux.dev>
I didn't realize there were dead links in the Kconfig help texts.
I've added a check for this to kconfirm and found many more instances!
In most cases, I'm not the right person to be replacing these links;
I'll send out a message soon to the mailing list with what's been
detected. Thanks for the inspiration, Qingfang!
Also, LGTM, so:
Reviewed-by: Julian Braha <julianbraha@gmail.com>
^ permalink raw reply
* Re: [PATCH RFC net-next] net: stmmac: qcom-ethqos: set clk_csr
From: Russell King (Oracle) @ 2026-04-02 14:37 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Konrad Dybcio, Alexandre Torgue, Andrew Lunn, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-stm32, netdev, Paolo Abeni
In-Reply-To: <acw1habUsiSqlrky@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 02:28:45AM +0530, Mohd Ayaan Anwar wrote:
> While I had made an identical change while retesting the PCS series,
> I was holding off on posting this patch for the same concern - what
> if some boards fall outside the 50 - 100 MHz range.
>
> After some digging, the AHB clock appears to operate within:
> - 50 to 100 MHz for lemans/monaco derivative boards (2500BASE-X
> interface)
> - 30 to 75 MHz for boards with an RGMII interface.
That's ever so slightly annoying, but it makes no difference for the
divisor selection.
CSR_F_60M is a divider of 42 giving:
714kHz @ 30MHz,
1.19MHz @ 50MHz,
1.79MHz @ 75MHz,
2.42MHz @ 100MHz
If we were to use CSR_F_35M, that would be /26, giving:
1.15MHz @ 30MHz
1.92MHz @ 50MHz
2.88MHz @ 75MHz (exceeding 802.3 spec)
3.85MHz @ 100MHz (exceeding 802.3 spec)
Given the RGMII range, to stay within the 802.3 spec without knowing
the actual clock rate being used, CSR_F_60M is still the only possible
selection, even though it gives an extremely low clock rate for 30MHz.
I believe you said that firmware can change this clock rate dynamically
at runtime which makes it much harder. If there was a notification from
firmware into the kernel that the clocks had changed, and that was
communicated into the clk API such that the appropriate clock input for
stmmac, then we could look at updating the divisor.
We would need the firmware to give us a pre-rate change notification
and post-rate change notification (and be guaranteed that there would
always be a post notification after the pre notification) with that
coupled into the clk API.
We'd need stmmac to hook into the clk API notifier infrastructure,
where the PRE_RATE_CHANGE takes the MDIO bus lock to wait for any in-
progress transfer to finish, and then block further accesses, and
POST_RATE_CHANGE update the divisor, and finally both
ABORT_RATE_CHANGE and POST_RATE_CHANGE releasing the MDIO bus lock.
With firmware telling the kernel what this clock rate is, the manual
setting of priv->plat->clk_csr goes away.
Maybe this is something to consider for the future.
> If a future platform exceeds this range, we could switch to something
> like: plat_dat->clk_csr = data->clk_csr, with each EMAC version
> selecting the appropriate divisor.
Without firmware telling us what the clock rate actually is, that's the
only solution.
> Due to some urgent work tasks, I am still finishing PCS series
> testing. I will provide a t-b once done.
>
> In the meanwhile, please feel free to add:
>
> Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Thanks! I'll submit the patch non-RFC shortly.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v7] selftests: net: add tests for PPP
From: Andrew Lunn @ 2026-04-02 14:37 UTC (permalink / raw)
To: Qingfang Deng
Cc: Paolo Abeni, Jakub Kicinski, Dianne Skoll, Shuah Khan,
David S. Miller, Eric Dumazet, Simon Horman, Felix Maurer,
Sebastian Andrzej Siewior, Matthieu Baerts (NGI0), linux-kernel,
linux-kselftest, linux-ppp, netdev, Paul Mackerras, Jaco Kroon
In-Reply-To: <CALW65jZszAVHNSYgo9Fav8J-Ph9dXzR34CYr1-Ar776mOy4Lbw@mail.gmail.com>
On Thu, Apr 02, 2026 at 08:04:23PM +0800, Qingfang Deng wrote:
> On Thu, Apr 2, 2026 at 7:17 PM Paolo Abeni <pabeni@redhat.com> wrote:
> >
> > On 4/2/26 12:13 PM, Qingfang Deng wrote:
> >
> > > What distro do you run CI tests on? On Ubuntu 24.04, "rp-pppoe.so" is
> > > a symlink to "pppoe.so" in apt package "ppp". Maybe an additional
> > > package is required for the distro you use, or I may work around that
> > > by manually creating the symlink.
> >
> > It's fedora 43 with ppp and pppoe installed.
> >
> > ppp provides pppoe.so, and AFAICS nothink provides rp-pppoe.so, and the
> > pppoe-server is looking for a non existing /etc/ppp/plugins/rp-pppoe.so
> > plugin.
> >
> > Before I mess with the nipa testbed, could you please double check that
> >
> > ln -n /usr/lib64/pppd/2.5.1/pppoe.so /etc/ppp/plugins/rp-pppoe.so
> >
> > should solve?
>
> Hard links will also work.
> Alternatively, if your rp-pppoe version is 4.0, you can use the new
> option `-g` to specify the full path of the pppoe.so plugin.
It should be possible for anybody to run these self tests. So we don't
want specially crafted setups, but generic setups which will work for
as many people as possible.
It looks like v4.0 we released 2024-09-09. So can we make that the
minimum version? Fail the test if an older version is found? Can the
test poke around the file system and find rp-pppoe.so and pass it
using -g?
Andrew
^ permalink raw reply
* Re: [PATCH net-next] selftests/net: Add two xdp tests to xdp.py
From: Jakub Kicinski @ 2026-04-02 14:35 UTC (permalink / raw)
To: Leon Hwang
Cc: Leon Hwang, netdev, Andrew Lunn, David S . Miller, Eric Dumazet,
Paolo Abeni, Shuah Khan, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
linux-kselftest, linux-kernel, bpf
In-Reply-To: <6c1d6987-ca73-40de-adab-bc6f9fce67f6@linux.dev>
On Thu, 2 Apr 2026 11:22:15 +0800 Leon Hwang wrote:
> >> +def test_xdp_native_update_mb_to_sb(cfg):
> >> + obj = cfg.net_lib_dir / "xdp_dummy.bpf.o"
> >> +
> >> + _set_jumbo_mtu(cfg, 9000)
> >> +
> >> + attach = _exec_cmd(cfg, obj, "xdp.frags")
> >> + if attach.ret != 0:
> >> + output = attach.stderr.strip() or attach.stdout.strip()
> >> + raise KsftSkipEx(output or "device does not support multi-buffer XDP")
> >> +
> >> + defer(ip, f"link set dev {cfg.ifname} xdpdrv off")
> >> +
> >> + update1 = _exec_cmd(cfg, obj, "xdp.frags", "-force")
> >> + if update1.ret != 0:
> >> + raise KsftFailEx("device fails to update multi-buffer XDP")
> >> +
> >> + update2 = _exec_cmd(cfg, obj, "xdp", "-force")
> >> + if update2.ret == 0:
> >> + raise KsftFailEx("device unexpectedly updates non-multi-buffer XDP")
>
> From sashiko's review [1]:
>
> On architectures with larger page sizes, such as 16KB or 64KB on ARM64 or
> PowerPC, a 9000-byte packet can fit entirely within a single buffer. In
> these environments, the driver might legally accept a non-frag XDP program,
> which would lead to a false positive failure here.
Yes the test is indeed not checking all the corner cases, it should be:
# set mtu to 9k
# try attach xdp
# if ret == 0:
# return // must be 64k pages or something
# try attach xdp.frags
# if ret != 0:
# raise SKIP // driver doesn't support multi-buf
# defer xdp off
# try --froce switch to xdp
# if ret == 0:
# raise FAIL // replace is missing a check
^ permalink raw reply
* Re: [PATCH net-next] net-timestamp: take track of the skb when wait_for_space occurs
From: Eric Dumazet @ 2026-04-02 14:24 UTC (permalink / raw)
To: Jason Xing
Cc: davem, kuba, pabeni, horms, willemb, netdev, Jason Xing,
Yushan Zhou
In-Reply-To: <20260402085831.36983-1-kerneljasonxing@gmail.com>
On Thu, Apr 2, 2026 at 1:58 AM Jason Xing <kerneljasonxing@gmail.com> wrote:
>
> From: Jason Xing <kernelxing@tencent.com>
>
> Tag the skb in tcp_sendmsg_locked() when wait_for_space occurs even
> though it might not carry the last byte of the sendmsg.
>
> If we don't do so, we might be faced with no single timestamp that
> can be received by application from the error queue. The following steps
> reproduce this:
> 1) skb A is the current last skb before entering wait_for_space process
> 2) tcp_push() pushes A without any tag
> 3) A is transmitted from TCP to driver without putting any skb carring
> timestamps in the error queue, like SCHED, DRV/HARDWARE.
> 4) sk_stream_wait_memory() sleeps for a while and then returns with an
> error code. Note that the socket lock is released.
> 5) skb A finally gets acked and removed from the rtx queue.
> 6) continue with the rest of tcp_sendmsg_locked(): it will jump to(goto)
> 'do_error' label and then 'out' label.
> 7) at this moment, skb A turns out to be the last one in this send
> syscall, and miss the following tcp_tx_timestamp() opportunity before
> the final tcp_push
> 8) application receives no timestamps this time
>
> The original commit ad02c4f54782 ("tcp: provide timestamps for partial writes")
> says it is best effort. Now it's time to cover the only potential point
> to avoid missing record.
>
> The side effect is obvious that we might record more than one time for a
> single send syscall since the skb that we keep track of in this scenario
> might not be the last one. But tracing more than one skb is not a bad
> thing since there is an emerging/promissing trend to do a detailed
> packet granularity monitor.
This is rather weak/lazy, especially if you do not know how long the
thread is put to sleep?
>
> Thanks to the great ID, namely, tskey, application that is responsible
> for the collect/sort of timestamps leverages it to put that record in
> between two consecutive send syscalls correctly.
>
> Signed-off-by: Yushan Zhou <katrinzhou@tencent.com>
> Signed-off-by: Jason Xing <kernelxing@tencent.com>
> ---
> net/ipv4/tcp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 516087c622ad..2db80d75cfa4 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1411,9 +1411,11 @@ int tcp_sendmsg_locked(struct sock *sk, struct msghdr *msg, size_t size)
> wait_for_space:
> set_bit(SOCK_NOSPACE, &sk->sk_socket->flags);
> tcp_remove_empty_skb(sk);
> - if (copied)
> + if (copied) {
> + tcp_tx_timestamp(sk, &sockc);
> tcp_push(sk, flags & ~MSG_MORE, mss_now,
> TCP_NAGLE_PUSH, size_goal);
> + }
>
> err = sk_stream_wait_memory(sk, &timeo);
> if (err != 0)
I think non blocking model should be used by modern applications,
especially ones caring about timestamps.
This patch has performance implications.
tcp_tx_timestamp() is quite big and was inlined because it had a single caller.
After this patch, it is no longer inlined.
scripts/bloat-o-meter -t vmlinux.before vmlinux.after
add/remove: 2/0 grow/shrink: 0/1 up/down: 239/-192 (47)
Function old new delta
tcp_tx_timestamp - 223 +223
__pfx_tcp_tx_timestamp - 16 +16
tcp_sendmsg_locked 4560 4368 -192
Total: Before=29652698, After=29652745, chg +0.00%
^ permalink raw reply
* Re: [net-next PATCH 06/10] net: dsa: realtek: rtl8365mb: add VLAN support
From: Yury Norov @ 2026-04-02 14:22 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Linus Walleij,
Alvin Šipraga, Yury Norov, Rasmus Villemoes, Russell King,
netdev, linux-kernel
In-Reply-To: <CAJq09z6fUhwnbZhFF2okU07z2uj5JPr5mAerpfSxhYDgRNZvwA@mail.gmail.com>
On Wed, Apr 01, 2026 at 11:45:18PM -0300, Luiz Angelo Daros de Luca wrote:
> > > + vlan4k->vid = vid;
> > > + vlan4k->member =
> > > + FIELD_GET(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK, data[0]) |
> > > + (FIELD_GET(RTL8365MB_CVLAN_ENTRY_D2_MBR_EXT_MASK, data[2])
> > > + << FIELD_WIDTH(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK));
> >
> > This FIELD_GET() << FIELD_WIDTH() resembles FIELD_PREP(), except that
> > you skip some checks. Is that intentional?
>
> While it resembles FIELD_PREP(), the usage of FIELD_GET() <<
> FIELD_WIDTH() is intentional and semantically distinct from
> FIELD_PREP(). While FIELD_PREP() prepares a raw value to be written up
> into a register mask, we are performing a read/unpack operation here:
> extracting bits from hardware registers to populate the driver's
> internal logical structure.
>
> Using FIELD_PREP() for this would require defining a 'fake' software
> mask (e.g., GENMASK(10, 8)) that does not correspond to any physical
> register, which would be more confusing to future maintainers than the
> current explicit reassembly.
Not sure. You can add a nice comment on top of those GENMASKS(),
explaining what actually is happening there. Long term it always
better to avoid opencoded shifts. It's proven by decades of coding.
All that FIELD() machinery is aimed to avoid shifts and other
opencoded bit manipulations, because they are proven to be a constant
source of errors. And now you use that FIELD_WIDTH() exactly for that.
The alternative would look like:
lo = FIELD_GET(RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK, data[0]);
hi = FIELD_GET(RTL8365MB_CVLAN_ENTRY_D2_MBR_EXT_MASK, data[2]);
vlan4k->member = FIELD_PREP(RTL8365MB_CVLAN_ENTRY_MBR_MASK_LO, lo) |
FIELD_PREP(RTL8365MB_CVLAN_ENTRY_MBR_EXT_MASK_HI, hi);
I'm not going to teach you how to wright your driver, but you see -
it's 4 lines vs 4 lines, and no opencoded bit ops. And I'm pretty sure
you'll find plenty examples in the kernel where people construct
registers from pieces this way.
Thanks,
Yury
> The 11-bit member field is split across two non-contiguous 16-bit
> words in the CVLAN entry:
> - data[0] (D0): Contains the primary bits [7:0] via
> RTL8365MB_CVLAN_ENTRY_D0_MBR_MASK.
> - data[2] (D2): Contains the extension bits [10:8] via
> RTL8365MB_CVLAN_ENTRY_D2_MBR_EXT_MASK.
>
> This split layout suggests the hardware was originally designed for 8
> ports and later expanded to 11, placing the extra bits in the
> previously unused space in data[2].
> Even if we concatenate them into a single 48-bit value, a single
> bitfield macro would not handle the non-contiguous mask.
^ permalink raw reply
* Re: [PATCH net v6 3/4] selftests: Add MACsec VLAN propagation traffic test
From: Cosmin Ratiu @ 2026-04-02 14:18 UTC (permalink / raw)
To: sd@queasysnail.net
Cc: andrew+netdev@lunn.ch, davem@davemloft.net,
linux-kselftest@vger.kernel.org, Dragos Tatulea, sdf@fomichev.me,
shuah@kernel.org, pabeni@redhat.com, horms@kernel.org,
edumazet@google.com, kuba@kernel.org, netdev@vger.kernel.org
In-Reply-To: <ac5U3LFm2pOV3vWM@krikkit>
On Thu, 2026-04-02 at 13:37 +0200, Sabrina Dubroca wrote:
> 2026-03-30, 16:01:29 +0300, Cosmin Ratiu wrote:
> > +def _get_mac(ifname, host=None):
> > + """Gets MAC address of an interface."""
> > + dev = ip(f"-d link show dev {ifname}", json=True, host=host)
>
> nit: MAC address doesn't need '-d'
Will do.
>
> I would have used fixed SCI on both ends to avoid this mess with the
> local/remote MAC address, but it's ok as you wrote it.
I guess it would make the test slightly simpler but it would no longer
exercise the manual rx port address creation. I think the MAC stuff is
a small cost to pay for a little extra coverage.
> > + return dev[0]["address"]
>
> [...]
> > +def _check_nsim_vid(cfg, vid, expected) -> None:
> > + """Checks if a VLAN is present. Only works on netdevsim."""
> > +
> > + nsim = cfg.get_local_nsim_dev()
> > + if not nsim:
> > + return
> > +
> > + vlan_path = nsim.nsims[0].dfs_dir + "vlan"
>
> nit: os.path.join for consistency with other users
Will do.
Cosmin.
^ permalink raw reply
* [PATCH 0/1] gcov: add -fprofile-update=atomic to fix concurrent access crashes
From: Konstantin Khorenko @ 2026-04-02 14:18 UTC (permalink / raw)
To: Peter Oberparleiter, Mikhail Zaslonko, Nathan Chancellor,
Nicolas Schier
Cc: Masahiro Yamada, Thomas Weißschuh, Arnd Bergmann,
Steffen Klassert, Herbert Xu, linux-kbuild, linux-kernel, netdev,
Konstantin Khorenko, Pavel Tikhomirov, Vasileios Almpanis,
Jakub Kicinski
This patch adds -fprofile-update=atomic to global CFLAGS_GCOV in the
top-level Makefile to fix crashes caused by GCC merging GCOV counters
with loop induction variables in concurrent code paths.
History
-------
This was originally posted as a zlib-only fix:
https://lore.kernel.org/lkml/20260330143256.306326-1-khorenko@virtuozzo.com/T/#t
During review, it was suggested to apply the flag globally instead of
per-subsystem, as it not only fixes the observed crash but makes GCOV
coverage data more consistent overall. A combined series was posted:
https://lore.kernel.org/lkml/20260401142020.1434243-1-khorenko@virtuozzo.com/T/#t
That combined series is now split per subsystem as requested by
reviewers.
The GCC bug report for the underlying compiler issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124749
Dependencies
------------
This patch requires the following preparatory fixes to be applied first,
otherwise CONFIG_GCOV_PROFILE_ALL=y builds will fail:
- net: fix skb_ext BUILD_BUG_ON failures with GCOV (sent to netdev):
__no_profile on skb_ext_total_length() and skb_extensions_init()
https://lore.kernel.org/lkml/20260402140558.1437002-1-khorenko@virtuozzo.com/T/#t
- iommu/generic_pt: disable GCOV for iommu_amdv1.o (sent to iommu):
GCOV_PROFILE_iommu_amdv1.o := n
https://lore.kernel.org/lkml/20260402141012.1437095-1-khorenko@virtuozzo.com/T/#t
Without those patches, -fprofile-update=atomic prevents GCC from
constant-folding expressions inside profiled inline functions, breaking
BUILD_BUG_ON / FIELD_PREP compile-time checks.
The crash
---------
Observed during LTP IPComp stress testing on a GCOV-enabled kernel:
BUG: unable to handle page fault for address: ffffd0a3c0902ffa
RIP: inflate_fast+1431
Call Trace:
zlib_inflate
__deflate_decompress
crypto_comp_decompress
ipcomp_decompress [xfrm_ipcomp]
ipcomp_input [xfrm_ipcomp]
xfrm_input
GCC merged a global GCOV counter with the loop induction variable.
Another CPU modified the counter between loads, causing a write 3.4 MB
past a 65 KB buffer. -fprofile-update=atomic forces atomic counter
updates and prevents this merging.
Testing
-------
Build-tested with CONFIG_GCOV_PROFILE_ALL=y using GCC 11.4.1 and
GCC 16.0.1 20260327 (experimental). Both fail without the full set
of patches, both succeed with all three series applied.
Assembly-verified that -fprofile-update=atomic prevents counter-IV
merging in inflate_fast() on both compiler versions.
Also tested by Peter Oberparleiter:
Quote: "Successfully tested this series on s390 (except for patch 3 which
depends on x86) using GCC 15.2.0, GCC 10.1.0, and current Clang from git
(20260401)."
Konstantin Khorenko (1):
gcov: use atomic counter updates to fix concurrent access crashes
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.43.5
^ permalink raw reply
* [PATCH] gcov: use atomic counter updates to fix concurrent access crashes
From: Konstantin Khorenko @ 2026-04-02 14:18 UTC (permalink / raw)
To: Peter Oberparleiter, Mikhail Zaslonko, Nathan Chancellor,
Nicolas Schier
Cc: Masahiro Yamada, Thomas Weißschuh, Arnd Bergmann,
Steffen Klassert, Herbert Xu, linux-kbuild, linux-kernel, netdev,
Konstantin Khorenko, Pavel Tikhomirov, Vasileios Almpanis,
Jakub Kicinski
In-Reply-To: <20260402141831.1437357-1-khorenko@virtuozzo.com>
GCC's GCOV instrumentation can merge global branch counters with loop
induction variables as an optimization. In inflate_fast(), the inner
copy loops get transformed so that the GCOV counter value is loaded
multiple times to compute the loop base address, start index, and end
bound. Since GCOV counters are global (not per-CPU), concurrent
execution on different CPUs causes the counter to change between loads,
producing inconsistent values and out-of-bounds memory writes.
The crash manifests during IPComp (IP Payload Compression) processing
when inflate_fast() runs concurrently on multiple CPUs:
BUG: unable to handle page fault for address: ffffd0a3c0902ffa
RIP: inflate_fast+1431
Call Trace:
zlib_inflate
__deflate_decompress
crypto_comp_decompress
ipcomp_decompress [xfrm_ipcomp]
ipcomp_input [xfrm_ipcomp]
xfrm_input
At the crash point, the compiler generated three loads from the same
global GCOV counter (__gcov0.inflate_fast+216) to compute base, start,
and end for an indexed loop. Another CPU modified the counter between
loads, making the values inconsistent — the write went 3.4 MB past a
65 KB buffer.
Add -fprofile-update=atomic to CFLAGS_GCOV at the global level in the
top-level Makefile. This tells GCC that GCOV counters may be
concurrently accessed, causing counter updates to use atomic
instructions (lock addq) instead of plain load/store. This prevents
the compiler from merging counters with loop induction variables.
Applying this globally rather than per-subsystem not only addresses the
observed crash in zlib but makes GCOV coverage data more consistent
overall, preventing similar issues in any kernel code path that may
execute concurrently.
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 6b1d9fb1a6b4..a55ad668d6ba 100644
--- a/Makefile
+++ b/Makefile
@@ -806,7 +806,7 @@ all: vmlinux
CFLAGS_GCOV := -fprofile-arcs -ftest-coverage
ifdef CONFIG_CC_IS_GCC
-CFLAGS_GCOV += -fno-tree-loop-im
+CFLAGS_GCOV += -fno-tree-loop-im -fprofile-update=atomic
endif
export CFLAGS_GCOV
--
2.43.5
^ permalink raw reply related
* [PATCH 1/1] net: hsr: avoid learning nodes from ordinary PRP SAN traffic
From: Ao Zhou @ 2026-04-02 14:18 UTC (permalink / raw)
To: netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Felix Maurer, Murali Karicheri, Shaurya Rane,
Sebastian Andrzej Siewior, Ingo Molnar, Kees Cook, Yifan Wu,
Juefei Pu, Yuan Tan, Xin Liu, Yuqi Xu, Ao Zhou
In-Reply-To: <cover.1775056603.git.royenheart@outlook.com>
From: Haoze Xie <royenheart@gmail.com>
PRP slave ports accept ordinary SAN traffic and forward it to the
master device without needing a persistent node entry. Creating one
node per previously unseen SAN source lets arbitrary source MAC floods
grow node_db until the prune timer catches up.
Keep the receive path for ordinary PRP SAN traffic, but stop learning a
new node when the frame is untagged and does not carry a PRP trailer.
Continue to deliver the frame locally and only keep node state for
actual HSR/PRP senders or nodes that have already been learned.
Fixes: 451d8123f897 ("net: prp: add packet handling support")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Yuqi Xu <xuyuqiabc@gmail.com>
Signed-off-by: Haoze Xie <royenheart@gmail.com>
Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
---
net/hsr/hsr_forward.c | 14 ++++++++++----
net/hsr/hsr_framereg.c | 16 +++++++++++++---
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
index aefc9b6936ba..5fbfc42997d2 100644
--- a/net/hsr/hsr_forward.c
+++ b/net/hsr/hsr_forward.c
@@ -403,7 +403,8 @@ static void hsr_deliver_master(struct sk_buff *skb, struct net_device *dev,
int res, recv_len;
was_multicast_frame = (skb->pkt_type == PACKET_MULTICAST);
- hsr_addr_subst_source(node_src, skb);
+ if (node_src)
+ hsr_addr_subst_source(node_src, skb);
skb_pull(skb, ETH_HLEN);
recv_len = skb->len;
res = netif_rx(skb);
@@ -699,8 +700,12 @@ static int fill_frame_info(struct hsr_frame_info *frame,
frame->node_src = hsr_get_node(port, n_db, skb,
frame->is_supervision, port->type);
- if (!frame->node_src)
- return -1; /* Unknown node and !is_supervision, or no mem */
+ if (IS_ERR(frame->node_src)) {
+ ret = PTR_ERR(frame->node_src);
+ if (ret != -ENOENT)
+ return ret;
+ frame->node_src = NULL;
+ }
ethhdr = (struct ethhdr *)skb_mac_header(skb);
frame->is_vlan = false;
@@ -739,7 +744,8 @@ void hsr_forward_skb(struct sk_buff *skb, struct hsr_port *port)
if (fill_frame_info(&frame, skb, port) < 0)
goto out_drop;
- hsr_register_frame_in(frame.node_src, port, frame.sequence_nr);
+ if (frame.node_src)
+ hsr_register_frame_in(frame.node_src, port, frame.sequence_nr);
hsr_forward_do(&frame);
rcu_read_unlock();
/* Gets called for ingress frames as well as egress from master port.
diff --git a/net/hsr/hsr_framereg.c b/net/hsr/hsr_framereg.c
index 50996f4de7f9..13e1a0484879 100644
--- a/net/hsr/hsr_framereg.c
+++ b/net/hsr/hsr_framereg.c
@@ -230,7 +230,7 @@ struct hsr_node *hsr_get_node(struct hsr_port *port, struct list_head *node_db,
bool san = false;
if (!skb_mac_header_was_set(skb))
- return NULL;
+ return ERR_PTR(-EINVAL);
ethhdr = (struct ethhdr *)skb_mac_header(skb);
@@ -263,14 +263,24 @@ struct hsr_node *hsr_get_node(struct hsr_port *port, struct list_head *node_db,
ethhdr->h_proto == htons(ETH_P_HSR)) {
/* Check if skb contains hsr_ethhdr */
if (skb->mac_len < sizeof(struct hsr_ethhdr))
- return NULL;
+ return ERR_PTR(-EINVAL);
} else {
rct = skb_get_PRP_rct(skb);
if (!rct && rx_port != HSR_PT_MASTER)
san = true;
}
- return hsr_add_node(hsr, node_db, ethhdr->h_source, san, rx_port);
+ /* PRP accepts ordinary SAN traffic on slave ports without learning a
+ * persistent node entry.
+ */
+ if (hsr->prot_version == PRP_V1 && san)
+ return ERR_PTR(-ENOENT);
+
+ node = hsr_add_node(hsr, node_db, ethhdr->h_source, san, rx_port);
+ if (!node)
+ return ERR_PTR(-ENOMEM);
+
+ return node;
}
static bool hsr_seq_block_is_old(struct hsr_seq_block *block)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next 06/11] net: macb: introduce macb_context struct for buffer management
From: Théo Lebrun @ 2026-04-02 14:11 UTC (permalink / raw)
To: Nicolai Buchwitz, Théo Lebrun
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Richard Cochran,
Russell King, Paolo Valerio, Conor Dooley, Vladimir Kondratiev,
Gregory CLEMENT, Benoît Monin, Tawfik Bayouk,
Thomas Petazzoni, Maxime Chevallier, netdev, linux-kernel
In-Reply-To: <70b176b84fbff4a57d7f6be5f42fc753@tipi-net.de>
On Thu Apr 2, 2026 at 1:22 PM CEST, Nicolai Buchwitz wrote:
> On 1.4.2026 18:39, Théo Lebrun wrote:
>> Whenever an operation requires buffer realloc, we close the interface,
>> update parameters and reopen. To improve reliability under memory
>> pressure, we should rather alloc new buffers, reconfigure HW and free
>> old buffers. This requires MACB to support having multiple "contexts"
>> in parallel.
>>
>> Introduce this concept by adding the macb_context struct, which owns
>> all
>> queue buffers and the parameters associated. We do not yet support
>> multiple contexts in parallel, because all functions access bp->ctx
>> (the currently active context) directly.
>>
>> Steps:
>>
>> - Introduce `struct macb_context` and its children `struct macb_rxq`
>> and `struct macb_txq`. Context fields are stolen from `struct macb`
>> and rxq/txq fields are from `struct macb_queue`.
>>
>> Making it two separate structs per queue simplifies accesses: we
>> grab
>> a txq/rxq local variable and access fields like txq->head instead of
>> queue->tx_head. It also anecdotally improves data locality.
>>
>> - macb_init_dflt() does not set bp->ctx->{rx,tx}_ring_size to default
>> values as ctx is not allocated yet. Instead, introduce
>> bp->configured_{rx,tx}_ring_size which get updated on user requests.
>>
>> - macb_open() starts by allocating bp->ctx. It gets freed in the
>> open error codepath or by macb_close().
>>
>> - Guided by compile errors, update all codepaths. Most diff is
>> changing
>> `queue->tx_*` to `txq->*` and `queue->rx_*` to `rxq->*`, with a new
>> local variable. Also rx_buffer_size / rx_ring_size / tx_ring_size
>> move from bp to bp->ctx.
>>
>> Introduce two helpers macb_tx|rx() functions to convert macb_queue
>> pointers.
>>
>> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
>> ---
>> drivers/net/ethernet/cadence/macb.h | 49 ++--
>> drivers/net/ethernet/cadence/macb_main.c | 442
>> ++++++++++++++++++-------------
>> 2 files changed, 296 insertions(+), 195 deletions(-)
>>
>
>> [...]
>
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>> b/drivers/net/ethernet/cadence/macb_main.c
>> index d5023fdc0756..0f63d9b89c11 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>
>> [...]
>
>> @@ -3596,14 +3677,15 @@ static void macb_get_regs(struct net_device
>> *netdev, struct ethtool_regs *regs,
>> void *p)
>> {
>> struct macb *bp = netdev_priv(netdev);
>> + struct macb_txq *txq = &bp->ctx->txq[0];
>
> bp->ctx is NULL when the interface is down. This will crash if
> ethtool -d is called while the interface is not running. Same
> issue below in macb_get_ringparam().
Agreed. Will check if context is alive and use default values otherwise.
Something like this for V2:
static void macb_get_regs(struct net_device *netdev, struct ethtool_regs *regs,
void *p)
{
dma_addr_t tx_dma_tail = 0, tx_dma_head = 0;
struct macb *bp = netdev_priv(netdev);
unsigned int tail = 0, head = 0;
struct macb_txq *txq;
u32 *regs_buff = p;
regs->version = (macb_readl(bp, MID) & ((1 << MACB_REV_SIZE) - 1))
| MACB_GREGS_VERSION;
if (bp->ctx) {
txq = &bp->ctx->txq[0];
tail = macb_tx_ring_wrap(bp->ctx, txq->tail);
head = macb_tx_ring_wrap(bp->ctx, txq->head);
tx_dma_tail = macb_tx_dma(&bp->queues[0], tail);
tx_dma_head = macb_tx_dma(&bp->queues[0], head);
}
regs_buff[0] = macb_readl(bp, NCR);
regs_buff[1] = macb_or_gem_readl(bp, NCFGR);
regs_buff[2] = macb_readl(bp, NSR);
regs_buff[3] = macb_readl(bp, TSR);
regs_buff[4] = macb_readl(bp, RBQP);
regs_buff[5] = macb_readl(bp, TBQP);
regs_buff[6] = macb_readl(bp, RSR);
regs_buff[7] = macb_readl(bp, IMR);
regs_buff[8] = tail;
regs_buff[9] = head;
regs_buff[10] = tx_dma_tail;
regs_buff[11] = tx_dma_head;
if (!(bp->caps & MACB_CAPS_USRIO_DISABLED))
regs_buff[12] = macb_or_gem_readl(bp, USRIO);
if (macb_is_gem(bp->caps))
regs_buff[13] = gem_readl(bp, DMACFG);
}
>
>> unsigned int tail, head;
>> u32 *regs_buff = p;
>>
>> regs->version = (macb_readl(bp, MID) & ((1 << MACB_REV_SIZE) - 1))
>> | MACB_GREGS_VERSION;
>>
>> - tail = macb_tx_ring_wrap(bp, bp->queues[0].tx_tail);
>> - head = macb_tx_ring_wrap(bp, bp->queues[0].tx_head);
>> + tail = macb_tx_ring_wrap(bp, txq->tail);
>> + head = macb_tx_ring_wrap(bp, txq->head);
>>
>> regs_buff[0] = macb_readl(bp, NCR);
>> regs_buff[1] = macb_or_gem_readl(bp, NCFGR);
>> @@ -3682,8 +3764,8 @@ static void macb_get_ringparam(struct net_device
>> *netdev,
>> ring->rx_max_pending = MAX_RX_RING_SIZE;
>> ring->tx_max_pending = MAX_TX_RING_SIZE;
>>
>> - ring->rx_pending = bp->rx_ring_size;
>> - ring->tx_pending = bp->tx_ring_size;
>> + ring->rx_pending = bp->ctx->rx_ring_size;
>> + ring->tx_pending = bp->ctx->tx_ring_size;
>
> Same NULL ctx issue as above. This one could just read from
> bp->configured_{rx,tx}_ring_size instead.
Agreed with the fix, easy one.
Thanks!
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] net: fec: make FIXED_PHY dependency unconditional
From: Arnd Bergmann @ 2026-04-02 14:10 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Heiner Kallweit
Cc: Arnd Bergmann, netdev, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
When CONFIG_FIXED_PHY is in a loadable module, the fec driver cannot be
built-in any more:
x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe':
fec_main.c:(.text+0xc4f367): undefined reference to `fixed_phy_unregister'
x86_64-linux-ld: vmlinux.o: in function `fec_enet_close':
fec_main.c:(.text+0xc59591): undefined reference to `fixed_phy_unregister'
x86_64-linux-ld: vmlinux.o: in function `fec_enet_mii_probe.cold':
Select the fixed phy support on all targets to make this build
correctly, not just on coldfire.
Notat that Essentially the stub helpers in include/linux/phy_fixed.h
cannot be used correctly because of this build time dependency,
and we could just remove them to hit the build failure more often
when a driver uses them without the 'select FIXED_PHY'.
Fixes: dc86b621e1b4 ("net: fec: register a fixed phy using fixed_phy_register_100fd if needed")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
I sent the same fix for B44 earlier, see commit 3f0f591b44b0 ("net: b44:
always select CONFIG_FIXED_PHY"). I checked that there are no other
conditional users of FIXED_PHY this time.
---
drivers/net/ethernet/freescale/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index e2a591cf9601..11edbb46a118 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -28,7 +28,7 @@ config FEC
depends on PTP_1588_CLOCK_OPTIONAL
select CRC32
select PHYLIB
- select FIXED_PHY if M5272
+ select FIXED_PHY
select PAGE_POOL
imply PAGE_POOL_STATS
imply NET_SELFTESTS
--
2.39.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox