* [PATCH net-next v4 2/2] net: ethernet: ti: am65-cpsw: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 10:48 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <191e9f7e3a6c14eabe891a98c5fb646766479c0a.1775558273.git.nora.schiffer@ew.tq-group.com>
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
v2: drop AM64_CPSW_QUIRK_CUT_THRU flag, which is a downstream ti-linux feature
v3: resubmission for net-next, no changes
v4: no changes
SGMII operation also requires changes to the phy-j721e-wiz and gmii-sel drivers:
https://lore.kernel.org/lkml/cover.1775045279.git.nora.schiffer@ew.tq-group.com/
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
index d9400599e80a4..7ac75fc8cdcf4 100644
--- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
@@ -3468,6 +3468,13 @@ static const struct am65_cpsw_pdata am64x_cpswxg_pdata = {
.fdqring_mode = K3_RINGACC_RING_MODE_RING,
};
+static const struct am65_cpsw_pdata j722s_cpswxg_pdata = {
+ .quirks = AM64_CPSW_QUIRK_DMA_RX_TDOWN_IRQ,
+ .ale_dev_id = "am64-cpswxg",
+ .fdqring_mode = K3_RINGACC_RING_MODE_RING,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const struct am65_cpsw_pdata j7200_cpswxg_pdata = {
.quirks = 0,
.ale_dev_id = "am64-cpswxg",
@@ -3495,6 +3502,7 @@ static const struct of_device_id am65_cpsw_nuss_of_mtable[] = {
{ .compatible = "ti,am654-cpsw-nuss", .data = &am65x_sr1_0},
{ .compatible = "ti,j721e-cpsw-nuss", .data = &j721e_pdata},
{ .compatible = "ti,am642-cpsw-nuss", .data = &am64x_cpswxg_pdata},
+ { .compatible = "ti,j722s-cpsw-nuss", .data = &j722s_cpswxg_pdata},
{ .compatible = "ti,j7200-cpswxg-nuss", .data = &j7200_cpswxg_pdata},
{ .compatible = "ti,j721e-cpswxg-nuss", .data = &j721e_cpswxg_pdata},
{ .compatible = "ti,j784s4-cpswxg-nuss", .data = &j784s4_cpswxg_pdata},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH net-next v4 1/2] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Nora Schiffer @ 2026-04-07 10:48 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW3G is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am642-cpsw-nuss is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
v2: keep ti,am642-cpsw-nuss as a fallback
v3: resubmission for net-next, no changes
v4: remove redundant items: level
.../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
index a959c1d7e643a..c409c6310ed40 100644
--- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
+++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml
@@ -53,13 +53,18 @@ properties:
"#size-cells": true
compatible:
- enum:
- - ti,am642-cpsw-nuss
- - ti,am654-cpsw-nuss
- - ti,j7200-cpswxg-nuss
- - ti,j721e-cpsw-nuss
- - ti,j721e-cpswxg-nuss
- - ti,j784s4-cpswxg-nuss
+ oneOf:
+ - enum:
+ - ti,am642-cpsw-nuss
+ - ti,am654-cpsw-nuss
+ - ti,j7200-cpswxg-nuss
+ - ti,j721e-cpsw-nuss
+ - ti,j721e-cpswxg-nuss
+ - ti,j784s4-cpswxg-nuss
+ - items:
+ - enum:
+ - ti,j722s-cpsw-nuss
+ - const: ti,am642-cpsw-nuss
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH bpf-next v3 1/6] bpf: name the enum for BPF_FUNC_skb_adjust_room flags
From: Nick Hudson @ 2026-04-07 10:50 UTC (permalink / raw)
To: bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Eduard Zingerman,
Kumar Kartikeya Dwivedi, linux-kernel
In-Reply-To: <20260407105005.1639815-1-nhudson@akamai.com>
The existing anonymous enum for BPF_FUNC_skb_adjust_room flags is
named to enum bpf_adj_room_flags to enable CO-RE (Compile Once -
Run Everywhere) lookups in BPF programs.
Co-developed-by: Max Tottenham <mtottenh@akamai.com>
Signed-off-by: Max Tottenham <mtottenh@akamai.com>
Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Nick Hudson <nhudson@akamai.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
---
include/uapi/linux/bpf.h | 2 +-
tools/include/uapi/linux/bpf.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 552bc5d9afbd..c021ed8d7b44 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -6211,7 +6211,7 @@ enum {
};
/* BPF_FUNC_skb_adjust_room flags. */
-enum {
+enum bpf_adj_room_flags {
BPF_F_ADJ_ROOM_FIXED_GSO = (1ULL << 0),
BPF_F_ADJ_ROOM_ENCAP_L3_IPV4 = (1ULL << 1),
BPF_F_ADJ_ROOM_ENCAP_L3_IPV6 = (1ULL << 2),
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 677be9a47347..ca35ed622ed5 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -6211,7 +6211,7 @@ enum {
};
/* BPF_FUNC_skb_adjust_room flags. */
-enum {
+enum bpf_adj_room_flags {
BPF_F_ADJ_ROOM_FIXED_GSO = (1ULL << 0),
BPF_F_ADJ_ROOM_ENCAP_L3_IPV4 = (1ULL << 1),
BPF_F_ADJ_ROOM_ENCAP_L3_IPV6 = (1ULL << 2),
--
2.34.1
^ permalink raw reply related
* [PATCH bpf-next v3 0/6] bpf: decap flags and GSO state updates
From: Nick Hudson @ 2026-04-07 10:49 UTC (permalink / raw)
To: bpf, netdev, Willem de Bruijn, Martin KaFai Lau
Cc: Nick Hudson, Max Tottenham, Anna Glasgall
This series extends bpf_skb_adjust_room() with decapsulation-specific
flags and tunnel GSO state updates for decap use cases.
Motivation
----------
When BPF decapsulates tunneled packets, skb GSO state needs to be updated
to match the removed tunnel layer. This includes clearing the corresponding
tunnel GSO type bits and resetting encapsulation state once no tunnel GSO
flags remain.
Series Overview
---------------
- Name the adjust_room flag enum for CO-RE lookups.
- Refactor adjust_room helper masks for maintainable validation logic.
- Add new DECAP flags to UAPI.
- Add guard rails for incompatible/invalid decap flag combinations.
- Implement decap GSO flag clearing.
- Add selftests to validate decap GSO state transitions.
Changes v2 -> v3:
- Add a new selftests patch to validate decap GSO state behavior.
- Reorder the series so helper-mask refactoring precedes UAPI DECAP flag additions.
- Refresh patch 2 and patch 3 split to keep refactoring behavior-neutral.
- Patch 5: add decap tunnel GSO-state checks in
"bpf: clear decap tunnel GSO state in skb_adjust_room" (per Gemini/sashiko).
Changes v1 -> v2:
- Patch 3: decap flag acceptance intentionally remains L3-only while adding helper masks.
- Patch 4: decap with L4/IPXIP support enabled with guard rails.
Co-developed-by: Max Tottenham <mtottenh@akamai.com>
Signed-off-by: Max Tottenham <mtottenh@akamai.com>
Co-developed-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Anna Glasgall <aglasgal@akamai.com>
Signed-off-by: Nick Hudson <nhudson@akamai.com>
Nick Hudson (6):
bpf: name the enum for BPF_FUNC_skb_adjust_room flags
bpf: refactor masks for ADJ_ROOM flags and encap validation
bpf: add BPF_F_ADJ_ROOM_DECAP_* flags for tunnel decapsulation
bpf: allow new DECAP flags and add guard rails
bpf: clear decap tunnel GSO state in skb_adjust_room
selftests/bpf: tc_tunnel validate decap GSO state
include/uapi/linux/bpf.h | 36 +++++-
net/core/filter.c | 120 +++++++++++++++---
tools/include/uapi/linux/bpf.h | 36 +++++-
.../selftests/bpf/progs/test_tc_tunnel.c | 58 +++++++++
4 files changed, 227 insertions(+), 23 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH] net/tls: fix use-after-free in -EBUSY error path of tls_do_encryption
From: Sabrina Dubroca @ 2026-04-07 11:30 UTC (permalink / raw)
To: Muhammad Alifa Ramdhan
Cc: netdev, kuba, davem, edumazet, pabeni, john.fastabend, info,
stable
In-Reply-To: <20260403013617.2838875-1-ramdhan@starlabs.sg>
2026-04-03, 09:36:17 +0800, Muhammad Alifa Ramdhan wrote:
> The -EBUSY handling in tls_do_encryption(), introduced by commit
> 859054147318 ("net: tls: handle backlogging of crypto requests"), has
> a use-after-free due to double cleanup of encrypt_pending and the
> scatterlist entry.
>
> When crypto_aead_encrypt() returns -EBUSY, the request is enqueued to
> the cryptd backlog and the async callback tls_encrypt_done() will be
> invoked upon completion. That callback unconditionally restores the
> scatterlist entry (sge->offset, sge->length) and decrements
> ctx->encrypt_pending. However, if tls_encrypt_async_wait() returns an
> error, the synchronous error path in tls_do_encryption() performs the
> same cleanup again, double-decrementing encrypt_pending and
> double-restoring the scatterlist.
>
> The double-decrement corrupts the encrypt_pending sentinel (initialized
> to 1), making tls_encrypt_async_wait() permanently skip the wait for
> pending async callbacks. A subsequent sendmsg can then free the
> tls_rec via bpf_exec_tx_verdict() while a cryptd callback is still
> pending, resulting in a use-after-free when the callback fires on the
> freed record.
>
> Fix this by skipping the synchronous cleanup when the -EBUSY async
> wait returns an error, since the callback has already handled
> encrypt_pending and sge restoration.
>
> Fixes: 859054147318 ("net: tls: handle backlogging of crypto requests")
> Cc: stable@vger.kernel.org
> Signed-off-by: Muhammad Alifa Ramdhan <ramdhan@starlabs.sg>
> ---
> net/tls/tls_sw.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
--
Sabrina
^ permalink raw reply
* [PATCH net] net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo
From: Kai Zen @ 2026-04-07 11:31 UTC (permalink / raw)
To: netdev; +Cc: Eric Dumazet, davem, kuba, pabeni, horms
rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack
without initialisation:
struct ifla_vf_broadcast vf_broadcast;
The struct contains a single fixed 32-byte field:
/* include/uapi/linux/if_link.h */
struct ifla_vf_broadcast {
__u8 broadcast[32];
};
The function then copies dev->broadcast into it using dev->addr_len
as the length:
memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
On Ethernet devices (the overwhelming majority of SR-IOV NICs)
dev->addr_len is 6, so only the first 6 bytes of broadcast[] are
written. The remaining 26 bytes retain whatever was previously on
the kernel stack. The full struct is then handed to userspace via:
nla_put(skb, IFLA_VF_BROADCAST,
sizeof(vf_broadcast), &vf_broadcast)
leaking up to 26 bytes of uninitialised kernel stack per VF per
RTM_GETLINK request, repeatable.
The other vf_* structs in the same function are explicitly zeroed
for exactly this reason - see the memset() calls for ivi,
vf_vlan_info, node_guid and port_guid a few lines above.
vf_broadcast was simply missed when it was added.
Reachability and impact
-----------------------
The leak is reachable by any unprivileged local process. AF_NETLINK
with NETLINK_ROUTE requires no capabilities. The only environmental
requirement is that the host has at least one SR-IOV-capable
interface present, which is the common case for cloud, datacenter
and HPC hosts.
Trigger: send RTM_GETLINK with an IFLA_EXT_MASK attribute whose
value has the RTEXT_FILTER_VF bit set. The kernel will then walk
each VF and emit IFLA_VFINFO_LIST, including IFLA_VF_BROADCAST,
which carries the 26 bytes of uninitialised stack per VF.
Stack residue at this call site can include return addresses
(useful as a KASLR / function-pointer disclosure primitive) and
transient sensitive data left over by whatever ran on the same
kernel stack just prior. KASAN with stack instrumentation, or
KMSAN, will flag the nla_put() when reproduced.
Reproducer (unprivileged):
import socket, struct
IFLA_EXT_MASK = 29
RTEXT_FILTER_VF = 1
s = socket.socket(socket.AF_NETLINK, socket.SOCK_RAW,
socket.NETLINK_ROUTE)
s.bind((0, 0))
hdr = struct.pack('=IHHII', 0, 18, 0x301, 0, 0)
ifi = struct.pack('=BxHiII', 0, 0, 0, 0, 0)
attr = (struct.pack('=HH', 8, IFLA_EXT_MASK) +
struct.pack('=I', RTEXT_FILTER_VF))
msg = hdr + ifi + attr
msg = struct.pack('=I', len(msg)) + msg[4:]
s.send(msg)
data = s.recv(65536)
# Parse IFLA_VF_BROADCAST from the response. Bytes 7..32 of the
# broadcast[] field are uninitialised kernel stack on Ethernet.
Fix
---
Zero the on-stack struct before the partial memcpy, matching the
existing pattern used for the other vf_* structs in the same
function.
Signed-off-by: Kai Aizen <kai.aizen.dev@gmail.com>
---
net/core/rtnetlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1572,6 +1572,7 @@ static noinline_for_stack int
rtnl_fill_vfinfo(struct sk_buff *skb,
port_guid.vf = ivi.vf;
memcpy(vf_mac.mac, ivi.mac, sizeof(ivi.mac));
+ memset(&vf_broadcast, 0, sizeof(vf_broadcast));
memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
vf_vlan.vlan = ivi.vlan;
vf_vlan.qos = ivi.qos;
--
2.43.0
^ permalink raw reply
* Re: [PATCH net] net: rtnetlink: zero ifla_vf_broadcast to avoid stack infoleak in rtnl_fill_vfinfo
From: Eric Dumazet @ 2026-04-07 11:39 UTC (permalink / raw)
To: Kai Zen; +Cc: netdev, davem, kuba, pabeni, horms
In-Reply-To: <CALynFi54eQj7SOmF6QNG0eqhLw7AuURzo6tSYQavvM3ZP74ikw@mail.gmail.com>
On Tue, Apr 7, 2026 at 4:32 AM Kai Zen <kai.aizen.dev@gmail.com> wrote:
>
> rtnl_fill_vfinfo() declares struct ifla_vf_broadcast on the stack
> without initialisation:
>
> struct ifla_vf_broadcast vf_broadcast;
>
> The struct contains a single fixed 32-byte field:
>
> /* include/uapi/linux/if_link.h */
> struct ifla_vf_broadcast {
> __u8 broadcast[32];
> };
>
> The function then copies dev->broadcast into it using dev->addr_len
> as the length:
>
> memcpy(vf_broadcast.broadcast, dev->broadcast, dev->addr_len);
>
> On Ethernet devices (the overwhelming majority of SR-IOV NICs)
> dev->addr_len is 6, so only the first 6 bytes of broadcast[] are
> written. The remaining 26 bytes retain whatever was previously on
> the kernel stack. The full struct is then handed to userspace via:
>
> nla_put(skb, IFLA_VF_BROADCAST,
> sizeof(vf_broadcast), &vf_broadcast)
>
> leaking up to 26 bytes of uninitialised kernel stack per VF per
> RTM_GETLINK request, repeatable.
>
> The other vf_* structs in the same function are explicitly zeroed
> for exactly this reason - see the memset() calls for ivi,
> vf_vlan_info, node_guid and port_guid a few lines above.
> vf_broadcast was simply missed when it was added.
>
> Reachability and impact
> -----------------------
>
> The leak is reachable by any unprivileged local process. AF_NETLINK
> with NETLINK_ROUTE requires no capabilities. The only environmental
> requirement is that the host has at least one SR-IOV-capable
> interface present, which is the common case for cloud, datacenter
> and HPC hosts.
>
> Trigger: send RTM_GETLINK with an IFLA_EXT_MASK attribute whose
> value has the RTEXT_FILTER_VF bit set. The kernel will then walk
> each VF and emit IFLA_VFINFO_LIST, including IFLA_VF_BROADCAST,
> which carries the 26 bytes of uninitialised stack per VF.
>
> Stack residue at this call site can include return addresses
> (useful as a KASLR / function-pointer disclosure primitive) and
> transient sensitive data left over by whatever ran on the same
> kernel stack just prior. KASAN with stack instrumentation, or
> KMSAN, will flag the nla_put() when reproduced.
Please note:
1) You forgot to add the Fixes: tag as mentioned earlier.
2) Your patch is mangled, tabulations have been replaced with spaces.
Documentation/process/applying-patches.rst
3) Please wait ~24 hours before sending a new version.
Documentation/process/maintainer-netdev.rst
Thank you.
^ permalink raw reply
* [PATCH v4 0/5] J722S SGMII support
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
The J722S CPSW and SERDES are very similar to the variants found on the
AM64, but they additionally support SGMII. Introduce new compatible
strings for the J722S to add this support to the drivers.
This is a prerequisite for the Single-Pair Ethernet interface of the
TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
submitted separately.
For SGMII to actually work on the J722S, the am65-cpsw needs to be extended
as well, which has been submitted for net-next:
https://patchwork.kernel.org/project/netdevbpf/list/?series=1078111
Fallback compatible strings allow for the patches to be applied in any
order and to go through different trees without breaking existing
functionality.
v4:
- remove redundant items: level from DT binding YAMLs
v3:
- Drop am65-cpsw changes from this series, they need to go through net-next
- Fix missing PHY_GMII_SEL_RGMII_ID_MODE and PHY_GMII_SEL_FIXED_TX_DELAY in
gmii-sel driver for RGMII delay mode configuration
v2:
- Keep support for the AM64 compatible strings as a fallback, adjust commit
messages
- Drop reference to AM64_CPSW_QUIRK_CUT_THRU flag, which only exists in the
TI vendor kernel
Nora Schiffer (5):
dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel
compatible
phy: ti: phy-j721e-wiz: add support for J722S SoC family
phy: ti: gmii-sel: add support for J722S SoC family
arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel
and CPSW3G
.../bindings/phy/ti,phy-gmii-sel.yaml | 23 +++++++++++-------
.../bindings/phy/ti,phy-j721e-wiz.yaml | 19 +++++++++------
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++--
drivers/phy/ti/phy-gmii-sel.c | 13 ++++++++++
drivers/phy/ti/phy-j721e-wiz.c | 24 +++++++++++++++++++
5 files changed, 73 insertions(+), 18 deletions(-)
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* [PATCH v4 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII. The AM64 compatible ti,am654-phy-gmii-sel is used as a
fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-gmii-sel.yaml | 23 +++++++++++--------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
index be41b4547ec6d..60b644a4c6390 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
@@ -47,15 +47,20 @@ description: |
properties:
compatible:
- enum:
- - ti,am3352-phy-gmii-sel
- - ti,dra7xx-phy-gmii-sel
- - ti,am43xx-phy-gmii-sel
- - ti,dm814-phy-gmii-sel
- - ti,am654-phy-gmii-sel
- - ti,j7200-cpsw5g-phy-gmii-sel
- - ti,j721e-cpsw9g-phy-gmii-sel
- - ti,j784s4-cpsw9g-phy-gmii-sel
+ oneOf:
+ - enum:
+ - ti,am3352-phy-gmii-sel
+ - ti,dra7xx-phy-gmii-sel
+ - ti,am43xx-phy-gmii-sel
+ - ti,dm814-phy-gmii-sel
+ - ti,am654-phy-gmii-sel
+ - ti,j7200-cpsw5g-phy-gmii-sel
+ - ti,j721e-cpsw9g-phy-gmii-sel
+ - ti,j784s4-cpsw9g-phy-gmii-sel
+ - items:
+ - enum:
+ - ti,j722s-phy-gmii-sel
+ - const: ti,am654-phy-gmii-sel
reg:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 3/5] phy: ti: phy-j721e-wiz: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-j721e-wiz.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 6b584706b913a..7531a8a049123 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -331,6 +331,7 @@ enum wiz_type {
J721E_WIZ_16G,
J721E_WIZ_10G, /* Also for J7200 SR1.0 */
AM64_WIZ_10G,
+ J722S_WIZ_10G,
J7200_WIZ_10G, /* J7200 SR2.0 */
J784S4_WIZ_10G,
J721S2_WIZ_10G,
@@ -1020,6 +1021,7 @@ static void wiz_clock_cleanup(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1089,6 +1091,7 @@ static void wiz_clock_init(struct wiz *wiz)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
switch (rate) {
case REF_CLK_100MHZ:
@@ -1158,6 +1161,7 @@ static int wiz_clock_probe(struct wiz *wiz, struct device_node *node)
switch (wiz->type) {
case AM64_WIZ_10G:
+ case J722S_WIZ_10G:
case J7200_WIZ_10G:
case J784S4_WIZ_10G:
case J721S2_WIZ_10G:
@@ -1246,6 +1250,14 @@ static int wiz_phy_fullrt_div(struct wiz *wiz, int lane)
if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
break;
+
+ case J722S_WIZ_10G:
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_PCIE)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x1);
+ if (wiz->lane_phy_type[lane] == PHY_TYPE_SGMII)
+ return regmap_field_write(wiz->p0_fullrt_div[lane], 0x2);
+ break;
+
default:
return 0;
}
@@ -1350,6 +1362,15 @@ static struct wiz_data am64_10g_data = {
.clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
};
+static struct wiz_data j722s_10g_data = {
+ .type = J722S_WIZ_10G,
+ .pll0_refclk_mux_sel = &pll0_refclk_mux_sel,
+ .pll1_refclk_mux_sel = &pll1_refclk_mux_sel,
+ .refclk_dig_sel = &refclk_dig_sel_10g,
+ .clk_mux_sel = clk_mux_sel_10g,
+ .clk_div_sel_num = WIZ_DIV_NUM_CLOCKS_10G,
+};
+
static struct wiz_data j7200_pg2_10g_data = {
.type = J7200_WIZ_10G,
.pll0_refclk_mux_sel = &sup_pll0_refclk_mux_sel,
@@ -1389,6 +1410,9 @@ static const struct of_device_id wiz_id_table[] = {
{
.compatible = "ti,am64-wiz-10g", .data = &am64_10g_data,
},
+ {
+ .compatible = "ti,j722s-wiz-10g", .data = &j722s_10g_data,
+ },
{
.compatible = "ti,j7200-wiz-10g", .data = &j7200_pg2_10g_data,
},
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S WIZ is mostly identical to the AM64's, but additionally supports
SGMII. The AM64 compatible ti,am64-wiz-10g is used as a fallback.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
.../bindings/phy/ti,phy-j721e-wiz.yaml | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
index 3f16ff14484d2..0653252c18d8e 100644
--- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
+++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
@@ -12,13 +12,18 @@ maintainers:
properties:
compatible:
- enum:
- - ti,j721e-wiz-16g
- - ti,j721e-wiz-10g
- - ti,j721s2-wiz-10g
- - ti,am64-wiz-10g
- - ti,j7200-wiz-10g
- - ti,j784s4-wiz-10g
+ oneOf:
+ - enum:
+ - ti,j721e-wiz-16g
+ - ti,j721e-wiz-10g
+ - ti,j721s2-wiz-10g
+ - ti,am64-wiz-10g
+ - ti,j7200-wiz-10g
+ - ti,j784s4-wiz-10g
+ - items:
+ - enum:
+ - ti,j722s-wiz-10g
+ - const: ti,am64-wiz-10g
power-domains:
maxItems: 1
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 4/5] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
The J722S gmii-sel is mostly identical to the AM64's, but additionally
supports SGMII.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
drivers/phy/ti/phy-gmii-sel.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
index 6213c2b6005a5..c2865a6b1d7fb 100644
--- a/drivers/phy/ti/phy-gmii-sel.c
+++ b/drivers/phy/ti/phy-gmii-sel.c
@@ -251,6 +251,15 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
.regfields = phy_gmii_sel_fields_am654,
};
+static const
+struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
+ .use_of_data = true,
+ .features = BIT(PHY_GMII_SEL_RGMII_ID_MODE) |
+ BIT(PHY_GMII_SEL_FIXED_TX_DELAY),
+ .regfields = phy_gmii_sel_fields_am654,
+ .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
+};
+
static const
struct phy_gmii_sel_soc_data phy_gmii_sel_cpsw5g_soc_j7200 = {
.use_of_data = true,
@@ -307,6 +316,10 @@ static const struct of_device_id phy_gmii_sel_id_table[] = {
.compatible = "ti,am654-phy-gmii-sel",
.data = &phy_gmii_sel_soc_am654,
},
+ {
+ .compatible = "ti,j722s-phy-gmii-sel",
+ .data = &phy_gmii_sel_soc_j722s,
+ },
{
.compatible = "ti,j7200-cpsw5g-phy-gmii-sel",
.data = &phy_gmii_sel_cpsw5g_soc_j7200,
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* [PATCH v4 5/5] arm64: dts: ti: k3-j722s-main: use J722S compatibles for WIZ, gmii-sel and CPSW3G
From: Nora Schiffer @ 2026-04-07 11:42 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux, Nora Schiffer
In-Reply-To: <cover.1775559102.git.nora.schiffer@ew.tq-group.com>
Update WIZ, gmii-sel and CPSW3G to use the J722S-specific compatible
strings, enabling SGMII support. The fallback compatibles preserve
compatibility of the updated Device Trees with older kernels.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index 9ee5d0c8ffd1e..70f430aa3a944 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -18,7 +18,7 @@ serdes_refclk: clk-0 {
&cbass_main {
serdes_wiz0: phy@f000000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f000000 0x0 0x0f000000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -56,7 +56,7 @@ serdes0: serdes@f000000 {
};
serdes_wiz1: phy@f010000 {
- compatible = "ti,am64-wiz-10g";
+ compatible = "ti,j722s-wiz-10g", "ti,am64-wiz-10g";
ranges = <0x0f010000 0x0 0x0f010000 0x00010000>;
#address-cells = <1>;
#size-cells = <1>;
@@ -451,6 +451,14 @@ pcie0_ctrl: pcie0-ctrl@4070 {
};
};
+&cpsw3g {
+ compatible = "ti,j722s-cpsw-nuss", "ti,am642-cpsw-nuss";
+};
+
+&phy_gmii_sel {
+ compatible = "ti,j722s-phy-gmii-sel", "ti,am654-phy-gmii-sel";
+};
+
&oc_sram {
reg = <0x00 0x70000000 0x00 0x40000>;
ranges = <0x00 0x00 0x70000000 0x40000>;
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply related
* Re: [PATCH net v2] ipvs: fix MTU check for GSO packets in tunnel mode
From: kernel test robot @ 2026-04-07 11:43 UTC (permalink / raw)
To: Yingnan Zhang, horms, ja
Cc: oe-kbuild-all, pablo, fw, phil, davem, edumazet, kuba, pabeni,
netdev, lvs-devel, netfilter-devel, coreteam, linux-kernel,
Yingnan Zhang
In-Reply-To: <tencent_CA2C1C219C99D315086BE55E8654AF7E6009@qq.com>
Hi Yingnan,
kernel test robot noticed the following build errors:
[auto build test ERROR on net/main]
url: https://github.com/intel-lab-lkp/linux/commits/Yingnan-Zhang/ipvs-fix-MTU-check-for-GSO-packets-in-tunnel-mode/20260407-141549
base: net/main
patch link: https://lore.kernel.org/r/tencent_CA2C1C219C99D315086BE55E8654AF7E6009%40qq.com
patch subject: [PATCH net v2] ipvs: fix MTU check for GSO packets in tunnel mode
config: x86_64-rhel-9.4-ltp (https://download.01.org/0day-ci/archive/20260407/202604071309.RskiawHA-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260407/202604071309.RskiawHA-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604071309.RskiawHA-lkp@intel.com/
All error/warnings (new ones prefixed by >>):
>> net/netfilter/ipvs/ip_vs_xmit.c:115:11: error: expected identifier or '(' before 'else'
115 | } else if (skb->len > mtu &&
| ^~~~
>> net/netfilter/ipvs/ip_vs_xmit.c:119:9: error: expected identifier or '(' before 'return'
119 | return false;
| ^~~~~~
>> net/netfilter/ipvs/ip_vs_xmit.c:120:1: error: expected identifier or '(' before '}' token
120 | }
| ^
net/netfilter/ipvs/ip_vs_xmit.c: In function '__mtu_check_toobig_v6':
>> net/netfilter/ipvs/ip_vs_xmit.c:115:9: warning: control reaches end of non-void function [-Wreturn-type]
115 | } else if (skb->len > mtu &&
| ^
vim +115 net/netfilter/ipvs/ip_vs_xmit.c
104
105 static inline bool
106 __mtu_check_toobig_v6(const struct sk_buff *skb, u32 mtu)
107 {
108 if (IP6CB(skb)->frag_max_size) {
109 /* frag_max_size tell us that, this packet have been
110 * defragmented by netfilter IPv6 conntrack module.
111 */
112 if (IP6CB(skb)->frag_max_size > mtu)
113 return true; /* largest fragment violate MTU */
114 }
> 115 } else if (skb->len > mtu &&
116 !(skb_is_gso(skb) && skb_gso_validate_network_len(skb, mtu))) {
117 return true; /* Packet size violate MTU size */
118 }
> 119 return false;
> 120 }
121
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: stmmac: TX stalls with head OWN=1; requiring manual DMA kick (6.12.63)
From: Russell King (Oracle) @ 2026-04-07 11:45 UTC (permalink / raw)
To: Tomer Maimon; +Cc: Andrew Lunn, Giuseppe Cavallaro, netdev
In-Reply-To: <CAP6Zq1hKd19aLjWBnx3pkfeGyqrudqSHd0PTxUJhn7r9BG0oSA@mail.gmail.com>
On Thu, Mar 12, 2026 at 04:02:45PM +0200, Tomer Maimon wrote:
> Hi Andrew and Russell,
>
> On Wed, 11 Mar 2026 at 22:52, Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> >
> > On Wed, Mar 11, 2026 at 08:46:04PM +0100, Andrew Lunn wrote:
> > > On Wed, Mar 11, 2026 at 08:34:36PM +0200, Tomer Maimon wrote:
> > > > Hi Giuseppe,
> > > >
> > > > On kernel 6.12.63 (GMAC, normal 16‑byte TX descriptors), we observe
> > > > brief TX stalls when sending small packets.
> > >
> > > You might want to look at Russell Kings patches from this week to
> > > rework the descriptor handling.
>
> Sorry, I mean 6.12 LTS.
> >
> > Yep.
> >
> > Not sure they'll materially affect any problem, because I try to avoid
> > functional changes in stuff like those.
> >
> > What's missing from the original report is a description of the
> > hardware. stmmac drives multiple different versions of the Synopsys
> > IP which have significant changes between them. Which platform glue
> > is being used, which core driver is being used (dwmac1000? dwmac4?
> > etc.)
> stmmac IP version is 3.73a
> The platform is glue is "snps,dwmac" and the core driver is "dwmac1000"
Thanks.
> > Also what isn't mentioned is whether this is a regression, or whether
> > it's something that has never worked. If it's a regression, which
> > kernel version previously worked?
> We ran the test with kernel 5.10 LTS, and it didn't work.
So it isn't a regression, but a persistent issue.
You mentioned in your original email:
> If the head descriptor still has OWN=1, issue a Transmit Poll Demand
> via stmmac_enable_dma_transmission().
> This immediately resumes the DMA and clears the stall.
This will be dwmac_lib.c::dwmac_enable_dma_transmission() which writes
to the transmit poll demand register. This write is prefixed on arm64
by a "dmb oshst" instruction which should ensure that previous writes
to the descriptors are visible to stmmac.
dwmac1000 doesn't have TSO and in any case the packet is too small for
TSO, so we can ignore stmmac_tso_xmit(). I'm also guessing your not
using xdp either, so we can rule out stmmac_xdp_xmit_zc() and
stmmac_xdp_xmit_xdpf().
So, we're looking at the normal path through stmmac_xmit().
The code at this point is:
/* Set the OWN bit on the first descriptor now that all descriptors
* for this skb are populated.
*/
stmmac_set_tx_owner(priv, first_desc);
netdev_tx_sent_queue(netdev_get_tx_queue(dev, queue), skb->len);
stmmac_enable_dma_transmission(priv, priv->ioaddr, queue);
stmmac_set_tx_owner() will be calling norm_desc.c::ndesc_set_tx_owner()
which quite simply sets bit 31 in the descriptor via a
read-modify-write:
0000000000000000 <ndesc_set_tx_owner>:
0: b9400001 ldr w1, [x0]
4: 32010021 orr w1, w1, #0x80000000
8: b9000001 str w1, [x0]
c: d65f03c0 ret
and as I say, dwmac_enable_dma_transmission() includes the necessary
barrier to ensure that _that_ write should be visible to stmmac:
0000000000000120 <dwmac_enable_dma_transmission>:
120: 52820082 mov w2, #0x1004 // #4100
124: 0b012041 add w1, w2, w1, lsl #8
128: 8b214001 add x1, x0, w1, uxtw
12c: d50332bf dmb oshst
130: 52800020 mov w0, #0x1 // #1
134: b9000020 str w0, [x1]
138: d65f03c0 ret
However, I'm wondering if we have an issue with the descriptor writes
becoming visible in the wrong order. Please can you try adding a
dma_wmb() immediately before stmmac_set_tx_owner() in stmmac_xmit()
to ensure that all previous descriptor settings are fully visible
before we update the OWN bit on the first descriptor and make that
update visible?
Thanks.
--
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: [RFC net-next 15/15] Documentation: networking: add ipxlat translator guide
From: Daniel Gröber @ 2026-04-07 11:30 UTC (permalink / raw)
To: Xavier Hsinyuan
Cc: ralf, antonio, corbet, davem, edumazet, horms, kuba, linux-doc,
linux-kernel, netdev, pabeni, skhan
In-Reply-To: <TYRPR01MB12666EEA0B8007166ED446088CA5DA@TYRPR01MB12666.jpnprd01.prod.outlook.com>
On Mon, Apr 06, 2026 at 10:50:44PM +0800, Xavier Hsinyuan wrote:
> >+ $ ./tools/net/ynl/pyynl/cli.py --family ipxlat --json '{"ifindex": $IID, \
> >+ "config": {"xlat-prefix6": "'$HEX_ADDR'", "prefix-len": 96} }'
> Should this be like:
> $ python3 /extends/pyynl/cli.py --spec ipxlat.yaml --do dev-set --json \
> '{"ifindex": "'$IID'", "config": {"xlat-prefix6": \
> {"prefix":"'$ADDR_HEX'", "prefix-len": 96}}}'
Indeed, the JSON is just wrong and --do dev-set is missing. However
`--family ipxlat` works for me and looking at the code is basically the
same as specifying --spec.
Could you try this:
$ JSON='{"ifindex": '"$IID"', "config": {"xlat-prefix6": { "prefix": "'$ADDR_HEX'", "prefix-len": 96}}}'
$ ./tools/net/ynl/pyynl/cli.py --family ipxlat --do dev-set --json "$JSON"
> >+Address Translation
> >+-------------------
> >+
> >+The ipxlat address translation algorithm is stateless, per RFC-ADDR_, all
> >+possible IPv4 addressess are mapped one-to-one into the translation prefix,
> >+optionally including a non-standard "suffix". See `RFC-ADDR Section 2.2
> >+<https://datatracker.ietf.org/doc/html/rfc6052#section-2.2>`_.
> >+
> >+.. _RFC-ADDR: https://datatracker.ietf.org/doc/html/rfc6052
> >+
> >+IPv6 addressess outside this prefix are rejected with ICMPv6 errors with
> >+the notable exception of ICMPv6 errors originating from untranslatable
> >+source addressess. These are translated to be sourced from the IPv4 Dummy
> >+Address ``192.0.0.8`` (per I-D-dummy_) instead to maintain IPv4 traceroute
> >+visibility.
>
> Would it help to add a few example? For instance,
> - Interface ipxlat0 with prefix6=64:ff9b::/96.
> - A IPv6 packet with src=64:ff9b::192.0.2.1 dst=64:ff9b::198.51.100.1,
> was send to ipxlat0.
> - Then a IPv4 packet with src=192.0.2.1 dst=198.51.100.1 was received from
> ipxlat0.
I worry once we start with that we're really just re-stating what's already
extensively documented in the RFCs.
How about a reference to RFC 7915 Appendix A? This has a full bidirectional
end-to-end example of how translation operates:
https://datatracker.ietf.org/doc/html/rfc7915#appendix-A
Admittedly using a /96 prefix (which the appendix doesn't) would make it
easier to grok whats going on. Not sure that's reason enough to get into
more detailed examples here.
WDYT?
Thanks,
--Daniel
^ permalink raw reply
* Re: [PATCH net-next V2 0/5] net/mlx5e: XDP, Add support for multi-packet per page
From: patchwork-bot+netdevbpf @ 2026-04-07 11:50 UTC (permalink / raw)
To: Tariq Toukan
Cc: edumazet, kuba, pabeni, andrew+netdev, davem, saeedm, leon,
mbloch, ast, daniel, hawk, john.fastabend, sdf, dtatulea, cratiu,
horms, jacob.e.keller, lkayal, michal.swiatkowski, cjubran,
nathan, daniel.zahka, rrameshbabu, raeds, netdev, linux-rdma,
linux-kernel, bpf, gal
In-Reply-To: <20260403090927.139042-1-tariqt@nvidia.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 3 Apr 2026 12:09:22 +0300 you wrote:
> Hi,
>
> This series removes the limitation of having one packet per page in XDP
> mode. This has the following implications:
>
> - XDP in Striding RQ mode can now be used on 64K page systems.
>
> [...]
Here is the summary with links:
- [net-next,V2,1/5] net/mlx5e: XSK, Increase size for chunk_size param
https://git.kernel.org/netdev/net-next/c/1047e14b44ed
- [net-next,V2,2/5] net/mlx5e: XDP, Improve dma address calculation of linear part for XDP_TX
https://git.kernel.org/netdev/net-next/c/833e72645aac
- [net-next,V2,3/5] net/mlx5e: XDP, Remove stride size limitation
https://git.kernel.org/netdev/net-next/c/2dfaa0238774
- [net-next,V2,4/5] net/mlx5e: XDP, Use a single linear page per rq
https://git.kernel.org/netdev/net-next/c/ebd4ad29cc82
- [net-next,V2,5/5] net/mlx5e: XDP, Use page fragments for linear data in multibuf-mode
https://git.kernel.org/netdev/net-next/c/25b8c9b6d731
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH bpf-next v3 5/6] bpf: clear decap tunnel GSO state in skb_adjust_room
From: bot+bpf-ci @ 2026-04-07 11:52 UTC (permalink / raw)
To: nhudson, bpf, netdev, willemb, martin.lau
Cc: nhudson, mtottenh, aglasgal, ast, daniel, andrii, eddyz87, memxor,
davem, edumazet, kuba, pabeni, linux-kernel, ast, andrii, daniel,
martin.lau, eddyz87, yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260407105005.1639815-6-nhudson@akamai.com>
[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 7f8d43420afb..04059d07d368 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -3667,6 +3667,46 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32 off, u32 len_diff,
> if (!(flags & BPF_F_ADJ_ROOM_FIXED_GSO))
> skb_increase_gso_size(shinfo, len_diff);
>
> + /* Selective GSO flag clearing based on decap type.
> + * Only clear the flags for the tunnel layer being removed.
> + */
> + if ((flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) &&
> + (shinfo->gso_type & (SKB_GSO_UDP_TUNNEL |
> + SKB_GSO_UDP_TUNNEL_CSUM |
> + SKB_GSO_TUNNEL_REMCSUM)))
> + shinfo->gso_type &= ~(SKB_GSO_UDP_TUNNEL |
> + SKB_GSO_UDP_TUNNEL_CSUM |
> + SKB_GSO_TUNNEL_REMCSUM);
[ ... ]
> +
> + /* Clear encapsulation flag only when no tunnel GSO flags remain */
> + if (flags & (BPF_F_ADJ_ROOM_DECAP_L4_MASK |
> + BPF_F_ADJ_ROOM_DECAP_IPXIP_MASK)) {
[ ... ]
> +
> + if (flags & BPF_F_ADJ_ROOM_DECAP_L4_UDP) {
> + skb->encap_hdr_csum = !!(shinfo->gso_type & SKB_GSO_UDP_TUNNEL_CSUM);
> + skb->remcsum_offload = !!(shinfo->gso_type & SKB_GSO_TUNNEL_REMCSUM);
The L4_UDP clearing block above unconditionally clears
SKB_GSO_UDP_TUNNEL_CSUM and SKB_GSO_TUNNEL_REMCSUM from
shinfo->gso_type. By the time these two assignments execute,
both flags are always zero, so these expressions always
evaluate to 0.
The kernel's own __skb_udp_tunnel_segment() in udp_offload.c
uses the same !!() pattern:
need_csum = !!(skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL_CSUM);
skb->encap_hdr_csum = need_csum;
remcsum = !!(skb_shinfo(skb)->gso_type & SKB_GSO_TUNNEL_REMCSUM);
skb->remcsum_offload = remcsum;
but there the flags are still live. Here they have already been
cleared, so the conditional form is misleading. Would it be
clearer to just assign 0 directly?
> + }
> + }
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24079111128
^ permalink raw reply
* Re: [PATCH net-next v5 00/10] Decouple receive and transmit enablement in team driver
From: Jiri Pirko @ 2026-04-07 11:55 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260406-teaming-driver-internal-v5-0-e8a3f348a1c5@google.com>
Mon, Apr 06, 2026 at 05:03:36AM +0200, marcharvey@google.com 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 10).
>
>There are three patches with small fixes as well, with the goal of
>making the final decoupling patch clearer (1, 2, and 3).
Looks fine to me now. Do you have libteam/teamd counterpart?
^ permalink raw reply
* Re: [PATCH net-next v5 01/10] net: team: Annotate reads and writes for mixed lock accessed values
From: Jiri Pirko @ 2026-04-07 11:56 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260406-teaming-driver-internal-v5-1-e8a3f348a1c5@google.com>
Mon, Apr 06, 2026 at 05:03:37AM +0200, marcharvey@google.com wrote:
>The team_port's "index" and the team's "en_port_count" are read in
>the hot transmit path, but are only written to when holding the rtnl
>lock.
>
>Use READ_ONCE() for all lockless reads of these values, and use
>WRITE_ONCE() for all writes.
>
>Signed-off-by: Marc Harvey <marcharvey@google.com>
>---
>Changes in v5:
>- None
>
>Changes in v4:
>- None
>
>Changes in v3:
>- None
>
>Changes in v2:
>- None
Nit: I don't think you need to add such record when there is no change.
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
* Re: [PATCH net-next v5 02/10] net: team: Remove unused team_mode_op, port_enabled
From: Jiri Pirko @ 2026-04-07 11:56 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260406-teaming-driver-internal-v5-2-e8a3f348a1c5@google.com>
Mon, Apr 06, 2026 at 05:03:38AM +0200, marcharvey@google.com wrote:
>This team_mode_op wasn't used by any of the team modes, so remove it.
>
>Signed-off-by: Marc Harvey <marcharvey@google.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
* Re: [PATCH net-next v5 06/10] net: team: Rename enablement functions and struct members to tx
From: Jiri Pirko @ 2026-04-07 11:56 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260406-teaming-driver-internal-v5-6-e8a3f348a1c5@google.com>
Mon, Apr 06, 2026 at 05:03:42AM +0200, marcharvey@google.com wrote:
>Add no functional changes, but rename enablement functions, variables
>etc. that are used in teaming driver transmit decisions.
>
>Since rx and tx enablement are still coupled, some of the variables
>renamed in this patch are still used for the rx path, but that will
>change in a follow-up patch.
>
>Signed-off-by: Marc Harvey <marcharvey@google.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
* Re: [PATCH net-next v5 07/10] net: team: Track rx enablement separately from tx enablement
From: Jiri Pirko @ 2026-04-07 11:56 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260406-teaming-driver-internal-v5-7-e8a3f348a1c5@google.com>
Mon, Apr 06, 2026 at 05:03:43AM +0200, marcharvey@google.com wrote:
>Separate the rx and tx enablement/disablement into different
>functions so that it is easier to interact with them independently
>later.
>
>Although this patch changes receive and transmit paths, the actual
>behavior of the teaming driver should remain unchanged, since there
>is no option introduced yet to change rx or tx enablement
>independently. Those options will be added in follow-up patches.
>
>Signed-off-by: Marc Harvey <marcharvey@google.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
* linux-next: manual merge of the bpf-next tree with the powerpc tree
From: Mark Brown @ 2026-04-07 11:56 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking
Cc: Abhishek Dubey, Linux Kernel Mailing List,
Linux Next Mailing List, Madhavan Srinivasan
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c
between commit:
66cad93ad325b ("selftest/bpf: Enable instruction array test for powerpc")
from the powerpc tree and commit:
99726ece0c8ad ("selftests/bpf: Enable test for instruction array on arm64")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c
index 482d38b9c29e1,93166c2da8e7b..0000000000000
--- a/tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c
+++ b/tools/testing/selftests/bpf/prog_tests/bpf_insn_array.c
@@@ -3,7 -3,7 +3,7 @@@
#include <bpf/bpf.h>
#include <test_progs.h>
- #if defined(__x86_64__) || defined(__powerpc__)
-#if defined(__x86_64__) || defined(__aarch64__)
++#if defined(__x86_64__) || defined(__powerpc__) || defined(__aarch64__)
static int map_create(__u32 map_type, __u32 max_entries)
{
const char *map_name = "insn_array";
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v5 08/10] net: team: Add new rx_enabled team port option
From: Jiri Pirko @ 2026-04-07 11:57 UTC (permalink / raw)
To: Marc Harvey
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Shuah Khan, Simon Horman, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <20260406-teaming-driver-internal-v5-8-e8a3f348a1c5@google.com>
Mon, Apr 06, 2026 at 05:03:44AM +0200, marcharvey@google.com wrote:
>Allow independent control over rx enablement via the rx_enabled option
>without affecting tx enablement. This affects the normal enabled
>option since a port is only considered enabled if both tx and rx are
>enabled.
>
>If this option is not used, then the enabled option will continue to
>behave exactly as it did before.
>
>Tested in a follow-up patch with a new selftest.
>
>Signed-off-by: Marc Harvey <marcharvey@google.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
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