* Re: [PATCH net v2] net/x25: Fix overflow when accumulating packets
From: Martin Schiller @ 2026-04-02 7:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, edumazet, pabeni, yimingqian591, linux-x25, netdev,
linux-kernel, security
In-Reply-To: <20260402024855.842920-1-kuba@kernel.org>
On 2026-04-02 04:48, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net/x25: Fix overflow when accumulating packets
>
> This commit adds a check to prevent x25_sock.fraglen from overflowing
> during packet accumulation. It also resets the fragment length when
> purging the fragment queue.
>
>> diff --git a/net/x25/x25_in.c b/net/x25/x25_in.c
>> index b981a4828d08..cb84c683d249 100644
>> --- a/net/x25/x25_in.c
>> +++ b/net/x25/x25_in.c
>> @@ -34,6 +34,12 @@ static int x25_queue_rx_frame(struct sock *sk,
>> struct sk_buff *skb, int more)
>> struct sk_buff *skbo, *skbn = skb;
>> struct x25_sock *x25 = x25_sk(sk);
>>
>> + /* make sure we don't overflow */
>> + if (x25->fraglen + skb->len > USHRT_MAX) {
>> + kfree_skb(skb);
>> + return 1;
>> + }
>
> Does this cause the skb to be freed twice?
>
> When x25_queue_rx_frame() frees the skb and returns 1, the caller
> x25_state3_machine() leaves its local queued variable as 0 and returns
> 0.
>
> This 0 value propagates up through x25_process_rx_frame() to callers
> like x25_backlog_rcv() or x25_lapb_receive_frame(). Since the return
> value indicates the packet was not consumed by the protocol stack,
> these
> upper-level functions will call kfree_skb(skb) again on the already
> freed skb.
>
> Would it be safer to return 1 without calling kfree_skb(skb) here so
> the callers can handle freeing the unconsumed packet?
This is already fixed / changed in the v4 patch set.
^ permalink raw reply
* Re: Re: [PATCH net-next v03 4/6] hinic3: Add ethtool rss ops
From: Fan Gong @ 2026-04-02 7:17 UTC (permalink / raw)
To: mohsin.bashr
Cc: andrew+netdev, davem, edumazet, gongfan1, guoxin09, horms,
ioana.ciornei, kuba, linux-doc, linux-kernel, luosifu,
maxime.chevallier, netdev, pabeni, shijing34, wulike1,
zhengjiezhen, zhoushuai28, zhuyikai1
In-Reply-To: <3b252b2b-6be7-4a8d-9782-39695e948635@gmail.com>
On 4/1/2026 3:53 PM, Mohsin Bashir wrote:
> > + err = hinic3_update_rss_hash_opts(netdev, cmd, rss_type);
> > + if (err)
> > + return err;
> > +
> > + err = hinic3_set_rss_type(nic_dev->hwdev, *rss_type);
>
> So if we fail here, we have already modified the rss_type in-place. From this on-wards, the HW state would diverge from in-memory state. How about use a local copy and only update if no error?
>
> > + if (err) {
> > + netdev_err(netdev, "Failed to set rss type\n");
> > + return err;
> > + }
> > +
> > + return 0;
> > +}
> > +
Thanks for your four patch reviews.
For patch 01, we'll add nic_info to inform the user that depth is timmed and restore q_params.
For patch 02, we'll remove const.
For patch 03, we'll change errcode and modify rx_max_coalesced_frames_high judgement condition.
As tx and rx share interrupt, we only use ETHTOOL_COALESCE_RX_USECS to avoid user misunderstanding.
So we do not add ETHTOOL_COALESCE_TX_USECS.
For patch 04, we overlooked the recovery of rss_type in error handling and we'll fix it.
We will fix them in next version.
Fan gong
^ permalink raw reply
* [PATCH 1/2 net v3] ipv4: nexthop: avoid duplicate NHA_HW_STATS_ENABLE on nexthop group dump
From: Fernando Fernandez Mancera @ 2026-04-02 7:26 UTC (permalink / raw)
To: netdev
Cc: idosch, petrm, horms, pabeni, kuba, edumazet, davem, dsahern,
kees, Fernando Fernandez Mancera
Currently NHA_HW_STATS_ENABLE is included twice everytime a dump of
nexthop group is performed with NHA_OP_FLAG_DUMP_STATS. As all the stats
querying were moved to nla_put_nh_group_stats(), leave only that
instance of the attribute querying.
Fixes: 5072ae00aea4 ("net: nexthop: Expose nexthop group HW stats to user space")
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
---
v2: patch added
v3: no changes
---
net/ipv4/nexthop.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
index c942f1282236..a0c694583299 100644
--- a/net/ipv4/nexthop.c
+++ b/net/ipv4/nexthop.c
@@ -902,8 +902,7 @@ static int nla_put_nh_group(struct sk_buff *skb, struct nexthop *nh,
goto nla_put_failure;
if (op_flags & NHA_OP_FLAG_DUMP_STATS &&
- (nla_put_u32(skb, NHA_HW_STATS_ENABLE, nhg->hw_stats) ||
- nla_put_nh_group_stats(skb, nh, op_flags)))
+ nla_put_nh_group_stats(skb, nh, op_flags))
goto nla_put_failure;
return 0;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v3 1/2] dt-bindings: net: ti: k3-am654-cpsw-nuss: Add ti,j722s-cpsw-nuss compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:26 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Roger Quadros, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev, devicetree,
linux-kernel, linux-arm-kernel, linux
In-Reply-To: <e7ec1b928357d1240a962a88dc6ac67fd2c92357.1774958552.git.nora.schiffer@ew.tq-group.com>
On Wed, Apr 01, 2026 at 02:05:42PM +0200, Nora Schiffer wrote:
> 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
>
> .../bindings/net/ti,k3-am654-cpsw-nuss.yaml | 20 ++++++++++++-------
> 1 file changed, 13 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..70d25f5ff1cfe 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,19 @@ 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:
> + - items:
s/items/enum/. No need to make it a list, wasn't list before. It is not
making code more readable.
> + - enum:
> + - ti,am642-cpsw-nuss
> + - ti,am654-cpsw-nuss
> + - ti,j7200-cpswxg-nuss
> + - ti,j721e-cpsw-nuss
> + - ti,j721e-cpswxg-nuss
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/2 net v3] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Fernando Fernandez Mancera @ 2026-04-02 7:26 UTC (permalink / raw)
To: netdev
Cc: idosch, petrm, horms, pabeni, kuba, edumazet, davem, dsahern,
kees, Fernando Fernandez Mancera, Yiming Qian
In-Reply-To: <20260402072613.25262-1-fmancera@suse.de>
When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
single nexthops and small Equal-Cost Multi-Path groups, this fixed
allocation fails for large nexthop groups like 512 nexthops.
This results in the following warning splat:
WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608
[...]
RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)
[...]
Call Trace:
<TASK>
rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1894)
____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)
___sys_sendmsg (net/socket.c:2641)
__sys_sendmsg (net/socket.c:2671)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
</TASK>
Fix this by allocating the size dynamically using nh_nlmsg_size() and
using nlmsg_new(), this is consistent with nexthop_notify() behavior. In
addition, adjust nh_nlmsg_size_grp() so it calculates the size needed
based on flags passed. While at it, also add the size of NHA_FDB for
nexthop group size calculation as it was missing too.
This cannot be reproduced via iproute2 as the group size is currently
limited and the command fails as follows:
addattr_l ERROR: message exceeded bound of 1048
Fixes: 430a049190de ("nexthop: Add support for nexthop groups")
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Closes: https://lore.kernel.org/netdev/CAL_bE8Li2h4KO+AQFXW4S6Yb_u5X4oSKnkywW+LPFjuErhqELA@mail.gmail.com/
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
---
v2: adjust nh_nlmsg_size_grp() to handle size for stats and add symbols
to the trace in commit message
v3: include NHA_FDB size into nh_nlmsg_size_grp() calculation
---
net/ipv4/nexthop.c | 38 +++++++++++++++++++++++++++-----------
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
index a0c694583299..2c9036c719b6 100644
--- a/net/ipv4/nexthop.c
+++ b/net/ipv4/nexthop.c
@@ -1003,16 +1003,32 @@ static size_t nh_nlmsg_size_grp_res(struct nh_group *nhg)
nla_total_size_64bit(8);/* NHA_RES_GROUP_UNBALANCED_TIME */
}
-static size_t nh_nlmsg_size_grp(struct nexthop *nh)
+static size_t nh_nlmsg_size_grp(struct nexthop *nh, u32 op_flags)
{
struct nh_group *nhg = rtnl_dereference(nh->nh_grp);
size_t sz = sizeof(struct nexthop_grp) * nhg->num_nh;
size_t tot = nla_total_size(sz) +
- nla_total_size(2); /* NHA_GROUP_TYPE */
+ nla_total_size(2) + /* NHA_GROUP_TYPE */
+ nla_total_size(0); /* NHA_FDB */
if (nhg->resilient)
tot += nh_nlmsg_size_grp_res(nhg);
+ if (op_flags & NHA_OP_FLAG_DUMP_STATS) {
+ tot += nla_total_size(0) + /* NHA_GROUP_STATS */
+ nla_total_size(4); /* NHA_HW_STATS_ENABLE */
+ tot += nhg->num_nh *
+ (nla_total_size(0) + /* NHA_GROUP_STATS_ENTRY */
+ nla_total_size(4) + /* NHA_GROUP_STATS_ENTRY_ID */
+ nla_total_size_64bit(8)); /* NHA_GROUP_STATS_ENTRY_PACKETS */
+
+ if (op_flags & NHA_OP_FLAG_DUMP_HW_STATS) {
+ tot += nhg->num_nh *
+ nla_total_size_64bit(8); /* NHA_GROUP_STATS_ENTRY_PACKETS_HW */
+ tot += nla_total_size(4); /* NHA_HW_STATS_USED */
+ }
+ }
+
return tot;
}
@@ -1047,14 +1063,14 @@ static size_t nh_nlmsg_size_single(struct nexthop *nh)
return sz;
}
-static size_t nh_nlmsg_size(struct nexthop *nh)
+static size_t nh_nlmsg_size(struct nexthop *nh, u32 op_flags)
{
size_t sz = NLMSG_ALIGN(sizeof(struct nhmsg));
sz += nla_total_size(4); /* NHA_ID */
if (nh->is_group)
- sz += nh_nlmsg_size_grp(nh) +
+ sz += nh_nlmsg_size_grp(nh, op_flags) +
nla_total_size(4) + /* NHA_OP_FLAGS */
0;
else
@@ -1070,7 +1086,7 @@ static void nexthop_notify(int event, struct nexthop *nh, struct nl_info *info)
struct sk_buff *skb;
int err = -ENOBUFS;
- skb = nlmsg_new(nh_nlmsg_size(nh), gfp_any());
+ skb = nlmsg_new(nh_nlmsg_size(nh, 0), gfp_any());
if (!skb)
goto errout;
@@ -3376,15 +3392,15 @@ static int rtm_get_nexthop(struct sk_buff *in_skb, struct nlmsghdr *nlh,
if (err)
return err;
- err = -ENOBUFS;
- skb = alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL);
- if (!skb)
- goto out;
-
err = -ENOENT;
nh = nexthop_find_by_id(net, id);
if (!nh)
- goto errout_free;
+ goto out;
+
+ err = -ENOBUFS;
+ skb = nlmsg_new(nh_nlmsg_size(nh, op_flags), GFP_KERNEL);
+ if (!skb)
+ goto out;
err = nh_fill_node(skb, nh, RTM_NEWNEXTHOP, NETLINK_CB(in_skb).portid,
nlh->nlmsg_seq, 0, op_flags);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 2/5] dt-bindings: phy: ti: phy-gmii-sel: Add ti,j722s-phy-gmii-sel compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:27 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, 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
In-Reply-To: <5ac1c52827a1a246584dddb62335f9ce4715eceb.1775045279.git.nora.schiffer@ew.tq-group.com>
On Wed, Apr 01, 2026 at 02:25:22PM +0200, Nora Schiffer wrote:
> 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 | 24 ++++++++++++-------
> 1 file changed, 15 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..6e12a75100eb8 100644
> --- a/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,phy-gmii-sel.yaml
> @@ -47,15 +47,21 @@ 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:
> + - items:
Same comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: phy: ti: phy-j721e-wiz: Add ti,j722s-wiz-10g compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:28 UTC (permalink / raw)
To: Nora Schiffer
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Vinod Koul,
Neil Armstrong, 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
In-Reply-To: <b9d6a9322ce4f7dc3363dc00d93ab0256e12a8af.1775045279.git.nora.schiffer@ew.tq-group.com>
On Wed, Apr 01, 2026 at 02:25:21PM +0200, Nora Schiffer wrote:
> 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 | 20 ++++++++++++-------
> 1 file changed, 13 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..283e3eedc0f31 100644
> --- a/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
> +++ b/Documentation/devicetree/bindings/phy/ti,phy-j721e-wiz.yaml
> @@ -12,13 +12,19 @@ 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:
> + - items:
Same comments as for netdev patch.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] selftests/bpf: Reject malformed IPv4/IPv6 skb test input
From: sun jian @ 2026-04-02 7:35 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: ast, daniel, andrii, eddyz87, song, yonghong.song, john.fastabend,
kpsingh, sdf, haoluo, jolsa, davem, edumazet, kuba, pabeni, horms,
bpf, netdev, linux-kernel, syzbot+619b9ef527f510a57cfc
In-Reply-To: <ac33zzsqHlFc4GgE@devbig1721.ftw5.facebook.com>
On Thu, Apr 2, 2026 at 1:13 PM Martin KaFai Lau <martin.lau@linux.dev> wrote:
>
> On Thu, Apr 02, 2026 at 10:54:41AM +0800, sun jian wrote:
> > Ack, I'll respin a v2.
> >
> > BTW, v1 was mainly meant as a minimal proof of the fix, so I
> > kept the existing structure intact.
>
> This is already v2.
>
> The minimal proof of the fix is a selftest for a tricky case
> like this, instead of spamming the list, and now also the
> AI-review tokens, with an unlandable patch.
>
> It is a few line change, and I don't see how duplicating the
> existing switch case makes the RFC review easier.
You‘re right, I just noticed that I mixed up the version number.
I'll respin a v3 and include the selftest.
Sun Jian
^ permalink raw reply
* [PATCH v6 0/3] Add support for ICSSM Ethernet on AM57x, AM437x, and AM335x
From: Parvathi Pudi @ 2026-04-02 7:36 UTC (permalink / raw)
To: nm, vigneshr, afd, khilman, rogerq, tony, robh, krzk+dt, conor+dt,
richardcochran, aaro.koskinen, andreas
Cc: andrew, linux-omap, devicetree, linux-kernel, netdev, danishanwar,
pratheesh, j-rameshbabu, praneeth, srk, rogerq, krishna, mohan,
pmohan, basharath, parvathi
Hi,
This series adds support for ICSSM Ethernet on Texas Instruments AM57x,
AM437x and AM335x platforms.
The AM57x and AM437x IDKs support two PRU-ICSS instances, each consisting
of two PRU cores, with each PRU-ICSS instance capable of handling two
Ethernet ports. For the AM57x platforms, the PRU-ICSS2 node has been added
to the am57xx-idk-common.dtsi, while for the AM437x platform, the PRU-ICSS1
node has been added to the am437x-idk-evm.dts.
The AM335x ICE features a single PRU-ICSS instance. A new device tree overlay
source file, am335x-icev2-prueth-overlay.dtso, has been introduced to define the
PRU-ICSS node for the AM335x platform.
This is v6 of the patch series [v1]. It addresses comments made on [v5].
This series is based on the latest next-20260401 linux-next.
Changes from v5 to v6 :
*) Addressed Kevin Hilman, Krzysztof and Andrew lunn comments on patch 3 of
the series.
*) Fixed an issue with overlaying "output-low" property in "mux-mii-hog"
sub-node under "gpio3" node.
*) Rebased the series on latest linux-next.
Changes from v4 to v5 :
*) Addressed Andrew Davis's comments on patch 2 of the series.
*) Addressed Andrew Lunn and Nikolaus Schaller comments on patch 2 of the series.
*) Rebased the series on latest linux-next.
Changes from v3 to v4 :
*) No code changes were made, only the version was updated.
*) Rebased the series on latest linux-next.
Changes from v2 to v3 :
*) Addressed Andrew Davis's comment by placing PRUETH nodes in a new overlay file
am335x-icev2-prueth-overlay.dtso.
*) Rebased the series on latest linux-next.
Changes from v1 to v2 :
*) Addressed Andrew Lunn's comment on patch 1 of the series.
*) Addressed MD Danish Anwar comment on patch 1 of the series.
*) Rebased the series on latest linux-next.
[v1] https://lore.kernel.org/all/20251013125401.1435486-1-parvathi@couthit.com/
[v2] https://lore.kernel.org/all/20251103124820.1679167-1-parvathi@couthit.com/
[v3] https://lore.kernel.org/all/20251217130715.1327138-1-parvathi@couthit.com/
[v4] https://lore.kernel.org/all/20260105162546.1809714-1-parvathi@couthit.com/
[v5] https://lore.kernel.org/all/20260307122641.738450-1-parvathi@couthit.com/
Thanks and Regards,
Parvathi
Roger Quadros (3):
arm: dts: ti: Add device tree support for PRU-ICSS on AM57xx
arm: dts: ti: Add device tree support for PRU-ICSS on AM437x
arm: dts: ti: Add device tree support for PRU-ICSS on AM335x
arch/arm/boot/dts/ti/omap/Makefile | 4 +
.../ti/omap/am335x-icev2-prueth-overlay.dtso | 156 ++++++++++++++++++
arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi | 11 ++
arch/arm/boot/dts/ti/omap/am4372.dtsi | 11 ++
arch/arm/boot/dts/ti/omap/am437x-idk-evm.dts | 103 +++++++++++-
arch/arm/boot/dts/ti/omap/am57-pruss.dtsi | 11 ++
arch/arm/boot/dts/ti/omap/am571x-idk.dts | 8 +-
arch/arm/boot/dts/ti/omap/am572x-idk.dts | 10 +-
arch/arm/boot/dts/ti/omap/am574x-idk.dts | 10 +-
.../boot/dts/ti/omap/am57xx-idk-common.dtsi | 61 +++++++
10 files changed, 375 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/boot/dts/ti/omap/am335x-icev2-prueth-overlay.dtso
--
2.43.0
^ permalink raw reply
* [PATCH v6 1/3] arm: dts: ti: Add device tree support for PRU-ICSS on AM57xx
From: Parvathi Pudi @ 2026-04-02 7:36 UTC (permalink / raw)
To: nm, vigneshr, afd, khilman, rogerq, tony, robh, krzk+dt, conor+dt,
richardcochran, aaro.koskinen, andreas
Cc: andrew, linux-omap, devicetree, linux-kernel, netdev, danishanwar,
pratheesh, j-rameshbabu, praneeth, srk, rogerq, krishna, mohan,
pmohan, basharath, parvathi, Murali Karicheri
In-Reply-To: <20260402073853.2170099-1-parvathi@couthit.com>
From: Roger Quadros <rogerq@ti.com>
The TI Sitara AM57xx series of devices consists of 2 PRU-ICSS instances
(PRU-ICSS1 and PRU-ICSS2). This patch adds the device tree nodes for the
PRU-ICSS2 instance to support DUAL-MAC mode of operation.
Each PRU-ICSS instance consists of two PRU cores along with various
peripherals such as the Interrupt Controller (PRU_INTC), the Industrial
Ethernet Peripheral(IEP), the Real Time Media Independent Interface
controller (MII_RT), and the Enhanced Capture (eCAP) event module.
am57-pruss.dtsi - Adds IEP and eCAP peripheral as child nodes of
the PRUSS subsystem node.
am57xx-idk-common.dtsi - Adds PRU-ICSS2 instance node along with
PRU eth port information and corresponding port configuration. It includes
interrupt mapping for packet reception, HW timestamp collection, and
PRU Ethernet ports in MII mode.
am571x-idk.dts, am572x-idk.dts and am574x-idk.dts - GPIO configuration
along with delay configuration for individual PRU Ethernet port.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Basharath Hussain Khaja <basharath@couthit.com>
Signed-off-by: Parvathi Pudi <parvathi@couthit.com>
---
arch/arm/boot/dts/ti/omap/am57-pruss.dtsi | 11 ++++
arch/arm/boot/dts/ti/omap/am571x-idk.dts | 8 ++-
arch/arm/boot/dts/ti/omap/am572x-idk.dts | 10 +--
arch/arm/boot/dts/ti/omap/am574x-idk.dts | 10 +--
.../boot/dts/ti/omap/am57xx-idk-common.dtsi | 61 +++++++++++++++++++
5 files changed, 91 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/am57-pruss.dtsi b/arch/arm/boot/dts/ti/omap/am57-pruss.dtsi
index 46c5383f0eee..f73316625608 100644
--- a/arch/arm/boot/dts/ti/omap/am57-pruss.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am57-pruss.dtsi
@@ -170,6 +170,17 @@ pruss2_iepclk_mux: iepclk-mux@30 {
};
};
+ pruss2_iep: iep@2e000 {
+ compatible = "ti,am5728-icss-iep";
+ reg = <0x2e000 0x31c>;
+ clocks = <&pruss2_iepclk_mux>;
+ };
+
+ pruss2_ecap: ecap@30000 {
+ compatible = "ti,pruss-ecap";
+ reg = <0x30000 0x60>;
+ };
+
pruss2_mii_rt: mii-rt@32000 {
compatible = "ti,pruss-mii", "syscon";
reg = <0x32000 0x58>;
diff --git a/arch/arm/boot/dts/ti/omap/am571x-idk.dts b/arch/arm/boot/dts/ti/omap/am571x-idk.dts
index 322cf79d22e9..02653b440585 100644
--- a/arch/arm/boot/dts/ti/omap/am571x-idk.dts
+++ b/arch/arm/boot/dts/ti/omap/am571x-idk.dts
@@ -214,5 +214,11 @@ &pruss1_mdio {
};
&pruss2_mdio {
- status = "disabled";
+ reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <2>; /* PHY datasheet states 1uS min */
+};
+
+&pruss2_eth {
+ ti,pruss-gp-mux-sel = <4>, /* MII2, needed for PRUSS1_MII0 */
+ <4>; /* MII2, needed for PRUSS1_MII1 */
};
diff --git a/arch/arm/boot/dts/ti/omap/am572x-idk.dts b/arch/arm/boot/dts/ti/omap/am572x-idk.dts
index 94a738cb0a4d..54a8ccb9ca14 100644
--- a/arch/arm/boot/dts/ti/omap/am572x-idk.dts
+++ b/arch/arm/boot/dts/ti/omap/am572x-idk.dts
@@ -28,10 +28,12 @@ &mmc2 {
pinctrl-2 = <&mmc2_pins_ddr_rev20>;
};
-&pruss1_mdio {
- status = "disabled";
+&pruss2_eth0_phy {
+ reset-gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <2>; /* PHY datasheet states 1uS min */
};
-&pruss2_mdio {
- status = "disabled";
+&pruss2_eth1_phy {
+ reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <2>; /* PHY datasheet states 1uS min */
};
diff --git a/arch/arm/boot/dts/ti/omap/am574x-idk.dts b/arch/arm/boot/dts/ti/omap/am574x-idk.dts
index 47b9174d2353..47b6c6cb210c 100644
--- a/arch/arm/boot/dts/ti/omap/am574x-idk.dts
+++ b/arch/arm/boot/dts/ti/omap/am574x-idk.dts
@@ -40,10 +40,12 @@ &emif1 {
status = "okay";
};
-&pruss1_mdio {
- status = "disabled";
+&pruss2_eth0_phy {
+ reset-gpios = <&gpio5 8 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <2>; /* PHY datasheet states 1uS min */
};
-&pruss2_mdio {
- status = "disabled";
+&pruss2_eth1_phy {
+ reset-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <2>; /* PHY datasheet states 1uS min */
};
diff --git a/arch/arm/boot/dts/ti/omap/am57xx-idk-common.dtsi b/arch/arm/boot/dts/ti/omap/am57xx-idk-common.dtsi
index 43e3623f079c..5eccff3bb4b6 100644
--- a/arch/arm/boot/dts/ti/omap/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am57xx-idk-common.dtsi
@@ -155,6 +155,52 @@ src_clk_x1: src_clk_x1 {
compatible = "fixed-clock";
clock-frequency = <20000000>;
};
+
+ /* Dual-MAC Ethernet application node on PRU-ICSS2 */
+ pruss2_eth: pruss2-eth {
+ compatible = "ti,am57-prueth";
+ ti,prus = <&pru2_0>, <&pru2_1>;
+ sram = <&ocmcram1>;
+ ti,mii-rt = <&pruss2_mii_rt>;
+ ti,iep = <&pruss2_iep>;
+ ti,ecap = <&pruss2_ecap>;
+ interrupts = <20 2 2>, <21 3 3>;
+ interrupt-names = "rx_hp", "rx_lp";
+ interrupt-parent = <&pruss2_intc>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pruss2_emac0: ethernet-port@0 {
+ reg = <0>;
+ phy-handle = <&pruss2_eth0_phy>;
+ phy-mode = "mii";
+ interrupts = <20 2 2>, <26 6 6>, <23 6 6>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+
+ pruss2_emac1: ethernet-port@1 {
+ reg = <1>;
+ phy-handle = <&pruss2_eth1_phy>;
+ phy-mode = "mii";
+ interrupts = <21 3 3>, <27 9 7>, <24 9 7>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
+
+};
+
+&pruss2_iep {
+ interrupt-parent = <&pruss2_intc>;
+ interrupts = <7 7 8>;
+ interrupt-names = "iep_cap_cmp";
};
&dra7_pmx_core {
@@ -606,3 +652,18 @@ dpi_out: endpoint {
};
};
};
+
+&pruss2_mdio {
+ status = "okay";
+ pruss2_eth0_phy: ethernet-phy@0 {
+ reg = <0>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pruss2_eth1_phy: ethernet-phy@1 {
+ reg = <1>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v6 2/3] arm: dts: ti: Add device tree support for PRU-ICSS on AM437x
From: Parvathi Pudi @ 2026-04-02 7:36 UTC (permalink / raw)
To: nm, vigneshr, afd, khilman, rogerq, tony, robh, krzk+dt, conor+dt,
richardcochran, aaro.koskinen, andreas
Cc: andrew, linux-omap, devicetree, linux-kernel, netdev, danishanwar,
pratheesh, j-rameshbabu, praneeth, srk, rogerq, krishna, mohan,
pmohan, basharath, parvathi, Murali Karicheri
In-Reply-To: <20260402073853.2170099-1-parvathi@couthit.com>
From: Roger Quadros <rogerq@ti.com>
The TI Sitara AM437x series of devices consists of 2 PRU-ICSS instances
(PRU-ICSS0 and PRU-ICSS1). This patch adds the device tree nodes for the
PRU-ICSS1 instance to support DUAL-MAC mode of operation. Support for
Ethernet over PRU is available only for ICSS1 instance.
PRU-ICSS instance consists of two PRU cores along with various
peripherals such as the Interrupt Controller (PRU_INTC), the Industrial
Ethernet Peripheral(IEP), the Real Time Media Independent Interface
controller (MII_RT), and the Enhanced Capture (eCAP) event module.
am4372.dtsi - Adds IEP and eCAP peripheral as child nodes of the PRUSS
subsystem node.
am437x-idk-evm.dts - Adds PRU-ICSS instance node along with PRU eth port
information and corresponding port configuration. It includes interrupt
mapping for packet reception, HW timestamp collection, and PRU Ethernet
ports in MII mode,
GPIO configuration, boot strapping along with delay configuration for
individual PRU Ethernet port and other required nodes.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Basharath Hussain Khaja <basharath@couthit.com>
Signed-off-by: Parvathi Pudi <parvathi@couthit.com>
---
arch/arm/boot/dts/ti/omap/am4372.dtsi | 11 ++
arch/arm/boot/dts/ti/omap/am437x-idk-evm.dts | 103 ++++++++++++++++++-
2 files changed, 113 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ti/omap/am4372.dtsi b/arch/arm/boot/dts/ti/omap/am4372.dtsi
index 504fa6b57d39..494f251c8e6a 100644
--- a/arch/arm/boot/dts/ti/omap/am4372.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am4372.dtsi
@@ -476,6 +476,17 @@ pruss1_mii_rt: mii-rt@32000 {
reg = <0x32000 0x58>;
};
+ pruss1_iep: iep@2e000 {
+ compatible = "ti,am4376-icss-iep";
+ reg = <0x2e000 0x31c>;
+ clocks = <&pruss1_iepclk_mux>;
+ };
+
+ pruss1_ecap: ecap@30000 {
+ compatible = "ti,pruss-ecap";
+ reg = <0x30000 0x60>;
+ };
+
pruss1_intc: interrupt-controller@20000 {
compatible = "ti,pruss-intc";
reg = <0x20000 0x2000>;
diff --git a/arch/arm/boot/dts/ti/omap/am437x-idk-evm.dts b/arch/arm/boot/dts/ti/omap/am437x-idk-evm.dts
index 826f687c368a..2efa303d45be 100644
--- a/arch/arm/boot/dts/ti/omap/am437x-idk-evm.dts
+++ b/arch/arm/boot/dts/ti/omap/am437x-idk-evm.dts
@@ -168,6 +168,48 @@ led-out7 {
default-state = "off";
};
};
+
+ /* Dual-MAC Ethernet application node on PRU-ICSS1 */
+ pruss1_eth: pruss1-eth {
+ compatible = "ti,am4376-prueth";
+ ti,prus = <&pru1_0>, <&pru1_1>;
+ sram = <&ocmcram>;
+ ti,mii-rt = <&pruss1_mii_rt>;
+ ti,iep = <&pruss1_iep>;
+ ti,ecap = <&pruss1_ecap>;
+ interrupts = <20 2 2>, <21 3 3>;
+ interrupt-names = "rx_hp", "rx_lp";
+ interrupt-parent = <&pruss1_intc>;
+
+ pinctrl-0 = <&pruss1_eth_default>;
+ pinctrl-names = "default";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pruss1_emac0: ethernet-port@0 {
+ reg = <0>;
+ phy-handle = <&pruss1_eth0_phy>;
+ phy-mode = "mii";
+ interrupts = <20 2 2>, <26 6 6>, <23 6 6>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+
+ pruss1_emac1: ethernet-port@1 {
+ reg = <1>;
+ phy-handle = <&pruss1_eth1_phy>;
+ phy-mode = "mii";
+ interrupts = <21 3 3>, <27 9 5>, <24 9 5>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
};
&am43xx_pinmux {
@@ -303,6 +345,52 @@ AM4372_IOPAD(0x94c, PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};
+ pruss1_mdio_default: pruss1-mdio-default-pins {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x88c, PIN_OUTPUT | MUX_MODE5) /* (A12) gpmc_clk.pr1_mdio_mdclk */
+ AM4372_IOPAD(0xa70, PIN_INPUT | MUX_MODE8) /* (D24) xdma_event_intr0.pr1_mdio_data */
+ AM4372_IOPAD(0xa00, PIN_INPUT_PULLUP | MUX_MODE7) /* (AD23) cam1_data6.gpio4[20] */
+ >;
+ };
+
+ pruss1_eth_default: pruss1-eth-default-pins {
+ pinctrl-single,pins = <
+ AM4372_IOPAD(0x8a0, PIN_INPUT | MUX_MODE2) /* (B22) dss_data0.pr1_mii_mt0_clk */
+ AM4372_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE2) /* (B20) dss_data5.pr1_mii0_txd0 */
+ AM4372_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE2) /* (A20) dss_data4.pr1_mii0_txd1 */
+ AM4372_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE2) /* (C21) dss_data3.pr1_mii0_txd2 */
+ AM4372_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE2) /* (B21) dss_data2.pr1_mii0_txd3 */
+ AM4372_IOPAD(0x8cc, PIN_INPUT | MUX_MODE5) /* (B18) dss_data11.pr1_mii0_rxd0 */
+ AM4372_IOPAD(0x8c8, PIN_INPUT | MUX_MODE5) /* (A18) dss_data10.pr1_mii0_rxd1 */
+ AM4372_IOPAD(0x8c4, PIN_INPUT | MUX_MODE5) /* (B19) dss_data9.pr1_mii0_rxd2 */
+ AM4372_IOPAD(0x8c0, PIN_INPUT | MUX_MODE5) /* (A19) dss_data8.pr1_mii0_rxd3 */
+ AM4372_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE2) /* (A21) dss_data1.pr1_mii0_txen */
+ AM4372_IOPAD(0x8d8, PIN_INPUT | MUX_MODE5) /* (C17) dss_data14.pr1_mii_mr0_clk */
+ AM4372_IOPAD(0x8dc, PIN_INPUT | MUX_MODE5) /* (D17) dss_data15.pr1_mii0_rxdv */
+ AM4372_IOPAD(0x8d4, PIN_INPUT | MUX_MODE5) /* (D19) dss_data13.pr1_mii0_rxer */
+ AM4372_IOPAD(0x8d0, PIN_INPUT | MUX_MODE5) /* (C19) dss_data12.pr1_mii0_rxlink */
+ AM4372_IOPAD(0xa40, PIN_INPUT | MUX_MODE5) /* (G20) gpio5_10.pr1_mii0_crs */
+ AM4372_IOPAD(0xa38, PIN_INPUT | MUX_MODE5) /* (D25) gpio5_8.pr1_mii0_col */
+
+ AM4372_IOPAD(0x858, PIN_INPUT | MUX_MODE5) /* (E8) gpmc_a6.pr1_mii_mt1_clk */
+ AM4372_IOPAD(0x854, PIN_OUTPUT | MUX_MODE5) /* (E7) gpmc_a5.pr1_mii1_txd0 */
+ AM4372_IOPAD(0x850, PIN_OUTPUT | MUX_MODE5) /* (D7) gpmc_a4.pr1_mii1_txd1 */
+ AM4372_IOPAD(0x84c, PIN_OUTPUT | MUX_MODE5) /* (A4) gpmc_a3.pr1_mii1_txd2 */
+ AM4372_IOPAD(0x848, PIN_OUTPUT | MUX_MODE5) /* (C6) gpmc_a2.pr1_mii1_txd3 */
+ AM4372_IOPAD(0x86c, PIN_INPUT | MUX_MODE5) /* (D8) gpmc_a11.pr1_mii1_rxd0 */
+ AM4372_IOPAD(0x868, PIN_INPUT | MUX_MODE5) /* (G8) gpmc_a10.pr1_mii1_rxd1 */
+ AM4372_IOPAD(0x864, PIN_INPUT | MUX_MODE5) /* (B4) gpmc_a9.pr1_mii1_rxd2 */
+ AM4372_IOPAD(0x860, PIN_INPUT | MUX_MODE5) /* (F7) gpmc_a8.pr1_mii1_rxd3 */
+ AM4372_IOPAD(0x840, PIN_OUTPUT | MUX_MODE5) /* (C3) gpmc_a0.pr1_mii1_txen */
+ AM4372_IOPAD(0x85c, PIN_INPUT | MUX_MODE5) /* (F6) gpmc_a7.pr1_mii_mr1_clk */
+ AM4372_IOPAD(0x844, PIN_INPUT | MUX_MODE5) /* (C5) gpmc_a1.pr1_mii1_rxdv */
+ AM4372_IOPAD(0x874, PIN_INPUT | MUX_MODE5) /* (B3) gpmc_wpn.pr1_mii1_rxer */
+ AM4372_IOPAD(0xa4c, PIN_INPUT | MUX_MODE5) /* (E24) gpio5_13.pr1_mii1_rxlink */
+ AM4372_IOPAD(0xa44, PIN_INPUT | MUX_MODE5) /* (F23) gpio5_11.pr1_mii1_crs */
+ AM4372_IOPAD(0x878, PIN_INPUT | MUX_MODE5) /* (A3) gpmc_be1n.pr1_mii1_col */
+ >;
+ };
+
qspi_pins_default: qspi-default-pins {
pinctrl-single,pins = <
AM4372_IOPAD(0x87c, PIN_OUTPUT_PULLUP | MUX_MODE3) /* gpmc_csn0.qspi_csn */
@@ -539,5 +627,18 @@ opp-100-600000000 {
};
&pruss1_mdio {
- status = "disabled";
+ pinctrl-0 = <&pruss1_mdio_default>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ reset-gpios = <&gpio4 20 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <2>; /* PHY datasheet states 1uS min */
+
+ pruss1_eth0_phy: ethernet-phy@0 {
+ reg = <0>;
+ };
+
+ pruss1_eth1_phy: ethernet-phy@1 {
+ reg = <1>;
+ };
};
--
2.43.0
^ permalink raw reply related
* [PATCH v6 3/3] arm: dts: ti: Add device tree support for PRU-ICSS on AM335x
From: Parvathi Pudi @ 2026-04-02 7:36 UTC (permalink / raw)
To: nm, vigneshr, afd, khilman, rogerq, tony, robh, krzk+dt, conor+dt,
richardcochran, aaro.koskinen, andreas
Cc: andrew, linux-omap, devicetree, linux-kernel, netdev, danishanwar,
pratheesh, j-rameshbabu, praneeth, srk, rogerq, krishna, mohan,
pmohan, basharath, parvathi, Murali Karicheri
In-Reply-To: <20260402073853.2170099-1-parvathi@couthit.com>
From: Roger Quadros <rogerq@ti.com>
The TI Sitara AM335x ICE-V2 consists of single PRU-ICSS instance,
This patch adds the new device tree overlay file in-order to enable
PRU-ICSS instance, along with makefile changes.
PRU-ICSS instance consists of two PRU cores along with various
peripherals such as the Interrupt Controller (PRU_INTC), the Industrial
Ethernet Peripheral(IEP), the Real Time Media Independent Interface
controller (MII_RT), and the Enhanced Capture (eCAP) event module.
am33xx-l4.dtsi - Adds IEP and eCAP peripheral as child nodes
of the PRUSS subsystem node.
am335x-icev2-prueth.dtso - Adds PRU-ICSS instance node along with PRU
eth port information and corresponding port configuration. It includes
interrupt mapping for packet reception, HW timestamp collection, and PRU
Ethernet ports in MII mode,
GPIO configuration, boot strapping along with delay configuration for
individual PRU Ethernet port and other required nodes.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Basharath Hussain Khaja <basharath@couthit.com>
Signed-off-by: Parvathi Pudi <parvathi@couthit.com>
---
arch/arm/boot/dts/ti/omap/Makefile | 4 +
.../ti/omap/am335x-icev2-prueth-overlay.dtso | 156 ++++++++++++++++++
arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi | 11 ++
3 files changed, 171 insertions(+)
create mode 100644 arch/arm/boot/dts/ti/omap/am335x-icev2-prueth-overlay.dtso
diff --git a/arch/arm/boot/dts/ti/omap/Makefile b/arch/arm/boot/dts/ti/omap/Makefile
index 3a4d9204339b..498c36ccb5ea 100644
--- a/arch/arm/boot/dts/ti/omap/Makefile
+++ b/arch/arm/boot/dts/ti/omap/Makefile
@@ -88,6 +88,9 @@ dtb-$(CONFIG_ARCH_OMAP4) += \
am335x-bonegreen-hdmi-00a0-dtbs := am335x-bonegreen-eco.dtb \
am335x-bone-hdmi-00a0.dtbo
+am335x-icev2-prueth-dtbs := am335x-icev2.dtb \
+ am335x-icev2-prueth-overlay.dtbo
+
dtb-$(CONFIG_SOC_AM33XX) += \
am335x-baltos-ir2110.dtb \
am335x-baltos-ir3220.dtb \
@@ -106,6 +109,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-evmsk.dtb \
am335x-guardian.dtb \
am335x-icev2.dtb \
+ am335x-icev2-prueth.dtb \
am335x-lxm.dtb \
am335x-mba335x.dtb \
am335x-moxa-uc-2101.dtb \
diff --git a/arch/arm/boot/dts/ti/omap/am335x-icev2-prueth-overlay.dtso b/arch/arm/boot/dts/ti/omap/am335x-icev2-prueth-overlay.dtso
new file mode 100644
index 000000000000..ffed1f3d046a
--- /dev/null
+++ b/arch/arm/boot/dts/ti/omap/am335x-icev2-prueth-overlay.dtso
@@ -0,0 +1,156 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT overlay for IDK AM335x
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/*
+ * AM335x ICE V2 board
+ * http://www.ti.com/tool/tmdsice3359
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/bus/ti-sysc.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/am33xx.h>
+#include <dt-bindings/clock/am3.h>
+
+&{/} {
+ /* Dual-MAC Ethernet application node on PRU-ICSS */
+ pruss_eth: pruss-eth {
+ compatible = "ti,am3359-prueth";
+ ti,prus = <&pru0>, <&pru1>;
+ sram = <&ocmcram>;
+ ti,mii-rt = <&pruss_mii_rt>;
+ ti,iep = <&pruss_iep>;
+ ti,ecap = <&pruss_ecap>;
+ interrupts = <20 2 2>, <21 3 3>;
+ interrupt-names = "rx_hp", "rx_lp";
+ interrupt-parent = <&pruss_intc>;
+
+ pinctrl-0 = <&pruss_eth_default>;
+ pinctrl-names = "default";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pruss_emac0: ethernet-port@0 {
+ reg = <0>;
+ phy-handle = <&pruss_eth0_phy>;
+ phy-mode = "mii";
+ interrupts = <20 2 2>, <26 6 6>, <23 6 6>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+
+ pruss_emac1: ethernet-port@1 {
+ reg = <1>;
+ phy-handle = <&pruss_eth1_phy>;
+ phy-mode = "mii";
+ interrupts = <21 3 3>, <27 9 7>, <24 9 7>;
+ interrupt-names = "rx", "emac_ptp_tx",
+ "hsr_ptp_tx";
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
+};
+
+&am33xx_pinmux {
+ /* MDIO node for PRU-ICSS */
+ pruss_mdio_default: pruss-mdio-default-pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x88c, PIN_OUTPUT | MUX_MODE5) /* (V12) gpmc_clk.pr1_mdio_mdclk */
+ AM33XX_IOPAD(0x888, PIN_INPUT | MUX_MODE5) /* (T13) gpmc_csn3.pr1_mdio_data */
+ >;
+ };
+
+ /* Pinmux configuration for PRU-ICSS */
+ pruss_eth_default: pruss-eth-default-pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x8a0, PIN_INPUT | MUX_MODE2) /* (R1) lcd_data0.pr1_mii_mt0_clk */
+ AM33XX_IOPAD(0x8b4, PIN_OUTPUT | MUX_MODE2) /* (T2) lcd_data5.pr1_mii0_txd0 */
+ AM33XX_IOPAD(0x8b0, PIN_OUTPUT | MUX_MODE2) /* (T1) lcd_data4.pr1_mii0_txd1 */
+ AM33XX_IOPAD(0x8ac, PIN_OUTPUT | MUX_MODE2) /* (R4) lcd_data3.pr1_mii0_txd2 */
+ AM33XX_IOPAD(0x8a8, PIN_OUTPUT | MUX_MODE2) /* (R3) lcd_data2.pr1_mii0_txd3 */
+ AM33XX_IOPAD(0x8cc, PIN_INPUT | MUX_MODE5) /* (U4) lcd_data11.pr1_mii0_rxd0 */
+ AM33XX_IOPAD(0x8c8, PIN_INPUT | MUX_MODE5) /* (U3) lcd_data10.pr1_mii0_rxd1 */
+ AM33XX_IOPAD(0x8c4, PIN_INPUT | MUX_MODE5) /* (U2) lcd_data9.pr1_mii0_rxd2 */
+ AM33XX_IOPAD(0x8c0, PIN_INPUT | MUX_MODE5) /* (U1) lcd_data8.pr1_mii0_rxd3 */
+ AM33XX_IOPAD(0x8a4, PIN_OUTPUT | MUX_MODE2) /* (R2) lcd_data1.pr1_mii0_txen */
+ AM33XX_IOPAD(0x8d8, PIN_INPUT | MUX_MODE5) /* (V4) lcd_data14.pr1_mii_mr0_clk */
+ AM33XX_IOPAD(0x8dc, PIN_INPUT | MUX_MODE5) /* (T5) lcd_data15.pr1_mii0_rxdv */
+ AM33XX_IOPAD(0x8d4, PIN_INPUT | MUX_MODE5) /* (V3) lcd_data13.pr1_mii0_rxer */
+ AM33XX_IOPAD(0x8d0, PIN_INPUT | MUX_MODE5) /* (V2) lcd_data12.pr1_mii0_rxlink */
+ AM33XX_IOPAD(0x8e8, PIN_INPUT | MUX_MODE2) /* (V5) lcd_pclk.pr1_mii0_crs */
+
+ AM33XX_IOPAD(0x840, PIN_INPUT | MUX_MODE5) /* (R13) gpmc_a0.pr1_mii_mt1_clk */
+ AM33XX_IOPAD(0x850, PIN_OUTPUT | MUX_MODE5) /* (R14) gpmc_a4.pr1_mii1_txd0 */
+ AM33XX_IOPAD(0x84c, PIN_OUTPUT | MUX_MODE5) /* (T14) gpmc_a3.pr1_mii1_txd1 */
+ AM33XX_IOPAD(0x848, PIN_OUTPUT | MUX_MODE5) /* (U14) gpmc_a2.pr1_mii1_txd2 */
+ AM33XX_IOPAD(0x844, PIN_OUTPUT | MUX_MODE5) /* (V14) gpmc_a1.pr1_mii1_txd3 */
+ AM33XX_IOPAD(0x860, PIN_INPUT | MUX_MODE5) /* (V16) gpmc_a8.pr1_mii1_rxd0 */
+ AM33XX_IOPAD(0x85c, PIN_INPUT | MUX_MODE5) /* (T15) gpmc_a7.pr1_mii1_rxd1 */
+ AM33XX_IOPAD(0x858, PIN_INPUT | MUX_MODE5) /* (U15) gpmc_a6.pr1_mii1_rxd2 */
+ AM33XX_IOPAD(0x854, PIN_INPUT | MUX_MODE5) /* (V15) gpmc_a5.pr1_mii1_rxd3 */
+ AM33XX_IOPAD(0x874, PIN_OUTPUT | MUX_MODE5) /* (U17) gpmc_wpn.pr1_mii1_txen */
+ AM33XX_IOPAD(0x864, PIN_INPUT | MUX_MODE5) /* (U16) gpmc_a9.pr1_mii_mr1_clk */
+ AM33XX_IOPAD(0x868, PIN_INPUT | MUX_MODE5) /* (T16) gpmc_a10.pr1_mii1_rxdv */
+ AM33XX_IOPAD(0x86c, PIN_INPUT | MUX_MODE5) /* (V17) gpmc_a11.pr1_mii1_rxer */
+ AM33XX_IOPAD(0x878, PIN_INPUT | MUX_MODE5) /* (U18) gpmc_be1n.pr1_mii1_rxlink */
+ AM33XX_IOPAD(0x8ec, PIN_INPUT | MUX_MODE2) /* (R6) lcd_ac_bias_en.pr1_mii1_crs */
+ >;
+ };
+};
+
+&gpio3 {
+ mux-mii-hog {
+ status = "disabled";
+ };
+
+ mux-mii-hog-0 {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ /* ETH1 mux: Low for MII-PRU, high for RMII-CPSW */
+ output-low;
+ line-name = "MUX_MII_CTL1";
+ };
+};
+
+/*
+ * Disable CPSW switch node and
+ * MDIO configuration to prevent
+ * conflict with PRU-ICSS
+ */
+&mac_sw {
+ status = "disabled";
+};
+
+&davinci_mdio_sw {
+ status = "disabled";
+};
+
+/* PRU-ICSS MDIO configuration */
+&pruss_mdio {
+ pinctrl-0 = <&pruss_mdio_default>;
+ pinctrl-names = "default";
+ reset-gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
+ reset-delay-us = <2>; /* PHY datasheet states 1uS min */
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pruss_eth0_phy: ethernet-phy@1 {
+ reg = <1>;
+ };
+
+ pruss_eth1_phy: ethernet-phy@3 {
+ reg = <3>;
+ };
+};
diff --git a/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi b/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
index 89d16fcc773e..a63ef307d918 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx-l4.dtsi
@@ -896,6 +896,17 @@ pruss_mii_rt: mii-rt@32000 {
reg = <0x32000 0x58>;
};
+ pruss_iep: iep@2e000 {
+ compatible = "ti,am3356-icss-iep";
+ reg = <0x2e000 0x31c>;
+ clocks = <&pruss_iepclk_mux>;
+ };
+
+ pruss_ecap: ecap@30000 {
+ compatible = "ti,pruss-ecap";
+ reg = <0x30000 0x60>;
+ };
+
pruss_intc: interrupt-controller@20000 {
compatible = "ti,pruss-intc";
reg = <0x20000 0x2000>;
--
2.43.0
^ permalink raw reply related
* Re: "Dead loop on virtual device" error without softirq-BKL on PREEMPT_RT
From: Daniel Vacek @ 2026-04-02 7:50 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: edumazet, kuba, linux-kernel, linux-rt-devel, netdev, spasswolf,
tglx, Aaron Tomlin
In-Reply-To: <20260402070319.vhRd6c-f@linutronix.de>
On Thu, 2 Apr 2026 at 09:03, Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
> On 2026-04-01 18:55:43 [+0200], Daniel Vacek wrote:
> > > > > The above was me thinking and does not even compile for !RT. Commit
> > > > > b824c3e16c190 ("net: Provide a PREEMPT_RT specific check for
> > > > > netdev_queue::_xmit_lock") is what was merged in the end.
> >
> > Thinking about it again, wouldn't it be better to have one generic
> > solution rather then special-casing for PREEMPT_RT vs. !PREEMPT_RT?
>
> PREEMPT_RT and !PREEMPT_RT is fundamentally different here. The one is
> not preemptible and records the CPU of the lock owner to detect a
> recursive deadlock.
> The other is preemptible, uses a different locking type/ class which
> records the lock owner which can be utilised for this purpose.
I understand that (or at least I think I do).
My idea was that the non-preemptible one can record `current` task
instead of the CPU to detect the deadlock. And that would also work
for the preemptible case (it would actually match the lock owner
approach as you did for the PREEMPT_RT case).
One code for both configurations, no special-casing. I'd argue that's
a better result. Am I missing something?
The size of the netdev_queue structure would grow by 8 bytes for !RT
case, but that's not a big deal, IMO. For RT case it would just fill
the hole.
--nX
> A generic thing would be to remove this and rely on lockdep. This could
> work if it is only a devel thing and never "I setup something and make a
> loop" sort of thing.
>
> > --nX
>
> Sebastian
^ permalink raw reply
* Re: RFC: phylink: disable PHY autonomous EEE when MAC manages LPI
From: Nicolai Buchwitz @ 2026-04-02 7:53 UTC (permalink / raw)
To: Russell King (Oracle); +Cc: Andrew Lunn, netdev
In-Reply-To: <ac1Bj-02_ob7UPjh@shell.armlinux.org.uk>
On 1.4.2026 18:02, Russell King (Oracle) wrote:
> On Wed, Apr 01, 2026 at 05:38:23PM +0200, Andrew Lunn wrote:
>> On Wed, Apr 01, 2026 at 04:05:32PM +0100, Russell King (Oracle) wrote:
>> > On Wed, Apr 01, 2026 at 03:11:24PM +0200, Andrew Lunn wrote:
>> > > > Thanks Russell and Andrew. You're both heading in the same direction,
>> > > > so to make sure I understand correctly:
>> > > >
>> > > > 1. Add a new phylib interface (separate from phy_ethtool_set_eee) to
>> > > > control PHY-autonomous EEE, e.g. phy_set_autonomous_eee(phydev,
>> > > > enable) and phy_get_autonomous_eee(phydev) to query the current
>> > > > state.
>> > >
>> > > In the end, we want the MAC driver using phylib to just call the
>> > > phylib methods for configuring EEE, and the MAC driver should not care
>> > > if EEE is actually implemented in the PHY or the MAC. The adjust_link
>> > > callback would simply not enable LPI if the PHY is doing EEE.
>> >
>> > This won't work.
>> >
>> > If we mask out eee.tx_lpi_enabled when calling into phylib to tell
>> > phylib drivers to disable SmartEEE (that's what I'm calling it here
>> > because it's easier to type)),
>>
>> We need phylib to handle some state information. Are we doing MAC EEE
>> or SmartEEE? We can then set phydev->enable_tx_lpi == True to indicate
>> if the MAC should be sending LPI indications, if and only if the
>> phylib knows we are doing MAC EEE and it should be enabled because the
>> user said so.
>
> Right, and that's why I suggested phy_disable_autonomous_eee() to tell
> phylib to disable SmartEEE/autonomous EEE support at the PHY
> independent
> of phy_ethtool_set_eee().
>
> I was also suggesting that there's eventually a complementary function
> that says basically "please enable SmartEEE" because we may have phy
> drivers that disable it today.
>
> In absence of either call, phy drivers need to maintain their current
> state.
>
>> However, i think this is down the road. If the MAC driver calls
>> phy_support_eee(), we should call the SmartEEE disable method of the
>> PHY driver. When we add support for SmartEEE then we need this
>> additional state information.
>
> That also works for me.
Thanks both. So if I understand correctly:
1. Add a .disable_autonomous_eee callback to struct phy_driver
2. Call it from phy_support_eee() so MAC drivers don't need to know
or care whether the PHY does (autonomous|smart)eee
3. BCM54xx (AutogrEEEn) and RTL8211F as first users
4. No enable counterpart for now. PHY drivers maintain their current
default behavior unless phy_support_eee() is called.
Sounds good. Sorting out the warts of (autonomous|smart)eee will be
iterative anyway, so starting with just the disable path makes sense
(and hopefully will make setups a bit less broken than they were with
both fighting for LPI).
I'll put the RFC patches together.
Nicolai
^ permalink raw reply
* Re: [PATCH net-next v36 1/8] eea: introduce PCI framework
From: Paolo Abeni @ 2026-04-02 8:02 UTC (permalink / raw)
To: Xuan Zhuo, netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Wen Gu, Philo Lu, Vadim Fedorenko, Dong Yibo, Heiner Kallweit,
Dust Li
In-Reply-To: <20260329132222.130912-2-xuanzhuo@linux.alibaba.com>
On 3/29/26 3:22 PM, Xuan Zhuo wrote:
> +struct eea_pci_cfg {
> + __le32 reserve0;
> + __le32 reserve1;
> + __le32 drv_f_idx;
> + __le32 drv_f;
> +
> +#define EEA_S_OK BIT(2)
> +#define EEA_S_FEATURE_DONE BIT(3)
> +#define EEA_S_FAILED BIT(7)
> + u8 device_status;
> + u8 reserved[7];
> +
> + __le32 rx_num_max;
> + __le32 tx_num_max;
> + __le32 db_blk_size;
> +
> + /* admin queue cfg */
> + __le16 aq_size;
> + __le16 aq_msix_vector;
> + __le32 aq_db_off;
> +
> + __le32 aq_sq_addr;
> + __le32 aq_sq_addr_hi;
> + __le32 aq_cq_addr;
> + __le32 aq_cq_addr_hi;
> +
> + __le64 hw_ts;
Sashiko has still a lot to say about this series. Here:
---
Is there an implicit compiler padding issue here?
The field aq_cq_addr_hi is a 32-bit integer ending at offset 59. The
immediately following field, hw_ts, is an 8-byte integer. To align hw_ts
to an 8-byte boundary, the compiler will implicitly insert 4 bytes of
padding, placing hw_ts at offset 64 instead of 60.
Depending on whether the hardware designer intended the register to be
at offset 60 or 64, the driver might read from the wrong address, or
rely on implicit padding that could change across architectures.
---
I assume the (virtual) H/W does the align thing correctly, so no real
issue here. Still replying to this patch explaining why the raised
concern is not valid would help a lot progresses on this series.
[ ... ]
> +int eea_device_reset(struct eea_device *edev)
> +{
> + struct eea_pci_device *ep_dev = edev->ep_dev;
> + u8 val;
> +
> + eea_pci_io_set_status(edev, 0);
> +
> + return read_poll_timeout(cfg_read8, val, !val, 20, EEA_RESET_TIMEOUT_US,
> + false, ep_dev->reg, device_status);
> +}
Sashiko says:
---
Can this cause a 60-second thread stall during a surprise removal?
When a PCIe device is surprise-removed, MMIO reads typically return all
ones (0xFF). If the device is removed, !0xFF evaluates to false, causing
the loop to never exit early and hanging the executing thread for the
entire 60-second timeout.
---
A similar concern was raised on the previous iteration. I see you
decreased the timeout from 1000s to 60s, but 60s is still a considerably
longsystem hangup. Anything above a few seconds should be considered
carefully.
> +
> +int eea_pci_set_aq_up(struct eea_device *edev)
> +{
> + struct eea_pci_device *ep_dev = edev->ep_dev;
> + u8 status = eea_pci_io_get_status(edev);
> + int err;
> + u8 val;
> +
> + WARN_ON(status & EEA_S_OK);
Sashiko says:
---
Does a surprise removal trigger a spurious kernel warning here?
A surprise removal forces status to 0xFF, making 0xFF & BIT(2) true and
triggering an unintended kernel stack dump for an asynchronous hardware
event.
---
This looks valid to me.
/P
^ permalink raw reply
* Re: [PATCH net v1] net: skb: fix cross-cache free of KFENCE-allocated skb head
From: Eric Dumazet @ 2026-04-02 8:03 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, Antonius, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jason Xing, Kuniyuki Iwashima, Michal Luczaj,
Mina Almasry, Eric Biggers, Toke Høiland-Jørgensen,
Soheil Hassas Yeganeh, Alexander Duyck, linux-kernel, bpf
In-Reply-To: <ad90b2a9-0f67-4796-94bc-9dbb76a575af@linux.dev>
On Wed, Apr 1, 2026 at 9:15 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
> If we no longer care about the cost of accessing a struct page in the
> free path, which the original commit was trying to avoid, this is
> indeed the simplest fix — kfree() correctly handles objects via
> virt_to_slab.
We only have SLUB in modern kernels, kmem_cache_free() needs to touch it.
Using is_kfence_address() in net/core/skbuff.c is pushing too hard in
my opinion.
^ permalink raw reply
* [PATCH net 0/2] vsock/virtio: fix MSG_PEEK calculation on bytes to copy
From: Luigi Leonardi @ 2026-04-02 8:18 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
`virtio_transport_stream_do_peek`, when calculating the number of bytes to copy,
didn't consider the `offset`, caused by partial reads that happend before.
This might cause out-of-bounds read that lead to an EFAULT.
More details in the commit.
Commit 1 introduces the fix
Commit 2 introduces a test that checks for this bug to avoid future
regressions.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
Luigi Leonardi (2):
vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy
vsock/test: add MSG_PEEK after partial recv test
net/vmw_vsock/virtio_transport_common.c | 5 ++-
tools/testing/vsock/vsock_test.c | 64 +++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+), 3 deletions(-)
---
base-commit: 9147566d801602c9e7fc7f85e989735735bf38ba
change-id: 20260401-fix_peek-6837b83469e3
Best regards,
--
Luigi Leonardi <leonardi@redhat.com>
^ permalink raw reply
* [PATCH net 1/2] vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy
From: Luigi Leonardi @ 2026-04-02 8:18 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
In-Reply-To: <20260402-fix_peek-v1-0-ad274fcef77b@redhat.com>
`virtio_transport_stream_do_peek()` does not account for the skb offset
when computing the number of bytes to copy.
This means that, after a partial recv() that advances the offset, a peek
requesting more bytes than are available in the sk_buff causes
`skb_copy_datagram_iter()` to go past the valid payload, resulting in a -EFAULT.
The dequeue path already handles this correctly.
Apply the same logic to the peek path.
Fixes: 0df7cd3c13e4 ("vsock/virtio/vhost: read data from non-linear skb")
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
net/vmw_vsock/virtio_transport_common.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 8a9fb23c6e853dfea0a24d3787f7d6eb351dd6c6..4b65bfe5d875111f115e0fc4c6727adb66f34830 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -547,9 +547,8 @@ virtio_transport_stream_do_peek(struct vsock_sock *vsk,
skb_queue_walk(&vvs->rx_queue, skb) {
size_t bytes;
- bytes = len - total;
- if (bytes > skb->len)
- bytes = skb->len;
+ bytes = min_t(size_t, len - total,
+ skb->len - VIRTIO_VSOCK_SKB_CB(skb)->offset);
spin_unlock_bh(&vvs->rx_lock);
--
2.53.0
^ permalink raw reply related
* [PATCH net 2/2] vsock/test: add MSG_PEEK after partial recv test
From: Luigi Leonardi @ 2026-04-02 8:18 UTC (permalink / raw)
To: Stefan Hajnoczi, Stefano Garzarella, Michael S. Tsirkin,
Jason Wang, Xuan Zhuo, Eugenio Pérez, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Arseniy Krasnov
Cc: kvm, virtualization, netdev, linux-kernel, Luigi Leonardi
In-Reply-To: <20260402-fix_peek-v1-0-ad274fcef77b@redhat.com>
Add a test that verifies MSG_PEEK works correctly after a partial
recv().
This is to test a bug that was present in the `virtio_transport_stream_do_peek()`
when computing the number of bytes to copy: After a partial read, the
peek function didn't take into consideration the number of bytes that
were already read. So peeking the whole buffer would cause a out-of-bounds read,
that resulted in a -EFAULT.
This test does exactly this: do a partial recv on a buffer, then try to
peek the whole buffer content.
Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
---
tools/testing/vsock/vsock_test.c | 64 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
index 5bd20ccd9335caafe68e8b7a5d02a4deb3d2deec..308f9f8f30d22bec5aaa282356e400d8438fe321 100644
--- a/tools/testing/vsock/vsock_test.c
+++ b/tools/testing/vsock/vsock_test.c
@@ -346,6 +346,65 @@ static void test_stream_msg_peek_server(const struct test_opts *opts)
return test_msg_peek_server(opts, false);
}
+#define PEEK_AFTER_RECV_LEN 100
+
+static void test_stream_peek_after_recv_client(const struct test_opts *opts)
+{
+ unsigned char buf[PEEK_AFTER_RECV_LEN];
+ int fd;
+ int i;
+
+ fd = vsock_stream_connect(opts->peer_cid, opts->peer_port);
+ if (fd < 0) {
+ perror("connect");
+ exit(EXIT_FAILURE);
+ }
+
+ for (i = 0; i < sizeof(buf); i++)
+ buf[i] = (unsigned char)i;
+
+ control_expectln("SRVREADY");
+
+ send_buf(fd, buf, sizeof(buf), 0, sizeof(buf));
+
+ close(fd);
+}
+
+static void test_stream_peek_after_recv_server(const struct test_opts *opts)
+{
+ unsigned char buf[PEEK_AFTER_RECV_LEN];
+ int half = PEEK_AFTER_RECV_LEN / 2;
+ ssize_t ret;
+ int fd;
+
+ fd = vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL);
+ if (fd < 0) {
+ perror("accept");
+ exit(EXIT_FAILURE);
+ }
+
+ control_writeln("SRVREADY");
+
+ /* Partial recv to advance offset within the skb */
+ recv_buf(fd, buf, half, 0, half);
+
+ /* Try to peek more than what remains: should return only 'half'
+ * bytes. Note: we can't use recv_buf() because it loops until
+ * all requested bytes are returned.
+ */
+ ret = recv(fd, buf, sizeof(buf), MSG_PEEK);
+ if (ret < 0) {
+ perror("recv");
+ exit(EXIT_FAILURE);
+ } else if (ret != half) {
+ fprintf(stderr, "MSG_PEEK after partial recv returned %d (expected %d)\n",
+ ret, half);
+ exit(EXIT_FAILURE);
+ }
+
+ close(fd);
+}
+
#define SOCK_BUF_SIZE (2 * 1024 * 1024)
#define SOCK_BUF_SIZE_SMALL (64 * 1024)
#define MAX_MSG_PAGES 4
@@ -2520,6 +2579,11 @@ static struct test_case test_cases[] = {
.run_client = test_stream_tx_credit_bounds_client,
.run_server = test_stream_tx_credit_bounds_server,
},
+ {
+ .name = "SOCK_STREAM MSG_PEEK after partial recv",
+ .run_client = test_stream_peek_after_recv_client,
+ .run_server = test_stream_peek_after_recv_server,
+ },
{},
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v5 4/6] net: bcmgenet: add XDP_TX support
From: Nicolai Buchwitz @ 2026-04-02 8:19 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, justin.chen, horms, opendmb, florian.fainelli,
bcm-kernel-feedback-list, andrew+netdev, davem, edumazet, pabeni,
ast, daniel, hawk, john.fastabend, sdf, linux-kernel, bpf
In-Reply-To: <20260402032722.905829-1-kuba@kernel.org>
On 2.4.2026 05:27, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> net: bcmgenet: add XDP_TX support
>
> This commit implements XDP_TX using ring 16, which is dedicated to XDP
> TX
> for isolation from SKB TX queues. It also changes the page_pool DMA
> direction to bidirectional to allow TX reuse of the existing DMA
> mapping.
>
>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> index b45ba2c2857e..687c3b12d44f 100644
>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> [ ... ]
>> @@ -2299,11 +2328,96 @@ static struct sk_buff
>> *bcmgenet_xdp_build_skb(struct bcmgenet_rx_ring *ring,
>> return skb;
>> }
>>
>> +static bool bcmgenet_xdp_xmit_frame(struct bcmgenet_priv *priv,
>> + struct xdp_frame *xdpf, bool dma_map)
>> +{
> [ ... ]
>> + } else {
>> + struct page *page = virt_to_page(xdpf->data);
>> +
>> + /* For local XDP_TX the caller already prepended the TSB
>> + * into xdpf->data/len, so dma_len == xdpf->len.
>> + */
>> + dma_len = xdpf->len;
>> + mapping = page_pool_get_dma_addr(page) +
>> + sizeof(*xdpf) + xdpf->headroom;
>
> When the RX page pool is created in bcmgenet_rx_ring_create_pool(), it
> is
> initialized with .offset = GENET_XDP_HEADROOM. Does the DMA address
> calculation here need to include this GENET_XDP_HEADROOM offset?
> Without it,
> it appears the hardware might be given a DMA address that is 256 bytes
> before the actual packet data, transmitting uninitialized memory.
The DMA address calculation is correct. page_pool_get_dma_addr()
returns the base DMA address of the page, not offset by the pool's
.offset parameter. sizeof(*xdpf) + xdpf->headroom correctly offsets
to xdpf->data where the TSB starts.
>
> [ ... ]
>> @@ -2311,14 +2425,42 @@ static unsigned int bcmgenet_run_xdp(struct
>> bcmgenet_rx_ring *ring,
>> switch (act) {
>> case XDP_PASS:
>> return XDP_PASS;
>> + case XDP_TX:
>> + /* Prepend a zeroed TSB (Transmit Status Block). The GENET
>> + * MAC has TBUF_64B_EN set globally, so hardware expects every
>> + * TX buffer to begin with a 64-byte struct status_64. Back
>> + * up xdp->data into the RSB area (which is no longer needed
>> + * after the BPF program ran) and zero it.
>> + */
>> + if (xdp->data - xdp->data_hard_start <
>> + sizeof(struct status_64)) {
>> + page_pool_put_full_page(ring->page_pool, rx_page,
>> + true);
>> + return XDP_DROP;
>> + }
>> + xdp->data -= sizeof(struct status_64);
>> + xdp->data_meta -= sizeof(struct status_64);
>> + memset(xdp->data, 0, sizeof(struct status_64));
>> +
>> + xdpf = xdp_convert_buff_to_frame(xdp);
>
> Does this headroom check account for the additional sizeof(struct
> xdp_frame)
> required by xdp_convert_buff_to_frame()?
The TSB headroom check doesn't account for sizeof(struct xdp_frame), but
xdp_update_frame_from_buff() has its own check that returns -ENOSPC if
headroom - metasize < sizeof(*xdp_frame). We handle the NULL return by
dropping the frame. I'll tighten the check to include sizeof(struct
xdp_frame) to fail early.
>
> If metadata is present, xdp->data_meta could potentially underflow
> xdp->data_hard_start. If the remaining headroom minus metasize becomes
> negative in xdp_convert_buff_to_frame(), could it undergo integer
> promotion
> to a large unsigned value and bypass the internal safety check? This
> might
> cause the struct xdp_frame to overwrite the newly zeroed status_64
> block.
xdp_update_frame_from_buff() handles this - it clamps metasize to >= 0
and checks (headroom - metasize) < sizeof(*xdp_frame), returning NULL on
insufficient space.
>
> [ ... ]
>> @@ -2556,9 +2698,15 @@ static int bcmgenet_rx_poll(struct napi_struct
>> *napi, int budget)
>> {
>> struct bcmgenet_rx_ring *ring = container_of(napi,
>> struct bcmgenet_rx_ring, napi);
>> + struct bcmgenet_priv *priv = ring->priv;
>> struct dim_sample dim_sample = {};
>> unsigned int work_done;
>>
>> + /* Reclaim completed XDP TX frames (ring 16 has no interrupt) */
>> + if (priv->xdp_prog)
>> + bcmgenet_tx_reclaim(priv->dev,
>> + &priv->xdp_tx_ring, false);
>> +
>
> What happens to in-flight frames if the XDP program is detached at
> runtime
> and priv->xdp_prog becomes NULL? Will this permanently lose track of
> the
> page pool buffers and DMA mappings since the NAPI poll stops reclaiming
> them?
Good catch. The reclaim in rx_poll is gated on priv->xdp_prog, so
in-flight frames on the TX ring would never be reclaimed after detach.
I'll change the condition to check for pending frames on the ring
instead.
>
> Additionally, if the interface is the target of an XDP_REDIRECT from
> another
> device, a local XDP program is not required and priv->xdp_prog could be
> NULL. Does this mean the transmitted frames for redirected traffic will
> never be reclaimed, eventually filling the TX ring?
The redirect-without-local-prog case can't happen since
xdp_features_set_redirect_target is tied to program attachment.
But the detach race is real - will fix in v6.
Thanks
Nicolai
^ permalink raw reply
* Re: [PATCH net-next v36 3/8] eea: probe the netdevice and create adminq
From: Paolo Abeni @ 2026-04-02 8:19 UTC (permalink / raw)
To: Xuan Zhuo, netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Wen Gu, Philo Lu, Vadim Fedorenko, Dong Yibo, Heiner Kallweit,
Dust Li
In-Reply-To: <20260329132222.130912-4-xuanzhuo@linux.alibaba.com>
On 3/29/26 3:22 PM, Xuan Zhuo wrote:
> +static int eea_adminq_submit(struct eea_net *enet, u16 cmd,
> + dma_addr_t req_addr, dma_addr_t res_addr,
> + u32 req_size, u32 res_size)
> +{
> + struct eea_aq_cdesc *cdesc;
> + struct eea_aq_desc *desc;
> + int ret;
> +
> + desc = ering_aq_alloc_desc(enet->adminq.ring);
> +
> + desc->classid = cmd >> 8;
Here there are a couple of example where a reply to the AI reviews would
have been very useful.
Sashiko says:
---
Is it possible for ering_aq_alloc_desc() to return NULL if the admin
ring is full?
If so, will this cause a NULL pointer dereference when accessing
desc->classid?
---
AFAICS this is allucinating, as ering_aq_alloc_desc() never returns NULL.
> + desc->flags = cpu_to_le16(enet->adminq.phase);
> +
> + ering_sq_commit_desc(enet->adminq.ring);
> +
> + ering_kick(enet->adminq.ring);
> +
> + ++enet->adminq.num;
> +
> + if ((enet->adminq.num % enet->adminq.ring->num) == 0)
> + enet->adminq.phase ^= EEA_RING_DESC_F_AQ_PHASE;
Sashiko says:
---
Does this code require a lock to serialize access?
Concurrently modifying enet->adminq.num and enet->adminq.phase from
multiple threads could lead to data races and ring corruption if
administrative commands are triggered simultaneously.
---
Again, AFAICS this is allucinating, as all the calls are under the rtnl
lock. This check took a lot of time to me, because I had to go up in the
call stack a few hops looking for any lock. A reply clarifying the
locking would have been very helpful.
> + ret = le32_to_cpu(cdesc->status);
> +
> + ering_cq_ack_desc(enet->adminq.ring, 1);
> +
> + if (ret)
> + netdev_err(enet->netdev,
> + "adminq exec failed. cmd: %d ret %d\n", cmd, ret);
> +
> + return ret;
> +}
Sashiko says:
---
Are device statuses returned as positive integers?
If this returns a positive value during eea_net_probe(), it will bubble
up to the PCI subsystem. Since the driver model treats a return value >
0 as a successful probe, the PCI core might believe the device is
successfully bound even though the error path in eea_net_probe() freed
the resources.
Could this lead to a use-after-free during device removal?
---
This looks real to me, and was already reported in the previous
iteration. The question is: why do you consider this invalid? Or did you
miss the remark? A reply to this comment would have been helpful.
The bottom line is please go over the comments reported by sashiko, and
either take care of them (dropping a line in the changelog about the
update) or reply on the ML explaining why the comment is not valid, with
a single reply per patch touching all the relevant comments.
I understand it takes a significant effort, but if you leave this
entirely on us, the only choice we have is to unconditionally set to
change request any patches with AI remarks due to the volume of comments
and capacity limits.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net-next v5 3/6] net: bcmgenet: add basic XDP support (PASS/DROP)
From: Nicolai Buchwitz @ 2026-04-02 8:25 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, Justin Chen, Simon Horman, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, linux-kernel, bpf
In-Reply-To: <20260401202702.0b0b6dec@kernel.org>
On 2.4.2026 05:27, Jakub Kicinski wrote:
> On Sun, 29 Mar 2026 00:05:06 +0100 Nicolai Buchwitz wrote:
>> @@ -2403,26 +2456,52 @@ static unsigned int bcmgenet_desc_rx(struct
>> bcmgenet_rx_ring *ring,
>> goto next;
>> } /* error packet */
>>
>> - /* Build SKB from the page - data starts at hard_start,
>> - * frame begins after RSB(64) + pad(2) = 66 bytes.
>> - */
>> - skb = napi_build_skb(hard_start, PAGE_SIZE - GENET_XDP_HEADROOM);
>> - if (unlikely(!skb)) {
>> - BCMGENET_STATS64_INC(stats, dropped);
>> - page_pool_put_full_page(ring->page_pool, rx_page,
>> - true);
>> - goto next;
>> - }
>> -
>> - skb_mark_for_recycle(skb);
>> + /* XDP: frame data starts after RSB + pad */
>> + if (xdp_prog) {
>> + struct xdp_buff xdp;
>> + unsigned int xdp_act;
>> + int pkt_len;
>> +
>> + pkt_len = len - GENET_RSB_PAD;
>> + if (priv->crc_fwd_en)
>> + pkt_len -= ETH_FCS_LEN;
>> +
>> + xdp_init_buff(&xdp, PAGE_SIZE, &ring->xdp_rxq);
>> + xdp_prepare_buff(&xdp, page_address(rx_page),
>> + GENET_RX_HEADROOM, pkt_len, true);
>> +
>> + xdp_act = bcmgenet_run_xdp(ring, xdp_prog, &xdp,
>> + rx_page);
>> + if (xdp_act != XDP_PASS)
>> + goto next;
>> +
>> + /* XDP_PASS: build SKB from (possibly modified) xdp */
>> + skb = bcmgenet_xdp_build_skb(ring, &xdp, rx_page);
>> + if (unlikely(!skb)) {
>> + BCMGENET_STATS64_INC(stats, dropped);
>> + page_pool_put_full_page(ring->page_pool,
>> + rx_page, true);
>> + goto next;
>> + }
>> + } else {
>> + /* Build SKB from the page - data starts at
>> + * hard_start, frame begins after RSB(64) + pad(2).
>> + */
>> + skb = napi_build_skb(hard_start,
>> + PAGE_SIZE - GENET_XDP_HEADROOM);
>> + if (unlikely(!skb)) {
>> + BCMGENET_STATS64_INC(stats, dropped);
>> + page_pool_put_full_page(ring->page_pool,
>> + rx_page, true);
>> + goto next;
>> + }
>
> The large branches here are quite unusual, normally drivers fully
> prepare the xdp_buff and if there's no xdp prog attached act as
> if there was one and it returned XDP_PASS. Saves LoC and therefore
> bugs.
Agreed, will refactor to always prepare xdp_buff and use
bcmgenet_xdp_build_skb for both paths in v6.
>
>>
>> - /* Reserve the RSB + pad, then set the data length */
>> - skb_reserve(skb, GENET_RSB_PAD);
>> - __skb_put(skb, len - GENET_RSB_PAD);
>> + skb_mark_for_recycle(skb);
>> + skb_reserve(skb, GENET_RSB_PAD);
>> + __skb_put(skb, len - GENET_RSB_PAD);
>>
>> - if (priv->crc_fwd_en) {
>> - skb_trim(skb, skb->len - ETH_FCS_LEN);
>> - len -= ETH_FCS_LEN;
>> + if (priv->crc_fwd_en)
>> + skb_trim(skb, skb->len - ETH_FCS_LEN);
>> }
>>
>> /* Set up checksum offload */
>
> AI points out that :
>
> The status_64 structure is located at the start of the page
> before the frame data. Since this resides inside the XDP headroom, if
> an XDP
> program expands the header backwards (e.g., via bpf_xdp_adjust_head()
> or
> metadata via bpf_xdp_adjust_meta()), could it physically overwrite
> status->rx_csum?
>
> Since the driver reads status->rx_csum after executing the XDP
> program, it
> could risk reading garbage data if the headroom was used. Should the
> driver
> skip setting CHECKSUM_COMPLETE when an XDP program is loaded?
Makes sense, status->rx_csum is read after XDP runs and an
adjust_head could overwrite the RSB. I'll save rx_csum before
running the XDP program rather than skipping CHECKSUM_COMPLETE
entirely, so XDP_PASS packets that weren't modified still benefit
from HW checksum offload.
>
>> @@ -3745,6 +3824,39 @@ static int bcmgenet_change_carrier(struct
>> net_device *dev, bool new_carrier)
>> return 0;
>> }
>>
>> +static int bcmgenet_xdp_setup(struct net_device *dev,
>> + struct netdev_bpf *xdp)
>> +{
>> + struct bcmgenet_priv *priv = netdev_priv(dev);
>> + struct bpf_prog *old_prog;
>> + struct bpf_prog *prog = xdp->prog;
>> +
>> + if (prog && dev->mtu > PAGE_SIZE - GENET_RX_HEADROOM -
>> + SKB_DATA_ALIGN(sizeof(struct skb_shared_info))) {
>> + NL_SET_ERR_MSG_MOD(xdp->extack,
>> + "MTU too large for single-page XDP buffer");
>> + return -EOPNOTSUPP;
>> + }
>> +
>> + old_prog = xchg(&priv->xdp_prog, prog);
>> + if (old_prog) {
>> + synchronize_net();
>
> Why? BPF prog gets freed after a RCU grace period I think?
You're right, bpf_prog_put handles this via call_rcu. Will remove
the synchronize_net().
>
>> + bpf_prog_put(old_prog);
Thanks
Nicolai
^ permalink raw reply
* Re: [PATCH net-next v5 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: Birger Koblitz @ 2026-04-02 8:27 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-usb, netdev, linux-kernel, Chih Kai Hsu
In-Reply-To: <20260401203711.7e56ff95@kernel.org>
On 4/2/26 05:37, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 17:55:52 +0200 Birger Koblitz wrote:
>> Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
>> chip in the RTL815x family of chips.
>>
>> The RTL8157 uses a different frame descriptor format, and different
>> SRAM/ADV access methods, plus offers 5GBit/s Ethernet, so support for these
>> features is added in addition to chip initialization and configuration.
>
> This version does not seem to apply to net-next.
> Please make sure you base it on net-next not linux-next.
Sorry about that, I was not aware of the parallel changes. I have rebased
to net-next and will send a v6.
^ permalink raw reply
* [PATCH net-next v6 0/2] r8152: Add support for the RTL8157 5Gbit USB Ethernet chip
From: Birger Koblitz @ 2026-04-02 8:28 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu, Birger Koblitz
Add support for the RTL8157, which is a 5GBit USB-Ethernet adapter
chip in the RTL815x family of chips.
The RTL8157 uses a different frame descriptor format, and different
SRAM/ADV access methods, plus offers 5GBit/s Ethernet, so support for these
features is added in addition to chip initialization and configuration.
The module was tested with an OEM RTL8157 USB adapter:
[25758.328238] usb 4-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[25758.345565] usb 4-1: New USB device found, idVendor=0bda, idProduct=8157, bcdDevice=30.00
[25758.345585] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=7
[25758.345593] usb 4-1: Product: USB 10/100/1G/2.5G/5G LAN
[25758.345599] usb 4-1: Manufacturer: Realtek
[25758.345605] usb 4-1: SerialNumber: 000300E04C68xxxx
[25758.534241] r8152-cfgselector 4-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[25758.603511] r8152 4-1:1.0: skip request firmware
[25758.653351] r8152 4-1:1.0 eth0: v1.12.13
[25758.689271] r8152 4-1:1.0 enx00e04c68xxxx: renamed from eth0
[25763.271682] r8152 4-1:1.0 enx00e04c68xxxx: carrier on
The RTL8157 adapter was tested against an AQC107 PCIe-card supporting
10GBit/s and an RTL8126 5Gbit PCIe-card supporting 5GBit/s for
performance, link speed and EEE negotiation. Using USB3.2 Gen 1 with
the RTL8157 USB adapter and running iperf3 against the AQC107 PCIe
card resulted in 3.47 Gbits/sec, whereas using USB3.2 Gen2 resulted
in 4.70 Gbits/sec, speeds against the RTL8126-card were the same.
As the code integrates the RTL8157-specific code with existing RTL8156 code
in order to improve code maintainability (instead of adding RTL8157-specific
functions duplicaing most of the RTL8156 code), regression tests were done
with an Edimax EU-4307 V1.0 USB-Ethernet adapter with RTL8156.
The code is based on the out-of-tree r8152 driver published by Realtek under
the GPL.
This patch is on top of linux-next as the code re-uses the 2.5 Gbit EEE
recently added in r8152.c.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
Changes in v6:
- Rebased to net-next
- Fixed typos: ocp_10bt -> ocp_10gbt
- Link to v5: https://lore.kernel.org/r/20260331-rtl8157_next-v5-0-deb3095f8380@birger-koblitz.de
Changes in v5:
- Filter advertising in rtl8152_set_speed() to prevent incorrect speeds
- Prevent double USB transfers in rtl8152_get_link_ksettings()
- Make sure OCP_EEE_ADV2 and OCP_EEE_LPABLE2 are read if a device
supports 5GBit but not 2.5Gbit
- Fix rtl8157_runtime_enable() to follow the behavior of
rtl8156_runtime_enable()
- Prevent call to r8153_u2p3en in rtl8156_up() for RTL8157
- Fix rtl8157_unload() to disable interrupt mitigation
- Link to v4: https://lore.kernel.org/r/20260324-rtl8157_next-v4-0-034312b12de5@birger-koblitz.de
Changes in v4:
- Fix return type of ocp_adv_read()
- In r8152_tx_csum() use tx_desc
- Use TCPHO_MAX_2 for RTL8157 in rtl8152_features_check()
- Include RTL_VER_12 in RTL8156B chip versions in rtl8156_init()
- Remove inline keyword from rx_agg_align and tx_agg_align
- Link to v3: https://lore.kernel.org/r/20260320-rtl8157_next-v3-0-1aefeca7fda7@birger-koblitz.de
Changes in v3:
- Apply reverse Christmas tree order for declarations
- Use poll_timeout_us for register polling
- In rtl8156_enable(), fix version comparison: tp->version >= RTL_VER_16
- Correct error handling of r8153_phy_status in r8157_hw_phy_cfg()
- Fix use of ocp_word_clr_bits for PLA_MCU_SPDWN_EN register
- Link to v2: https://lore.kernel.org/r/20260317-rtl8157_next-v2-0-10ea1fa488d1@birger-koblitz.de
Changes in v2:
- Fixed missing initialization of ret value in wait_cmd_ready()
- Combine all parts with RTL8157-specific code to avoid undefined functions
- Link to v1: https://lore.kernel.org/r/20260314-rtl8157_next-v1-0-9ba77b428afd@birger-koblitz.de
---
Birger Koblitz (2):
r8152: Add support for 5Gbit Link Speeds and EEE
r8152: Add support for the RTL8157 hardware
drivers/net/usb/r8152.c | 1029 +++++++++++++++++++++++++++++++++++++----------
1 file changed, 827 insertions(+), 202 deletions(-)
---
base-commit: cee10a01e286e88e0949979e91231270ca9fdb8e
change-id: 20260314-rtl8157_next-ae18683eb4fa
Best regards,
--
Birger Koblitz <mail@birger-koblitz.de>
^ permalink raw reply
* [PATCH net-next v6 1/2] r8152: Add support for 5Gbit Link Speeds and EEE
From: Birger Koblitz @ 2026-04-02 8:28 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-usb, netdev, linux-kernel, Chih Kai Hsu, Birger Koblitz
In-Reply-To: <20260402-rtl8157_next-v6-0-a9b77c0931ef@birger-koblitz.de>
The RTL8157 supports 5GBit Link speeds. Add support for this speed
in the setup and setting/getting through ethtool. Also add 5GBit EEE.
Add functionality for setup and ethtool get/set methods.
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
---
drivers/net/usb/r8152.c | 100 +++++++++++++++++++++++++++++++++++++++---------
1 file changed, 82 insertions(+), 18 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 8747c55e0a48433e2300c151af2ac36e839a3929..15527f3cb5478df3450d5e53b5a277fca1460e44 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -604,6 +604,7 @@ enum spd_duplex {
FORCE_100M_FULL,
FORCE_1000M_FULL,
NWAY_2500M_FULL,
+ NWAY_5000M_FULL,
};
/* OCP_ALDPS_CONFIG */
@@ -725,6 +726,7 @@ enum spd_duplex {
#define BP4_SUPER_ONLY 0x1578 /* RTL_VER_04 only */
enum rtl_register_content {
+ _5000bps = BIT(12),
_2500bps = BIT(10),
_1250bps = BIT(9),
_500bps = BIT(8),
@@ -738,6 +740,7 @@ enum rtl_register_content {
};
#define is_speed_2500(_speed) (((_speed) & (_2500bps | LINK_STATUS)) == (_2500bps | LINK_STATUS))
+#define is_speed_5000(_speed) (((_speed) & (_5000bps | LINK_STATUS)) == (_5000bps | LINK_STATUS))
#define is_flow_control(_speed) (((_speed) & (_tx_flow | _rx_flow)) == (_tx_flow | _rx_flow))
#define RTL8152_MAX_TX 4
@@ -944,6 +947,7 @@ struct r8152 {
unsigned int pipe_in, pipe_out, pipe_intr, pipe_ctrl_in, pipe_ctrl_out;
u32 support_2500full:1;
+ u32 support_5000full:1;
u32 lenovo_macpassthru:1;
u32 dell_tb_rx_agg_bug:1;
u16 ocp_base;
@@ -1194,6 +1198,7 @@ enum tx_csum_stat {
#define RTL_ADVERTISED_1000_HALF BIT(4)
#define RTL_ADVERTISED_1000_FULL BIT(5)
#define RTL_ADVERTISED_2500_FULL BIT(6)
+#define RTL_ADVERTISED_5000_FULL BIT(7)
/* Maximum number of multicast addresses to filter (vs. Rx-all-multicast).
* The RTL chips use a 64 element hash table based on the Ethernet CRC.
@@ -5398,12 +5403,23 @@ static void r8153_eee_en(struct r8152 *tp, bool enable)
static void r8156_eee_en(struct r8152 *tp, bool enable)
{
+ u16 config;
+
r8153_eee_en(tp, enable);
+ config = ocp_reg_read(tp, OCP_EEE_ADV2);
+
if (enable && (tp->eee_adv2 & MDIO_EEE_2_5GT))
- ocp_reg_set_bits(tp, OCP_EEE_ADV2, MDIO_EEE_2_5GT);
+ config |= MDIO_EEE_2_5GT;
else
- ocp_reg_clr_bits(tp, OCP_EEE_ADV2, MDIO_EEE_2_5GT);
+ config &= ~MDIO_EEE_2_5GT;
+
+ if (enable && (tp->eee_adv2 & MDIO_EEE_5GT))
+ config |= MDIO_EEE_5GT;
+ else
+ config &= ~MDIO_EEE_5GT;
+
+ ocp_reg_write(tp, OCP_EEE_ADV2, config);
}
static void rtl_eee_enable(struct r8152 *tp, bool enable)
@@ -6167,9 +6183,13 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
if (tp->support_2500full)
support |= RTL_ADVERTISED_2500_FULL;
+
+ if (tp->support_5000full)
+ support |= RTL_ADVERTISED_5000_FULL;
}
- if (!(advertising & support))
+ advertising &= support;
+ if (!advertising)
return -EINVAL;
orig = r8152_mdio_read(tp, MII_ADVERTISE);
@@ -6212,15 +6232,20 @@ static int rtl8152_set_speed(struct r8152 *tp, u8 autoneg, u32 speed, u8 duplex,
r8152_mdio_write(tp, MII_CTRL1000, new1);
}
- if (tp->support_2500full) {
+ if (tp->support_2500full || tp->support_5000full) {
orig = ocp_reg_read(tp, OCP_10GBT_CTRL);
- new1 = orig & ~MDIO_AN_10GBT_CTRL_ADV2_5G;
+ new1 = orig & ~(MDIO_AN_10GBT_CTRL_ADV2_5G | MDIO_AN_10GBT_CTRL_ADV5G);
if (advertising & RTL_ADVERTISED_2500_FULL) {
new1 |= MDIO_AN_10GBT_CTRL_ADV2_5G;
tp->ups_info.speed_duplex = NWAY_2500M_FULL;
}
+ if (advertising & RTL_ADVERTISED_5000_FULL) {
+ new1 |= MDIO_AN_10GBT_CTRL_ADV5G;
+ tp->ups_info.speed_duplex = NWAY_5000M_FULL;
+ }
+
if (orig != new1)
ocp_reg_write(tp, OCP_10GBT_CTRL, new1);
}
@@ -8248,17 +8273,38 @@ int rtl8152_get_link_ksettings(struct net_device *netdev,
linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
cmd->link_modes.supported, tp->support_2500full);
- if (tp->support_2500full) {
- linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
- cmd->link_modes.advertising,
- ocp_reg_read(tp, OCP_10GBT_CTRL) & MDIO_AN_10GBT_CTRL_ADV2_5G);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ cmd->link_modes.supported, tp->support_5000full);
+
+ if (tp->support_2500full || tp->support_5000full) {
+ u16 ocp_10gbt_ctrl = ocp_reg_read(tp, OCP_10GBT_CTRL);
+ u16 ocp_10gbt_stat = ocp_reg_read(tp, OCP_10GBT_STAT);
+
+ if (tp->support_2500full) {
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ cmd->link_modes.advertising,
+ ocp_10gbt_ctrl & MDIO_AN_10GBT_CTRL_ADV2_5G);
+
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
+ cmd->link_modes.lp_advertising,
+ ocp_10gbt_stat & MDIO_AN_10GBT_STAT_LP2_5G);
+
+ if (is_speed_2500(rtl8152_get_speed(tp)))
+ cmd->base.speed = SPEED_2500;
+ }
+
+ if (tp->support_5000full) {
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ cmd->link_modes.advertising,
+ ocp_10gbt_ctrl & MDIO_AN_10GBT_CTRL_ADV5G);
- linkmode_mod_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT,
- cmd->link_modes.lp_advertising,
- ocp_reg_read(tp, OCP_10GBT_STAT) & MDIO_AN_10GBT_STAT_LP2_5G);
+ linkmode_mod_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ cmd->link_modes.lp_advertising,
+ ocp_10gbt_stat & MDIO_AN_10GBT_STAT_LP5G);
- if (is_speed_2500(rtl8152_get_speed(tp)))
- cmd->base.speed = SPEED_2500;
+ if (is_speed_5000(rtl8152_get_speed(tp)))
+ cmd->base.speed = SPEED_5000;
+ }
}
mutex_unlock(&tp->control);
@@ -8308,6 +8354,10 @@ static int rtl8152_set_link_ksettings(struct net_device *dev,
cmd->link_modes.advertising))
advertising |= RTL_ADVERTISED_2500_FULL;
+ if (test_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT,
+ cmd->link_modes.advertising))
+ advertising |= RTL_ADVERTISED_5000_FULL;
+
mutex_lock(&tp->control);
ret = rtl8152_set_speed(tp, cmd->base.autoneg, cmd->base.speed,
@@ -8425,7 +8475,7 @@ static int r8152_set_eee(struct r8152 *tp, struct ethtool_keee *eee)
tp->eee_en = eee->eee_enabled;
tp->eee_adv = val;
- if (tp->support_2500full) {
+ if (tp->support_2500full || tp->support_5000full) {
val = linkmode_to_mii_eee_cap2_t(eee->advertised);
tp->eee_adv2 = val;
}
@@ -8449,19 +8499,28 @@ static int r8153_get_eee(struct r8152 *tp, struct ethtool_keee *eee)
val = ocp_reg_read(tp, OCP_EEE_LPABLE);
mii_eee_cap1_mod_linkmode_t(eee->lp_advertised, val);
- if (tp->support_2500full) {
- linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, eee->supported);
-
+ if (tp->support_2500full || tp->support_5000full) {
val = ocp_reg_read(tp, OCP_EEE_ADV2);
mii_eee_cap2_mod_linkmode_adv_t(eee->advertised, val);
val = ocp_reg_read(tp, OCP_EEE_LPABLE2);
mii_eee_cap2_mod_linkmode_adv_t(eee->lp_advertised, val);
+ }
+
+ if (tp->support_2500full) {
+ linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, eee->supported);
if (speed & _2500bps)
linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, common);
}
+ if (tp->support_5000full) {
+ linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, eee->supported);
+
+ if (speed & _5000bps)
+ linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, common);
+ }
+
eee->eee_enabled = tp->eee_en;
if (speed & _1000bps)
@@ -9402,6 +9461,11 @@ static int rtl8152_probe_once(struct usb_interface *intf,
} else {
tp->speed = SPEED_1000;
}
+ if (tp->support_5000full &&
+ tp->udev->speed >= USB_SPEED_SUPER) {
+ tp->speed = SPEED_5000;
+ tp->advertising |= RTL_ADVERTISED_5000_FULL;
+ }
tp->advertising |= RTL_ADVERTISED_1000_FULL;
}
tp->duplex = DUPLEX_FULL;
--
2.47.3
^ 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