* [PATCH net V2 2/2] net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation
From: Tariq Toukan @ 2026-07-17 7:51 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
netdev, Paolo Abeni
Cc: Alexei Lazar, Carolina Jubran, Leon Romanovsky, linux-kernel,
linux-rdma, Mark Bloch, Pavan Chebbi, Saeed Mahameed,
Tariq Toukan, Gal Pressman
In-Reply-To: <20260717075125.1244877-1-tariqt@nvidia.com>
From: Alexei Lazar <alazar@nvidia.com>
Credit Based (CB) TSA is not supported by the mlx5 driver, so reject
any configurations that specify it.
Fixes: 08fb1dacdd76 ("net/mlx5e: Support DCBNL IEEE ETS")
Signed-off-by: Alexei Lazar <alazar@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
index 762f0a46c120..00e706e1ede1 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
@@ -324,6 +324,14 @@ static int mlx5e_dbcnl_validate_ets(struct net_device *netdev,
}
}
+ for (i = 0; i < IEEE_8021QAZ_MAX_TCS; i++) {
+ if (ets->tc_tsa[i] == IEEE_8021QAZ_TSA_CB_SHAPER) {
+ netdev_err(netdev,
+ "Failed to validate ETS: CB Shaper is not supported\n");
+ return -EOPNOTSUPP;
+ }
+ }
+
/* Validate Bandwidth Sum */
for (i = 0; i < IEEE_8021QAZ_MAX_TCS; i++) {
if (ets->tc_tsa[i] == IEEE_8021QAZ_TSA_ETS) {
--
2.44.0
^ permalink raw reply related
* [PATCH net V2 1/2] net/mlx5e: Report zero bandwidth for non-ETS traffic classes
From: Tariq Toukan @ 2026-07-17 7:51 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
netdev, Paolo Abeni
Cc: Alexei Lazar, Carolina Jubran, Leon Romanovsky, linux-kernel,
linux-rdma, Mark Bloch, Pavan Chebbi, Saeed Mahameed,
Tariq Toukan, Gal Pressman
In-Reply-To: <20260717075125.1244877-1-tariqt@nvidia.com>
From: Alexei Lazar <alazar@nvidia.com>
The IEEE 802.1Qaz standard defines that bandwidth allocation percentages
only apply to Enhanced Transmission Selection (ETS) traffic classes.
For STRICT and VENDOR transmission selection algorithms, bandwidth
percentage values are not applicable.
Currently for non-ETS 100 bandwidth is being reported for all traffic
classes in the get operation due to hardware limitation, regardless of
their TSA type.
Fix this by reporting 0 for non-ETS traffic classes.
Fixes: 820c2c5e773d ("net/mlx5e: Read ETS settings directly from firmware")
Signed-off-by: Alexei Lazar <alazar@nvidia.com>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
index 4b86df6d5b9e..762f0a46c120 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
@@ -173,6 +173,13 @@ static int mlx5e_dcbnl_ieee_getets(struct net_device *netdev,
}
memcpy(ets->tc_tsa, priv->dcbx.tc_tsa, sizeof(ets->tc_tsa));
+ /* Report 0 for non ETS TSA */
+ for (i = 0; i < ets->ets_cap; i++) {
+ if (ets->tc_tx_bw[i] == MLX5E_MAX_BW_ALLOC &&
+ priv->dcbx.tc_tsa[i] != IEEE_8021QAZ_TSA_ETS)
+ ets->tc_tx_bw[i] = 0;
+ }
+
return err;
}
--
2.44.0
^ permalink raw reply related
* [PATCH net V2 0/2] net/mlx5e: Report zero bandwidth for non-ETS traffic
From: Tariq Toukan @ 2026-07-17 7:51 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
netdev, Paolo Abeni
Cc: Alexei Lazar, Carolina Jubran, Leon Romanovsky, linux-kernel,
linux-rdma, Mark Bloch, Pavan Chebbi, Saeed Mahameed,
Tariq Toukan, Gal Pressman
Hi,
The IEEE 802.1Qaz standard restricts bandwidth allocation percentages
to Enhanced Transmission Selection (ETS) traffic classes; STRICT,
VENDOR, and CB Shaper TSA types carry no bandwidth semantics. Two
problems exist in the mlx5e DCBNL ETS implementation: the get path
reports 100% bandwidth for all TCs regardless of TSA type due to a
hardware limitation, introduced by commit 820c2c5e773d ("net/mlx5e:
Read ETS settings directly from firmware"), and the set path does
not reject the unsupported CB Shaper TSA, introduced by commit
08fb1dacdd76 ("net/mlx5e: Support DCBNL IEEE ETS").
This series by Alexei Lazar fixes the get path to report zero
bandwidth for non-ETS traffic classes, and rejects CB Shaper TSA
configurations that the driver does not support.
Regards,
Tariq
V2:
- Dropped patch 2 "net/mlx5e: Validate bandwidth for non-ETS
traffic classes" (Jakub). We'll submit a more generic version of it.
V1:
https://lore.kernel.org/all/20260622112925.624795-1-tariqt@nvidia.com/
Alexei Lazar (2):
net/mlx5e: Report zero bandwidth for non-ETS traffic classes
net/mlx5e: Reject unsupported CB Shaper TSA in ETS validation
.../net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
base-commit: 3f1f755366687d051174739fb99f7d560202f60b
--
2.44.0
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] net: dsa: mv88e6xxx: various hwstamp fixes
From: Luke Howard @ 2026-07-17 7:47 UTC (permalink / raw)
To: Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Vivien Didelot, Gregory CLEMENT, Andrew Lunn,
Richard Cochran
Cc: Cedric Jehasse, Kieran Tyrrell, Max Holtmann, Max Hunter,
Christoph Mellauner, Simon Gapp, netdev, linux-kernel
In-Reply-To: <20260710-mv88e6xxx-ptp-fixes-v2-0-af97c38df247@padl.com>
> ---
> Luke Howard (2):
> net: dsa: mv88e6xxx: embedded PTP timestamp support
This can be improved: there is no need to extract the embedded timestamp in the PTP worker as it can be done directly in mv88e6xxx_port_rxtstamp() (provided tstamp_{cc,tc} are protected by a spinlock). DSA can deliver the frame normally, similar to ocelot_ptp_rx_timestamp().
Deferring to the worker can reorder frames such that PTP general messages arrive before the timestamped event messages, which confuses some other PTP implementations such as gptp2d [1].
This optimisation of course only works for ArrTSMode because there is no MDIO read required.
Luke
[1] https://github.com/xl4-shiro/excelfore-gptp
^ permalink raw reply
* [PATCH net] net: pcs: xpcs: fix SGMII state reading
From: Coia Prant @ 2026-07-17 7:43 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit, Russell King, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Jiawen Wu, netdev, linux-kernel, Coia Prant, stable
Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
added a path in xpcs_get_state_c37_sgmii() that reads speed/duplex from
BMCR after AN completes. However, BMCR does not reflect the negotiated
result on the hardware where this has been tested:
- On RK3568 (MAC side SGMII), BMCR returns a fixed hardware reset value
- Wangxun engineer Jiawen Wu confirmed that on their side, "BMCR looks
like it only wants to be return as 0" [0]
The correct information is available in CL37_ANSGM_STS, which contains
the actual link status and negotiated speed/duplex.
This bug was previously masked by phylink core, which overrides the PCS
link state with the PHY state when a PHY is present:
/* If we have a phy, the "up" state is the union of both the
* PHY and the MAC
*/
if (phy)
link_state.link &= pl->phy_state.link;
Thus, when the link is down, the PHY's link_down state is applied on top
of whatever the PCS reports, hiding the broken PCS state reading path.
Modify xpcs_get_state_c37_sgmii() to:
1. Read link state from CL37_ANSGM_STS
2. If link is up, report speed/duplex from CL37_ANSGM_STS
3. Remove the broken BMCR reading path entirely
Also properly set state->an_complete to reflect the AN completion status,
and clear CL37_ANCMPLT_INTR when link is down to avoid stale state.
[0] https://lore.kernel.org/all/000c01dd1593$2ac0b0f0$804212d0$@trustnetic.com/
Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
Cc: stable@vger.kernel.org
Tested-by: Jiawen Wu <jiawenwu@trustnetic.com>
Signed-off-by: Coia Prant <coiaprant@gmail.com>
---
drivers/net/pcs/pcs-xpcs.c | 32 +++++++-------------------------
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/drivers/net/pcs/pcs-xpcs.c b/drivers/net/pcs/pcs-xpcs.c
index e69fa2f0a0e8d..0337e2bcc0125 100644
--- a/drivers/net/pcs/pcs-xpcs.c
+++ b/drivers/net/pcs/pcs-xpcs.c
@@ -1058,6 +1058,7 @@ static int xpcs_get_state_c37_sgmii(struct dw_xpcs *xpcs,
/* Reset link_state */
state->link = false;
+ state->an_complete = false;
state->speed = SPEED_UNKNOWN;
state->duplex = DUPLEX_UNKNOWN;
state->pause = 0;
@@ -1069,6 +1070,8 @@ static int xpcs_get_state_c37_sgmii(struct dw_xpcs *xpcs,
if (ret < 0)
return ret;
+ state->an_complete = ret & DW_VR_MII_AN_STS_C37_ANCMPLT_INTR;
+
if (ret & DW_VR_MII_C37_ANSGM_SP_LNKSTS) {
int speed_value;
@@ -1086,34 +1089,13 @@ static int xpcs_get_state_c37_sgmii(struct dw_xpcs *xpcs,
state->duplex = DUPLEX_FULL;
else
state->duplex = DUPLEX_HALF;
- } else if (ret == DW_VR_MII_AN_STS_C37_ANCMPLT_INTR) {
- int speed, duplex;
-
- state->link = true;
-
- speed = xpcs_read(xpcs, MDIO_MMD_VEND2, MII_BMCR);
- if (speed < 0)
- return speed;
-
- speed &= BMCR_SPEED100 | BMCR_SPEED1000;
- if (speed == BMCR_SPEED1000)
- state->speed = SPEED_1000;
- else if (speed == BMCR_SPEED100)
- state->speed = SPEED_100;
- else if (speed == 0)
- state->speed = SPEED_10;
-
- duplex = xpcs_read(xpcs, MDIO_MMD_VEND2, MII_ADVERTISE);
- if (duplex < 0)
- return duplex;
- if (duplex & ADVERTISE_1000XFULL)
- state->duplex = DUPLEX_FULL;
- else if (duplex & ADVERTISE_1000XHALF)
- state->duplex = DUPLEX_HALF;
+ return 0;
+ }
+ /* Clear AN complete status or interrupt */
+ if (state->an_complete)
xpcs_write(xpcs, MDIO_MMD_VEND2, DW_VR_MII_AN_INTR_STS, 0);
- }
return 0;
}
--
2.47.3
^ permalink raw reply related
* [PATCH net] ipv4: reject impossible oversized fragments at queue time
From: Yuxiang Yang @ 2026-07-17 7:41 UTC (permalink / raw)
To: netdev
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms,
linux-kernel, Yuxiang Yang, stable, Yizhou Zhao, Ao Wang,
Xuewei Feng, Qi Li, Ke Xu, yyxroy22
ip_frag_queue() computes each incoming fragment's end offset and may
store it in qp->q.len without checking that the fragment can fit within
the 65535 byte IPv4 datagram limit, even with the minimum IPv4 header.
The only 65535 byte check lives later in ip_frag_reasm(), after the
fragment has already been accepted into the reassembly queue and has
updated its state.
A fragment whose end offset exceeds 65535 minus the minimum 20-byte IPv4
header cannot be part of any valid IPv4 datagram. Letting it update
qp->q.len leaves the shared reassembly queue with an impossible expected
length. A later legitimate two-fragment datagram sharing that key can no
longer complete reassembly and is not delivered.
This was verified at runtime on Linux 6.12.93-0-virt. A same-key
oversized-fragment injection (offset 65528, payload 8, end 65536) drove
legitimate two-fragment UDP delivery from 8/8 to 0/8, while a cross-ID
control stayed at 8/8.
With this change applied to net main, the same-key test delivered 8/8.
A valid 65535-byte datagram with a 20-byte header was also delivered with
both in-order and reverse-order fragments; its 65507-byte UDP payload
was intact in both cases.
Add a per-fragment bound check in ip_frag_queue() right after computing
end and before any qp->q.len update or skb insertion. IPv4 always needs
at least a struct iphdr, so an end offset greater than IP_MAX_MTU minus
sizeof(struct iphdr) cannot fit in any valid IPv4 datagram. Use that
minimum-header bound rather than the current fragment's IHL because
fragments may arrive out of order and the first fragment may carry
non-copied options that later fragments lack. The existing check in
ip_frag_reasm() continues to validate the final length against the
actual header length of the first fragment.
Drop only the invalid skb so an existing queue for the same key remains
intact.
The issue was found by Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng,
Qi Li, and Ke Xu, with assistance from GLM-5.2 by Z.ai.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
---
net/ipv4/ip_fragment.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index c790d2f49..32e5240a5 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -291,6 +291,8 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb, int *refs)
/* Determine the position of this fragment. */
end = offset + skb->len - skb_network_offset(skb) - ihl;
err = -EINVAL;
+ if (end > IP_MAX_MTU - sizeof(struct iphdr))
+ goto err;
/* Is this the final fragment? */
if ((flags & IP_MF) == 0) {
--
2.34.1
^ permalink raw reply related
* [PATCH net] net/mlx5: E-Switch, fix zero num_dest in prio_tag egress vlan rule
From: Tariq Toukan @ 2026-07-17 7:33 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
netdev, Paolo Abeni
Cc: Cosmin Ratiu, Kees Cook, Leon Romanovsky, linux-kernel,
linux-rdma, Mark Bloch, Saeed Mahameed, Tariq Toukan, Yael Chemla
From: Yael Chemla <ychemla@nvidia.com>
esw_egress_acl_vlan_create() hardcodes num_dest=0 in its
mlx5_add_flow_rules() call. When invoked from the non-bond path
fwd_dest is NULL and num_dest=0 is correct. When invoked from
esw_acl_egress_ofld_rules_create() during a bond event, fwd_dest is
non-NULL and flow_act.action carries MLX5_FLOW_CONTEXT_ACTION_FWD_DEST,
but _mlx5_add_flow_rules() rejects a non-NULL dest pointer paired with
dest_num<=0 and returns -EINVAL. The error propagates as
"configure slave vport egress fwd, err(-22)". The passive vport's egress
ACL table ends up with its flow groups allocated but no FTEs, so
prio-tagged packets are not popped and bond failover is broken on
prio_tag_required devices.
Fix by passing fwd_dest ? 1 : 0 as num_dest to match the actual number
of destinations supplied.
Fixes: bf773dc0e6d5 ("net/mlx5: E-Switch, Introduce APIs to enable egress acl forward-to-vport rule")
Signed-off-by: Yael Chemla <ychemla@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/esw/acl/helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/helper.c b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/helper.c
index ba5cce706ea2..9693c74e9b16 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/helper.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/esw/acl/helper.c
@@ -71,7 +71,7 @@ int esw_egress_acl_vlan_create(struct mlx5_eswitch *esw,
flow_act.action = flow_action;
vport->egress.allowed_vlan =
mlx5_add_flow_rules(vport->egress.acl, spec,
- &flow_act, fwd_dest, 0);
+ &flow_act, fwd_dest, fwd_dest ? 1 : 0);
if (IS_ERR(vport->egress.allowed_vlan)) {
err = PTR_ERR(vport->egress.allowed_vlan);
esw_warn(esw->dev,
base-commit: 3f1f755366687d051174739fb99f7d560202f60b
--
2.44.0
^ permalink raw reply related
* [PATCH net] net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock
From: Tariq Toukan @ 2026-07-17 7:30 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
netdev, Paolo Abeni
Cc: Cosmin Ratiu, Leon Romanovsky, linux-kernel, linux-rdma,
Mark Bloch, Saeed Mahameed, Shay Drory, Tariq Toukan
From: Shay Drory <shayd@nvidia.com>
In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is
deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring
ESW devcom lock without condition. In addition, in case of peer_flow,
__mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock.
This results in an AA deadlock.
To fix this, introduce a new PEER flag that is set on flows created as
peer flows (the duplicate flows on peer devices), and check it in
mlx5e_tc_del_flow() before acquiring ESW devcom lock.
In addition, rename the existing DUP flag to PRIMARY to better reflect
its semantics. The DUP flag indicated that a flow has peer flows on
other devices, but the name was not descriptive. PRIMARY clearly
indicates this is the original flow that manages peer flows.
This makes the distinction between the two flow roles explicit:
- PRIMARY: the original flow that owns and manages peer flows
- PEER: the duplicate flows created on peer devices
Lockdep splat:
============================================
WARNING: possible recursive locking detected
============================================
Possible unsafe locking scenario:
CPU0
----
lock(&comp->lock_key#2);
lock(&comp->lock_key#2);
*** DEADLOCK ***
Call Trace:
<TASK>
dump_stack_lvl+0x69/0xa0
print_deadlock_bug.cold+0xbd/0xca
__lock_acquire+0x1671/0x2ec0
lock_acquire+0x10e/0x2e0
down_read+0x95/0x430
mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core]
mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core]
mlx5e_flow_put+0x99/0x100 [mlx5_core]
__mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core]
mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core]
mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core]
mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core]
tc_setup_cb_add+0x1dc/0x470
fl_change+0x2f4d/0x626d [cls_flower]
tc_new_tfilter+0x79b/0x2310
rtnetlink_rcv_msg+0x778/0xad0
do_syscall_64+0x70/0x960
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
Fixes: 04de7dda7394 ("net/mlx5e: Infrastructure for duplicated offloading of TC flows")
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h
index 28cab4bf525c..7bfe7cdc5770 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h
@@ -30,6 +30,7 @@ enum {
MLX5E_TC_FLOW_FLAG_FAILED = MLX5E_TC_FLOW_BASE + 9,
MLX5E_TC_FLOW_FLAG_SAMPLE = MLX5E_TC_FLOW_BASE + 10,
MLX5E_TC_FLOW_FLAG_USE_ACT_STATS = MLX5E_TC_FLOW_BASE + 11,
+ MLX5E_TC_FLOW_FLAG_PEER = MLX5E_TC_FLOW_BASE + 12,
};
struct mlx5e_tc_flow_parse_attr {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 1bc7b9019124..b290beb4369a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2161,7 +2161,8 @@ static void mlx5e_tc_del_flow(struct mlx5e_priv *priv,
if (mlx5e_is_eswitch_flow(flow)) {
struct mlx5_devcom_comp_dev *devcom = flow->priv->mdev->priv.eswitch->devcom;
- if (!mlx5_devcom_for_each_peer_begin(devcom)) {
+ if (flow_flag_test(flow, PEER) ||
+ !mlx5_devcom_for_each_peer_begin(devcom)) {
mlx5e_tc_del_fdb_flow(priv, flow);
return;
}
@@ -4628,6 +4629,7 @@ static int mlx5e_tc_add_fdb_peer_flow(struct flow_cls_offload *f,
else
in_mdev = priv->mdev;
+ flow_flags |= BIT(MLX5E_TC_FLOW_FLAG_PEER);
parse_attr = flow->attr->parse_attr;
peer_flow = __mlx5e_add_fdb_flow(peer_priv, f, flow_flags,
parse_attr->filter_dev,
base-commit: 3f1f755366687d051174739fb99f7d560202f60b
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v1 net 1/2] soreuseport: Clear sk_reuseport_cb before failure in sk_clone().
From: Willem de Bruijn @ 2026-07-17 7:31 UTC (permalink / raw)
To: Kuniyuki Iwashima, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Willem de Bruijn
Cc: Simon Horman, Octavian Purdila, Daniel Borkmann,
Alexei Starovoitov, Martin KaFai Lau, Kuniyuki Iwashima,
Kuniyuki Iwashima, netdev, Sashiko
In-Reply-To: <20260709183315.965751-2-kuniyu@google.com>
Kuniyuki Iwashima wrote:
> When sk_clone() fails, sk_destruct() is called for the new socket.
>
> If the parent socket has sk->sk_reuseport_cb, the child will call
> reuseport_detach_sock() for the reuseport group.
>
> Let's clear sk->sk_reuseport_cb before any failure path in sk_clone().
>
> Note that this was not a problem before the cited commit because
> reuseport_detach_sock() did nothing if the socket was not found in
> the reuseport array.
>
> Fixes: 5dc4c4b7d4e8 ("bpf: Introduce BPF_MAP_TYPE_REUSEPORT_SOCKARRAY")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260709032007.9E4D61F000E9@smtp.kernel.org/
> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH v1 net 2/2] net: Call net_enable_timestamp() before failure in sk_clone().
From: Willem de Bruijn @ 2026-07-17 7:29 UTC (permalink / raw)
To: Kuniyuki Iwashima, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Willem de Bruijn
Cc: Simon Horman, Octavian Purdila, Daniel Borkmann,
Alexei Starovoitov, Martin KaFai Lau, Kuniyuki Iwashima,
Kuniyuki Iwashima, netdev, Sashiko
In-Reply-To: <20260709183315.965751-3-kuniyu@google.com>
Kuniyuki Iwashima wrote:
> When sk_clone() fails, sk_destruct() is called for the new socket.
>
> If the parent socket has SK_FLAGS_TIMESTAMP in sk->sk_flags,
> net_disable_timestamp() is called for the child socket even though
> net_enable_timestamp() is not called for it.
>
> Let's call net_enable_timestamp() before any failure path in
> sk_clone().
>
> Fixes: 704da560c0a0 ("tcp: update the netstamp_needed counter when cloning sockets")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260709032007.9E4D61F000E9@smtp.kernel.org/
> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [REGRESSION][BISECTED] stmmac: suspend hangs since 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts")
From: tresonic @ 2026-07-17 7:18 UTC (permalink / raw)
To: Andrew Lunn; +Cc: netdev, regressions, rmk+kernel, kuba
In-Reply-To: <17ebe5ba-16a5-4b3a-94cd-e9707c88df3e@lunn.ch>
On 7/16/26 11:47 PM, Andrew Lunn wrote:
> On Thu, Jul 16, 2026 at 10:10:25PM +0200, tresonic wrote:
>> Hello,
>> Please bear with me, this is my first time writing to a mailing list...
>
> Thanks for the report. Nice description for a first post. Lots of
> useful details.
>
>> Since commit 1b9707e6f1a9, suspend (systemctl suspend) causes a full system freeze on my laptop. Fans and keyboard backlight stay powered; the machine is completely unresponsive and requires a hard power-off (holding the power button) to recover. I could not get any kernel output from the hang.
>
> 1b9707e6f1a9 makes in effect 4 changes.
>
> Can you do some testing to see if the changes to
> DMA_CHAN_INTR_ABNORMAL or the changes to DMA_CHAN_INTR_ABNORMAL_4_10
> break it. Or both, but i think that is unlikely.
>
> Once you know which of those is responsible, can you test to see which
> of DMA_CHAN_INTR_ENA_RPS or DMA_CHAN_INTR_ENA_RBU broke it.
>
> It kind of sounds like an interrupt storm, but that is just a
> guess. If it is an interrupt storm, it suggests an interrupt is not
> being disabled during suspend.
>
> Andrew
I tested the changes as you suggested and it seems DMA_CHAN_INTR_ENA_RPS in DMA_CHAN_INTR_ABNORMAL_4_10 broke it.
With this change on master suspend is working:
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
index 43b036d4e95b..e907142c9ee2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
@@ -121,7 +121,6 @@ static inline u32 dma_chanx_base_addr(const struct dwmac4_addrs *addrs,
DMA_CHAN_INTR_ENA_TIE)
#define DMA_CHAN_INTR_ABNORMAL_4_10 (DMA_CHAN_INTR_ENA_AIE_4_10 | \
- DMA_CHAN_INTR_ENA_RPS | \
DMA_CHAN_INTR_ENA_RBU | \
DMA_CHAN_INTR_ENA_FBE)
/* DMA default interrupt mask for 4.10a */
tresonic
^ permalink raw reply related
* RE: [External Mail] Re: [PATCH v4 6/7] net: wwan: t9xx: Add AT & MBIM WWAN ports
From: Wu. JackBB (GSM) @ 2026-07-17 7:26 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20260716093429.231132-1-horms@kernel.org>
Hi Simon,
On ... sashiko wrote:
> > +static int mtk_port_wwan_write(...)
> > + if (ret < 0)
> > + return ret;
> > +
> > + consume_skb(skb);
> > + return 0;
>
> [Severity: High]
> If mtk_port_common_write() successfully sends the first few fragments
> but fails on subsequent ones ... does this code silently drop the
> remaining data?
This is a design limitation of the WWAN port API:
wwan_port_op_tx returns 0 for success or negative for error —
there is no mechanism to report partial writes back to the WWAN
core. The already-submitted fragments cannot be recalled from
the DMA engine. For the AT/MBIM control ports, messages are
small (typically under 1KB, within a single MTU). The
multi-fragment path is rarely exercised for control plane
traffic.
> > +static int mtk_port_wwan_write_blocking(...)
> > + if (ret < 0)
> > + return ret;
> > +
> > + consume_skb(skb);
> > + return 0;
>
> [Severity: High]
> Can the same silent drop of partially written SKBs happen here?
Same reasoning as above. The WWAN port API does not support
partial write reporting, and control plane messages are
typically within a single MTU.
> > +static int mtk_port_wwan_enable(...)
> > + port->w_priv.w_port = wwan_create_port(...);
> > + if (IS_ERR(port->w_priv.w_port)) {
>
> [Severity: High]
> Can a race condition occur here if wwan_create_port() fails?
mtk_port_wwan_enable() is called from the FSM thread during
the handshake sequence, before the port starts receiving data.
The CLDMA RX queue for this port has not been opened at this
point — RX data only arrives after the modem completes its
handshake. The RX path cannot observe the error pointer.
During teardown, mtk_port_wwan_disable() holds w_lock when
clearing w_port, and mtk_port_wwan_recv() checks w_port under
the same lock, so the RX path is properly synchronized.
Thanks.
Jack Wu
^ permalink raw reply
* [PATCH net] net/mlx5: FW tracer, clamp firmware-reported num_string_db
From: Tariq Toukan @ 2026-07-17 7:25 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
netdev, Paolo Abeni
Cc: Akiva Goldberger, Gal Pressman, Kees Cook, Leon Romanovsky,
linux-kernel, linux-rdma, Mark Bloch, Moshe Shemesh,
Saeed Mahameed, Shay Drori, Tariq Toukan
From: Akiva Goldberger <agoldberger@nvidia.com>
mlx5_query_mtrc_caps() reads num_string_db from the MTRC capabilities
register and uses it directly as a loop bound to populate the fixed-size
base_address_out[STRINGS_DB_SECTIONS_NUM] and
size_out[STRINGS_DB_SECTIONS_NUM] arrays in the tracer's str_db
structure (STRINGS_DB_SECTIONS_NUM == 8).
The field is 4 bits wide, so firmware can report up to 15. A value
greater than STRINGS_DB_SECTIONS_NUM makes the loop write past the end
of those arrays, corrupting adjacent fields of the fw_tracer structure
on the kernel heap. Clamp the firmware-reported value before it is used.
Fixes: f53aaa31cce7 ("net/mlx5: FW tracer, implement tracer logic")
Signed-off-by: Akiva Goldberger <agoldberger@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c b/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
index adcc73e2a5b3..404736c46adf 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/diag/fw_tracer.c
@@ -64,6 +64,13 @@ static int mlx5_query_mtrc_caps(struct mlx5_fw_tracer *tracer)
tracer->str_db.num_string_trace =
MLX5_GET(mtrc_cap, out, num_string_trace);
tracer->str_db.num_string_db = MLX5_GET(mtrc_cap, out, num_string_db);
+ if (tracer->str_db.num_string_db > STRINGS_DB_SECTIONS_NUM) {
+ mlx5_core_warn(dev,
+ "FWTracer: Firmware reports num_string_db (%u) > (%u), clamping\n",
+ tracer->str_db.num_string_db,
+ STRINGS_DB_SECTIONS_NUM);
+ tracer->str_db.num_string_db = STRINGS_DB_SECTIONS_NUM;
+ }
tracer->owner = !!MLX5_GET(mtrc_cap, out, trace_owner);
tracer->str_db.loaded = false;
base-commit: 3f1f755366687d051174739fb99f7d560202f60b
--
2.44.0
^ permalink raw reply related
* RE: [External Mail] Re: [PATCH v4 5/7] net: wwan: t9xx: Add FSM thread
From: Wu. JackBB (GSM) @ 2026-07-17 7:24 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20260716093422.231112-1-horms@kernel.org>
Hi Simon,
> > +static int mtk_fsm_parse_hs2_msg(...)
>
> [Severity: High]
> Assumes entire SKB payload is linearly accessible without checking
> boundaries using pskb_may_pull() before direct dereferencing.
The RX SKBs are allocated internally by the CLDMA driver using
__dev_alloc_skb with linear buffers. The control message data
always resides in the contiguous linear data region. These SKBs
are not received from the network stack and are always linear,
so pskb_may_pull is not needed.
> [Severity: High]
> The rtft_entry->data is passed to action callbacks before data_len
> is validated against buffer bounds.
The bounds check at the loop start ensures the rtft_entry struct
header is within bounds. The action functions only read fixed-size
fields (e.g., a single __le32 for packet padding mode). The modem
firmware is a trusted source with head_pattern/tail_pattern
integrity checks.
> > +static int mtk_fsm_send_hs3_msg(...)
> > + skb = __dev_alloc_skb(...)
>
> [Severity: High]
> Uninitialized kernel heap memory leak. Buffer is not zeroed.
In mtk_fsm_append_rtft_entries, each runtime_feature_entry has
feature_id, support_info, and data_len explicitly set. The
reserved[2] field is not zeroed, but this data is sent to the
local modem over PCIe DMA as part of the HS3 handshake — it is
not exposed to external networks. The modem firmware ignores the
reserved field.
> > +static int mtk_fsm_sap_ctrl_msg_handler(...)
> > + skb_pull(skb, ...)
>
> [Severity: High]
> Missing pskb_may_pull() call.
Same as above. The RX SKBs are internal linear buffers from the
CLDMA driver. skb->len is checked before accessing skb->data.
> [Severity: High]
> Dangling pointer and SKB leak. If mtk_fsm_evt_submit() fails,
> SKB is freed but hs_info->rt_data not nulled.
We will add hs_info->rt_data = NULL after dev_kfree_skb(skb) in
the evt_submit failure path to avoid leaving a dangling pointer.
The same fix will be applied to mtk_fsm_md_ctrl_msg_handler
which has the identical pattern.
> > +static int mtk_port_ch_disable(...)
> > + wait_event_interruptible_timeout(...)
>
> [Severity: High]
> Infinite busy loop on signal pending.
This is intentional. Channel disable must complete or timeout —
aborting mid-operation would leave the channel in an inconsistent
state. The loop does not busy-spin: each iteration sleeps in
wait_event_interruptible_timeout until the condition is met or
the timeout expires. The timeout guarantees bounded execution.
> > +static int mtk_fsm_evt_submit(...)
> > + spin_unlock_irqrestore(...)
>
> [Severity: High]
> Race condition during teardown. fsm->fsm_handler could become
> NULL before wake_up_process().
mtk_fsm_exit() first submits a FSM_EVT_DEV_RM event. The FSM
kthread processes this and sets EVT_TF_GATECLOSED under
evtq_lock. Only after the kthread finishes does mtk_fsm_exit()
call kthread_stop() and set fsm_handler to NULL. If
mtk_fsm_evt_submit() passes the EVT_TF_GATECLOSED check inside
the spinlock, fsm_handler is still valid at the point of
wake_up_process().
> > +static int mtk_port_disable(...)
> > + kcalloc(...)
>
> [Severity: High]
> Silent allocation failure.
The kcalloc allocates a small temporary array of pointers
(typically a few hundred bytes). Allocation failure at this size
is extremely unlikely. Additionally, mtk_port_disable is called
during FSM_STATE_OFF transition, when the modem hardware has
already been power-cycled via PLDR. The hardware channels are
no longer active regardless of the software port state.
> > +static int mtk_fsm_notifier_register(...)
>
> [Severity: Medium]
> Race condition on notifier lists.
The notifier registration and unregistration are only called
during driver probe and remove paths, which are serialized by
the driver model. The FSM kthread does not start processing
events until probe completes, so there is no concurrent access
to the notifier lists.
> > +static void mtk_fsm_evt_cleanup(...)
>
> [Severity: Medium]
> Incomplete event queue cleanup. Cleanup misses freeing SKB stored
> in shared fsm->hs_info[].rt_data if HS2 message was pending.
We Will add rt_data cleanup in the teardown path in v5.
Thanks.
Jack Wu
^ permalink raw reply
* [PATCH net] net/mlx5: Fix MCIA register buffer overflow on 32 dword reads
From: Tariq Toukan @ 2026-07-17 7:23 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
netdev, Paolo Abeni
Cc: Alex Lazar, Gal Pressman, Leon Romanovsky, linux-kernel,
linux-rdma, Mark Bloch, Maxim Mikityanskiy, Saeed Mahameed,
Tariq Toukan
From: Gal Pressman <gal@nvidia.com>
The MCIA register can return up to 32 dwords (128 bytes) when the device
advertises the mcia_32dwords capability, but struct
mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just
12 dwords (48 bytes) of data.
mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then
memcpy()s that many bytes out of the register, potentially reading past
the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this
is caught as a buffer overflow while reading the module EEPROM via
ethtool:
detected buffer overflow in memcpy
kernel BUG at lib/string_helpers.c:1048!
RIP: 0010:fortify_panic+0x13/0x20
Call Trace:
mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core]
mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core]
mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core]
eeprom_prepare_data+0xf3/0x170
ethnl_default_doit+0xf1/0x3b0
Extend the mcia_reg layout to 32 dwords.
Fixes: 271907ee2f29 ("net/mlx5: Query the maximum MCIA register read size from firmware")
Signed-off-by: Gal Pressman <gal@nvidia.com>
Reviewed-by: Alex Lazar <alazar@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/port.c | 4 ++--
include/linux/mlx5/mlx5_ifc.h | 13 +------------
2 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/port.c b/drivers/net/ethernet/mellanox/mlx5/core/port.c
index ddbe9ca8971d..9f682f6bdb50 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/port.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/port.c
@@ -314,7 +314,7 @@ static int mlx5_query_module_id(struct mlx5_core_dev *dev, int module_num,
return -EIO;
}
- ptr = MLX5_ADDR_OF(mcia_reg, out, dword_0);
+ ptr = MLX5_ADDR_OF(mcia_reg, out, dwords);
*module_id = ptr[0];
@@ -399,7 +399,7 @@ static int mlx5_query_mcia(struct mlx5_core_dev *dev,
return -EIO;
}
- ptr = MLX5_ADDR_OF(mcia_reg, out, dword_0);
+ ptr = MLX5_ADDR_OF(mcia_reg, out, dwords);
memcpy(data, ptr, size);
return size;
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 695c86ee6d7a..8f18a508320d 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -12215,18 +12215,7 @@ struct mlx5_ifc_mcia_reg_bits {
u8 reserved_at_60[0x20];
- u8 dword_0[0x20];
- u8 dword_1[0x20];
- u8 dword_2[0x20];
- u8 dword_3[0x20];
- u8 dword_4[0x20];
- u8 dword_5[0x20];
- u8 dword_6[0x20];
- u8 dword_7[0x20];
- u8 dword_8[0x20];
- u8 dword_9[0x20];
- u8 dword_10[0x20];
- u8 dword_11[0x20];
+ u8 dwords[0x400];
};
struct mlx5_ifc_dcbx_param_bits {
base-commit: 3f1f755366687d051174739fb99f7d560202f60b
--
2.44.0
^ permalink raw reply related
* Re: [PATCH v4 net-next 3/7] selftests/ptp: Add testptp support for attributes ioctls
From: Arthur Kiyanovski @ 2026-07-17 7:20 UTC (permalink / raw)
To: saeed bishara
Cc: Arthur Kiyanovski, David Miller, Jakub Kicinski, netdev,
Richard Cochran, Eric Dumazet, Paolo Abeni, David Woodhouse,
Thomas Gleixner, Miroslav Lichvar, Andrew Lunn, Wen Gu, Xuan Zhuo,
David Woodhouse, Yonatan Sarna, Zorik Machulsky,
Alexander Matushevsky, Saeed Bshara, Matt Wilson, Anthony Liguori,
Nafea Bshara, Evgeny Schmeilin, Netanel Belgazal, Ali Saidi,
Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
vadim.fedorenko
In-Reply-To: <CAHfVqdWDaLEKYMw-ZfkYvKLoSJ-_HOm3X9hUUhEf7ReBbOi__w@mail.gmail.com>
On 2026-07-16 16:00:49+03:00, saeed bishara wrote:
> > " -t val shift the ptp clock time by 'val' seconds\n"
> > " -T val set the ptp clock time to 'val' seconds\n"
> > " -x val get an extended ptp clock time with the desired number of samples (up to %d)\n"
> > + " -a val get extended timestamps with attributes (error_bound,\n"
>
> timestamps -> ptp clock to be consistent
> also, have you considered making the "-a" additional flag to -x and -A
> instead of an exclusive option?
>
> > + printf("sample #%2d: unknown clock %d %s: %lld.%09u\n",
> > + sample_num, clockid, when, sec, nsec);
>
> In the case of an unknown clock, will the additional parameters
> (when/sec/..) be useful?
>
> > break;
> > }
> > }
> > @@ -188,6 +193,7 @@ int main(int argc, char *argv[])
> > struct ptp_sys_offset *sysoff;
> > struct ptp_sys_offset_extended *soe;
> > struct ptp_sys_offset_precise *xts;
> > + struct ptp_sys_offset_attrs *attrs_data;
> >
> > char *progname;
> > unsigned int i;
> > @@ -208,7 +214,9 @@ int main(int argc, char *argv[])
> > int list_pins = 0;
> > int pct_offset = 0;
> > int getextended = 0;
> > + int getextendedattrs = 0;
> > int getcross = 0;
> > + int getcrossattrs = 0;
> > int n_samples = 0;
> > int pin_index = -1, pin_func;
> > int pps = -1;
> > @@ -226,7 +234,8 @@ int main(int argc, char *argv[])
> >
> > progname = strrchr(argv[0], '/');
> > progname = progname ? 1+progname : argv[0];
> > - while (EOF != (c = getopt(argc, argv, "cd:e:E:f:F:ghH:i:k:lL:n:o:p:P:rsSt:T:w:x:Xy:z"))) {
> > + while (EOF != (c = getopt(argc, argv,
> > + "a:Acd:e:E:f:F:ghH:i:k:lL:n:o:p:P:rsSt:T:w:x:Xy:z"))) {
> > switch (c) {
> > case 'c':
> > capabilities = 1;
> > @@ -311,9 +320,22 @@ int main(int argc, char *argv[])
> > return -1;
> > }
> > break;
> > + case 'a':
> > + getextendedattrs = atoi(optarg);
> > + if (getextendedattrs < 1 ||
> > + getextendedattrs > PTP_MAX_SAMPLES) {
> > + fprintf(stderr,
> > + "number of extended attrs timestamp samples must be between 1 and %d; was asked for %d\n",
> > + PTP_MAX_SAMPLES, getextendedattrs);
> > + return -1;
> > + }
> > + break;
> > case 'X':
> > getcross = 1;
> > break;
> > + case 'A':
> > + getcrossattrs = 1;
> > + break;
> > case 'y':
> > if (!strcasecmp(optarg, "realtime"))
> > ext_clockid = CLOCK_REALTIME;
> > @@ -367,6 +389,8 @@ int main(int argc, char *argv[])
> > " %d programmable pins\n"
> > " %d cross timestamping\n"
> > " %d adjust_phase\n"
> > + " %d extended_attrs\n"
> > + " %d precise_attrs\n"
> > " %d maximum phase adjustment (ns)\n",
> > caps.max_adj,
> > caps.n_alarm,
> > @@ -376,6 +400,8 @@ int main(int argc, char *argv[])
> > caps.n_pins,
> > caps.cross_timestamping,
> > caps.adjust_phase,
> > + caps.extended_attrs,
> > + caps.precise_attrs,
> > caps.max_phase_adj);
> > }
> > }
> > @@ -648,6 +674,49 @@ int main(int argc, char *argv[])
> > free(soe);
> > }
> >
> > + if (getextendedattrs) {
> > + attrs_data = calloc(1, sizeof(*attrs_data) +
> > + getextendedattrs * sizeof(struct ptp_timestamp));
> > + if (!attrs_data) {
> > + perror("calloc");
> > + return -1;
> > + }
> > +
> > + attrs_data->request.num_samples = getextendedattrs;
> > + attrs_data->request.clock_id = ext_clockid;
> > +
> > + if (ioctl(fd, PTP_SYS_OFFSET_EXTENDED_ATTRS, attrs_data)) {
> > + perror("PTP_SYS_OFFSET_EXTENDED_ATTRS");
> > + } else {
> > + printf("extended attrs timestamp request returned %d samples\n",
> > + getextendedattrs);
> > +
> > + for (i = 0; i < getextendedattrs; i++) {
> > + struct ptp_timestamp *ts = &attrs_data->timestamps[i];
> > +
> > + printf(" sample #%u:\n", i);
> > + printf(" sys before: %lld ns\n",
> > + (long long)ts->pre_systime.sys_time);
> > + printf(" phc time: %lld.%09u\n",
> > + ts->devtime.device_time.sec,
> > + ts->devtime.device_time.nsec);
> > + if (ts->devtime.attrs.valid & PTP_ATTRS_VALID_ERROR_BOUND)
> > + printf(" error_bound: %u ns\n",
> > + ts->devtime.attrs.error_bound);
>
> in case device doesn't report error bound, I think it's better to
> print explicit message
All addressed in v5: -a is now a modifier on -x/-X (dropped -A, use
-X -a) as you suggested; usage text updated; the unknown-clock line is
trimmed to just the clock id; and attributes the device doesn't report
now print "not reported".
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v4 4/7] net: wwan: t9xx: Add control port
From: Wu. JackBB (GSM) @ 2026-07-17 7:20 UTC (permalink / raw)
To: Simon Horman
Cc: loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com,
johannes@sipsolutions.net, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, wen-zhi.huang@mediatek.com,
shi-wei.yeh@mediatek.com, Minano.tseng@mediatek.com,
matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com,
corbet@lwn.net, skhan@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <20260716093414.231093-1-horms@kernel.org>
Hi Simon,
> > +static void mtk_port_free_or_backup(...)
>
> [Severity: High]
> Does this directly bypass the kref API?
Will fix in v5. The kref count is 1 at this point (the initial
allocation reference only), so the behavior is correct — but
kref_put is the proper API. Will change to
kref_put(&port->kref, mtk_port_release). Same fix applied to
mtk_port_stale_list_grp_cleanup below.
> > +static struct mtk_port *mtk_port_search_by_id(...)
>
> [Severity: High]
> Is it safe to perform radix tree lookups without an RCU read-side
> critical section?
mtk_port_search_by_id is called from the CLDMA workqueue context
(rx_dispatch) and during probe/FSM startup. Port creation and
destruction are driven by FSM state transitions on the FSM
kthread. Ports are created before the CLDMA RX queue is opened,
and the RX queue is stopped before ports are destroyed. No
concurrent modification occurs during radix tree lookups.
The tree was initialized with INIT_RADIX_TREE (not RCU-tagged),
and all modifications are serialized by FSM state ordering.
> > +static struct mtk_port *mtk_port_search_by_name(...)
>
> [Severity: High]
> Does this radix tree iteration require rcu_read_lock() protection?
mtk_port_search_by_name is only called from
mtk_port_internal_open, which is exclusively invoked by the FSM
kthread during mtk_fsm_ctrl_ch_start. Port creation and
destruction are also driven by FSM state transitions on the same
kthread. Since the FSM serializes these operations, no concurrent
port removal can occur while iterating.
> > +static void mtk_port_stale_list_grp_cleanup(...)
>
> [Severity: High]
> This appears to be another instance of bypassing the kref API by
> calling mtk_port_release() directly instead of kref_put().
We will fix in v5:
Use kref_put(&port->kref, mtk_port_release) instead of
calling mtk_port_release() directly. The clear_bit before
it ensures no double list_del, and kref count is 1 so the
behavior is unchanged — but kref_put is the proper API.
> [Severity: Medium]
> Does this leak the s_list->dev_id? The list entries are freed here during
> module unload, but there doesn't appear to be a corresponding call to
> ida_free() to return the dev_id to the allocator.
We will fix in v5,Add ida_free before kfree(s_list) to properly release the
dev_id:
if (s_list->dev_id >= 0)
ida_free(&ccci_dev_ids, s_list->dev_id);
kfree(s_list);
> > +static int mtk_port_trb_init(...)
>
> [Severity: High]
> Does this assignment need to take a reference to the port with
> kref_get()?
The TRB lifecycle is protected by kref on the TRB itself
(kref_get before submit, kref_put in both the caller and the
completion callback). The port is not freed while TRBs reference
it — port destruction goes through kref_put(&port->kref,
mtk_port_release), and TRB_CMD_DISABLE triggers
mtk_ctrl_ch_flush, which forces all pending TRBs to complete
before the port teardown proceeds.
> > +static int mtk_port_send_data(...)
>
> [Severity: Medium]
> Can concurrent writers corrupt the tx_seq variable?
tx_seq is a per-port 8-bit sequence number with a single writer
per port: external ports are serialized by the WWAN core
ops_lock mutex around tx/tx_blocking callbacks, and internal
ports are written exclusively by the FSM kthread. Concurrent
transmissions on the same port do not occur.
> > +static int mtk_port_rx_dispatch_frag_skb(...)
>
> [Severity: High]
> Can this lead to use-after-free and double-free on the skb?
No. The recv callback (mtk_port_internal_recv) does not free
the skb on error — it returns -ENXIO and leaves skb ownership
with the caller. When recv returns an error, it is safe to
access the skb to restore frag_list. The caller
(mtk_port_rx_dispatch) then frees the skb once in the
drop_data path.
> > +static int mtk_port_rx_dispatch(...)
>
> [Severity: High]
> This is where the second free of the skb occurs when propagating
> the error from the recv callback.
As above, the recv callback does not free the skb on error.
The drop_data path in mtk_port_rx_dispatch is the only place
the skb is freed — no double free occurs.
> > +static void mtk_port_add_header(...)
>
> [Severity: Medium]
> This is the other side of the tx_seq data race.
Same as above — tx_seq is serialized by the WWAN core ops_lock
for external ports and the single-threaded FSM kthread for
internal ports.
> > +static int mtk_port_status_update(...)
>
> [Severity: High]
> Is there a missing bounds check on msg->port_cnt here?
The message is validated by head_pattern, tail_pattern, and
version checks before the loop. The port enumeration protocol
between host and modem guarantees the buffer contains exactly
port_cnt entries. The modem firmware is a trusted source —
this is a control plane interface, not an untrusted network
protocol.
> > +static int mtk_port_ch_enable(...)
>
> [Severity: High]
> Could this create an infinite loop in kernel space?
This is intentional. Channel enable/disable are control plane
operations that must complete or timeout — aborting mid-operation
due to a signal would leave the channel in an inconsistent state.
The loop does not busy-spin: each iteration sleeps in
wait_event_interruptible_timeout until the condition is met or
the timeout (MTK_DFLT_TRB_TIMEOUT) expires. The timeout
guarantees bounded execution.
> > +static int mtk_port_ch_disable(...)
>
> [Severity: High]
> This appears to have the same infinite loop risk.
Same reasoning as mtk_port_ch_enable. The timeout guarantees
bounded execution per iteration.
> > +static int mtk_port_internal_recv(...)
>
> [Severity: High]
> This is where the skb is freed on the error path before returning
> -ENXIO.
mtk_port_internal_recv does not free the skb on the error path.
The drop_data label simply returns -ENXIO without calling
dev_kfree_skb_any(). The skb ownership remains with the caller.
> > +static int mtk_port_common_open(...)
>
> [Severity: High]
> Is this test_bit() and set_bit() sequence intended to provide
> mutual exclusion?
All callers of mtk_port_common_open acquire port_mngr_grp_mtx
via mtk_port_get_locked before calling this function, which
serializes concurrent open attempts on the same port. The
test_bit/set_bit sequence is protected by the mutex.
Thanks.
Jack Wu
^ permalink raw reply
* Re: [PATCH v4 net-next 2/7] selftests/ptp: Extract print_system_timestamp helper in testptp
From: Arthur Kiyanovski @ 2026-07-17 7:19 UTC (permalink / raw)
To: saeed bishara
Cc: Arthur Kiyanovski, David Miller, Jakub Kicinski, netdev,
Richard Cochran, Eric Dumazet, Paolo Abeni, David Woodhouse,
Thomas Gleixner, Miroslav Lichvar, Andrew Lunn, Wen Gu, Xuan Zhuo,
David Woodhouse, Yonatan Sarna, Zorik Machulsky,
Alexander Matushevsky, Saeed Bshara, Matt Wilson, Anthony Liguori,
Nafea Bshara, Evgeny Schmeilin, Netanel Belgazal, Ali Saidi,
Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
vadim.fedorenko
In-Reply-To: <CAHfVqdWNk0QmvZBXi21eUKcU34DpXXZBNyJVUep+Tx1n52ihAg@mail.gmail.com>
On 2026-07-16 14:34:57+03:00, saeed bishara wrote:
> > +static void print_system_timestamp(int sample_num, __kernel_clockid_t clockid,
> > + long long sec, unsigned int nsec,
> > + const char *when)
> > +{
> > + switch (clockid) {
> > + case CLOCK_REALTIME:
> > + printf("sample #%2d: real time %s: %lld.%09u\n",
> > + sample_num, when, sec, nsec);
> > + break;
> > + case CLOCK_MONOTONIC:
> > + printf("sample #%2d: monotonic time %s: %lld.%09u\n",
> > + sample_num, when, sec, nsec);
> > + break;
> > + case CLOCK_MONOTONIC_RAW:
> > + printf("sample #%2d: monotonic-raw time %s: %lld.%09u\n",
> > + sample_num, when, sec, nsec);
> > + break;
>
> These three printfs are also kind of duplicated, I think mapping the
> clockid to name first would save a few lines.
Done in v5 - map the clockid to a name and print once.
^ permalink raw reply
* Re: [PATCH v4 net-next 1/7] ptp: Add ioctls for PHC timestamps with quality attributes
From: Arthur Kiyanovski @ 2026-07-17 7:18 UTC (permalink / raw)
To: saeed bishara
Cc: Arthur Kiyanovski, David Miller, Jakub Kicinski, netdev,
Richard Cochran, Eric Dumazet, Paolo Abeni, David Woodhouse,
Thomas Gleixner, Miroslav Lichvar, Andrew Lunn, Wen Gu, Xuan Zhuo,
David Woodhouse, Yonatan Sarna, Zorik Machulsky,
Alexander Matushevsky, Saeed Bshara, Matt Wilson, Anthony Liguori,
Nafea Bshara, Evgeny Schmeilin, Netanel Belgazal, Ali Saidi,
Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
vadim.fedorenko
In-Reply-To: <CAHfVqdWBsBMqerM7mq3U0fMKhCSMUd3nbNFi1vgFehRivG5B0w@mail.gmail.com>
On 2026-07-16 14:22:19+03:00, saeed bishara wrote:
> On Tue, Jul 14, 2026 at 5:06 AM Arthur Kiyanovski <akiyano@amazon.com> wrote:
>
> > + n_samples = data->request.num_samples;
> > + sts.clockid = data->request.clock_id;
> > + kfree(data);
> > + data = kzalloc(struct_size(data, timestamps, n_samples), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
>
> any idea why you free then allocate back?
>
> > --- a/include/linux/ptp_clock_kernel.h
> > +++ b/include/linux/ptp_clock_kernel.h
> > @@ -123,11 +123,34 @@ struct ptp_system_timestamp {
> > * reading the lowest bits of the PHC timestamp and the second
> > * reading immediately follows that.
> > *
> > + * @gettimexattrs64: Reads the current time from the hardware clock and
> > + * optionally also the system clock with additional clock
> > + * attributes.
> > + * parameter ts: Holds the PHC timestamp.
> > + * parameter sts: If not NULL, it holds a pair of
> > + * timestamps from the system clock. The first reading is
> > + * made right before reading the lowest bits of the PHC
> > + * timestamp and the second reading immediately follows that.
>
> The descriptions for ts and sts here are identical to gettimex64.
> Instead of duplicating this text, could we just refer back to the
> gettimex64 documentation?
Thanks. Both addressed in v5: ptp_sys_offset_{extended,precise}_attrs()
now copy the request header onto the stack and allocate the result
buffer once (no free + re-alloc), and the gettimexattrs64 /
getcrosststampattrs kernel-doc now references the base callbacks
instead of duplicating the text.
^ permalink raw reply
* [PATCH v5 net-next 7/7] net: ena: Implement gettimexattrs64 callback for PTP attributes
From: Arthur Kiyanovski @ 2026-07-17 7:09 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, netdev
Cc: Arthur Kiyanovski, Richard Cochran, Eric Dumazet, Paolo Abeni,
David Woodhouse, Thomas Gleixner, Miroslav Lichvar, Andrew Lunn,
Wen Gu, Xuan Zhuo, David Woodhouse, Yonatan Sarna,
Zorik Machulsky, Alexander Matushevsky, Saeed Bshara, Matt Wilson,
Anthony Liguori, Nafea Bshara, Evgeny Schmeilin, Netanel Belgazal,
Ali Saidi, Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
Bjorn Helgaas, vadim.fedorenko
In-Reply-To: <20260717070936.10718-1-akiyano@amazon.com>
Implement the gettimexattrs64 callback in the ENA driver to support
the PTP_SYS_OFFSET_EXTENDED_ATTRS ioctl.
This enables applications to retrieve PHC timestamps with quality
attributes through the standard PTP ioctl interface.
The ENA device currently reports only error_bound (valid bit set).
Other attributes are not reported (valid bits unset).
Signed-off-by: Amit Bernstein <amitbern@amazon.com>
Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
---
drivers/net/ethernet/amazon/ena/ena_phc.c | 58 +++++++++++++++++++----
1 file changed, 48 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_phc.c b/drivers/net/ethernet/amazon/ena/ena_phc.c
index 2bcb5af564e2..725c36fe3f6e 100644
--- a/drivers/net/ethernet/amazon/ena/ena_phc.c
+++ b/drivers/net/ethernet/amazon/ena/ena_phc.c
@@ -25,6 +25,43 @@ static int ena_phc_feature_enable(struct ptp_clock_info *clock_info,
return -EOPNOTSUPP;
}
+static int ena_phc_gettimexattrs64(struct ptp_clock_info *clock_info,
+ struct timespec64 *ts,
+ struct ptp_system_timestamp *sts,
+ struct ptp_clock_attrs *att)
+{
+ struct ena_phc_info *phc_info =
+ container_of(clock_info, struct ena_phc_info, clock_info);
+ u32 error_bound_nsec;
+ unsigned long flags;
+ u64 timestamp_nsec;
+ int rc;
+
+ spin_lock_irqsave(&phc_info->lock, flags);
+
+ ptp_read_system_prets(sts);
+
+ rc = ena_com_phc_get_timestamp(phc_info->adapter->ena_dev,
+ ×tamp_nsec,
+ &error_bound_nsec);
+
+ ptp_read_system_postts(sts);
+
+ spin_unlock_irqrestore(&phc_info->lock, flags);
+
+ if (rc)
+ return rc;
+
+ *ts = ns_to_timespec64(timestamp_nsec);
+
+ if (att) {
+ att->error_bound = error_bound_nsec;
+ att->valid |= PTP_ATTRS_VALID_ERROR_BOUND;
+ }
+
+ return 0;
+}
+
static int ena_phc_gettimex64(struct ptp_clock_info *clock_info,
struct timespec64 *ts,
struct ptp_system_timestamp *sts)
@@ -62,16 +99,17 @@ static int ena_phc_settime64(struct ptp_clock_info *clock_info,
}
static struct ptp_clock_info ena_ptp_clock_info = {
- .owner = THIS_MODULE,
- .n_alarm = 0,
- .n_ext_ts = 0,
- .n_per_out = 0,
- .pps = 0,
- .adjtime = ena_phc_adjtime,
- .adjfine = ena_phc_adjfine,
- .gettimex64 = ena_phc_gettimex64,
- .settime64 = ena_phc_settime64,
- .enable = ena_phc_feature_enable,
+ .owner = THIS_MODULE,
+ .n_alarm = 0,
+ .n_ext_ts = 0,
+ .n_per_out = 0,
+ .pps = 0,
+ .adjtime = ena_phc_adjtime,
+ .adjfine = ena_phc_adjfine,
+ .gettimexattrs64 = ena_phc_gettimexattrs64,
+ .gettimex64 = ena_phc_gettimex64,
+ .settime64 = ena_phc_settime64,
+ .enable = ena_phc_feature_enable,
};
/* Enable/Disable PHC by the kernel, affects on the next init flow */
--
2.47.3
^ permalink raw reply related
* [PATCH v5 net-next 6/7] net: ena: Add error bound to PHC communication layer
From: Arthur Kiyanovski @ 2026-07-17 7:09 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, netdev
Cc: Arthur Kiyanovski, Richard Cochran, Eric Dumazet, Paolo Abeni,
David Woodhouse, Thomas Gleixner, Miroslav Lichvar, Andrew Lunn,
Wen Gu, Xuan Zhuo, David Woodhouse, Yonatan Sarna,
Zorik Machulsky, Alexander Matushevsky, Saeed Bshara, Matt Wilson,
Anthony Liguori, Nafea Bshara, Evgeny Schmeilin, Netanel Belgazal,
Ali Saidi, Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
Bjorn Helgaas, vadim.fedorenko
In-Reply-To: <20260717070936.10718-1-akiyano@amazon.com>
Extend the ENA PHC communication layer to retrieve error bound from
the device.
Update ena_com_phc_get_timestamp() to retrieve error_bound alongside
timestamps.
Add error handling and statistics for error_bound retrieval failures.
Signed-off-by: Amit Bernstein <amitbern@amazon.com>
Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
---
.../device_drivers/ethernet/amazon/ena.rst | 2 +
drivers/net/ethernet/amazon/ena/ena_com.c | 40 ++++++++++++-------
drivers/net/ethernet/amazon/ena/ena_com.h | 5 ++-
drivers/net/ethernet/amazon/ena/ena_debugfs.c | 3 ++
drivers/net/ethernet/amazon/ena/ena_phc.c | 3 +-
5 files changed, 36 insertions(+), 17 deletions(-)
diff --git a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst
index 14784a0a6a8a..ce9ba84bfd01 100644
--- a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst
+++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst
@@ -306,6 +306,8 @@ PHC errors must remain below 1% of all PHC requests to maintain the desired leve
**phc_err_dv** | Number of failed get time attempts due to device errors (entering into block state).
**phc_err_ts** | Number of failed get time attempts due to timestamp errors (entering into block state),
| This occurs if driver exceeded the request limit or device received an invalid timestamp.
+**phc_err_eb** | Number of failed get time attempts due to error bound errors (entering into block state),
+ | This occurs if device received an excessively high or invalid error bound.
================= ======================================================
PHC timeouts:
diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c b/drivers/net/ethernet/amazon/ena/ena_com.c
index 40d1fd64bc34..353cb88e880e 100644
--- a/drivers/net/ethernet/amazon/ena/ena_com.c
+++ b/drivers/net/ethernet/amazon/ena/ena_com.c
@@ -45,7 +45,8 @@
#define ENA_PHC_DEFAULT_EXPIRE_TIMEOUT_USEC 10
#define ENA_PHC_DEFAULT_BLOCK_TIMEOUT_USEC 1000
#define ENA_PHC_REQ_ID_OFFSET 0xDEAD
-#define ENA_PHC_ERROR_FLAGS (ENA_ADMIN_PHC_ERROR_FLAG_TIMESTAMP)
+#define ENA_PHC_ERROR_FLAGS (ENA_ADMIN_PHC_ERROR_FLAG_TIMESTAMP | \
+ ENA_ADMIN_PHC_ERROR_FLAG_ERROR_BOUND)
/*****************************************************************************/
/*****************************************************************************/
@@ -1726,7 +1727,7 @@ int ena_com_phc_config(struct ena_com_dev *ena_dev)
if (phc->expire_timeout_usec > phc->block_timeout_usec)
phc->expire_timeout_usec = phc->block_timeout_usec;
- /* Prepare PHC feature command */
+ /* Prepare PHC config feature command */
memset(&set_feat_cmd, 0x0, sizeof(set_feat_cmd));
set_feat_cmd.aq_common_descriptor.opcode = ENA_ADMIN_SET_FEATURE;
set_feat_cmd.feat_common.feature_id = ENA_ADMIN_PHC_CONFIG;
@@ -1781,7 +1782,8 @@ void ena_com_phc_destroy(struct ena_com_dev *ena_dev)
phc->virt_addr = NULL;
}
-int ena_com_phc_get_timestamp(struct ena_com_dev *ena_dev, u64 *timestamp)
+int ena_com_phc_get_timestamp(struct ena_com_dev *ena_dev, u64 *timestamp,
+ u32 *error_bound)
{
const ktime_t zero_system_time = ktime_set(0, 0);
struct ena_com_phc_info *phc = &ena_dev->phc;
@@ -1828,6 +1830,8 @@ int ena_com_phc_get_timestamp(struct ena_com_dev *ena_dev, u64 *timestamp)
* a PHC error, this occurs if device:
* - exceeded the get time request limit
* - received an invalid timestamp
+ * - received an excessively high error bound
+ * - received an invalid error bound
*/
netdev_err(ena_dev->net_device,
"PHC get time request 0x%x failed (error 0x%x)\n",
@@ -1835,9 +1839,11 @@ int ena_com_phc_get_timestamp(struct ena_com_dev *ena_dev, u64 *timestamp)
resp->error_flags);
phc->stats.phc_err_ts += !!(resp->error_flags &
ENA_ADMIN_PHC_ERROR_FLAG_TIMESTAMP);
+ phc->stats.phc_err_eb += !!(resp->error_flags &
+ ENA_ADMIN_PHC_ERROR_FLAG_ERROR_BOUND);
} else {
/* Device updated req_id during blocking time
- * with valid timestamp
+ * with valid timestamp and error bound
*/
phc->stats.phc_exp++;
}
@@ -1864,9 +1870,9 @@ int ena_com_phc_get_timestamp(struct ena_com_dev *ena_dev, u64 *timestamp)
/* Stalling until the device updates req_id */
while (1) {
if (unlikely(ktime_after(ktime_get(), expire_time))) {
- /* Gave up waiting for updated req_id, PHC enters into
- * blocked state until passing blocking time,
- * during this time any get PHC timestamp will fail with
+ /* Gave up waiting for updated req_id,
+ * PHC enters into blocked state until passing blocking
+ * time, during this time, any request will fail with
* device busy error
*/
ret = -EBUSY;
@@ -1881,20 +1887,21 @@ int ena_com_phc_get_timestamp(struct ena_com_dev *ena_dev, u64 *timestamp)
continue;
}
- /* Ensure PHC payload (timestamp, error_flags) is read
- * after req_id update is observed
+ /* Ensure PHC payload (timestamp, error_bound, error_flags)
+ * is read after req_id update is observed
*/
dma_rmb();
/* req_id was updated by the device which indicates that
- * PHC timestamp and error_flags are updated too,
- * checking errors before retrieving timestamp
+ * PHC timestamp, error_bound and error_flags are updated too,
+ * checking error flags before retrieving timestamp and
+ * error_bound values
*/
if (unlikely(resp->error_flags & ENA_PHC_ERROR_FLAGS)) {
- /* Retrieved invalid PHC timestamp, PHC enters into
- * blocked state until passing blocking time,
- * during this time any get PHC timestamp requests
- * will fail with device busy error
+ /* Retrieved timestamp or error bound errors,
+ * PHC enters into blocked state until passing blocking
+ * time, during this time, any request will fail with
+ * device busy error
*/
ret = -EBUSY;
break;
@@ -1902,12 +1909,15 @@ int ena_com_phc_get_timestamp(struct ena_com_dev *ena_dev, u64 *timestamp)
/* PHC timestamp value is returned to the caller */
*timestamp = resp->timestamp;
+ if (error_bound)
+ *error_bound = resp->error_bound;
/* Update statistic on valid PHC timestamp retrieval */
phc->stats.phc_cnt++;
/* This indicates PHC state is active */
phc->system_time = zero_system_time;
+
break;
}
diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h b/drivers/net/ethernet/amazon/ena/ena_com.h
index 64df2c48c9a6..fcbff1a9eb7a 100644
--- a/drivers/net/ethernet/amazon/ena/ena_com.h
+++ b/drivers/net/ethernet/amazon/ena/ena_com.h
@@ -216,6 +216,7 @@ struct ena_com_stats_phc {
u64 phc_skp;
u64 phc_err_dv;
u64 phc_err_ts;
+ u64 phc_err_eb;
};
struct ena_com_admin_queue {
@@ -462,9 +463,11 @@ void ena_com_phc_destroy(struct ena_com_dev *ena_dev);
/* ena_com_phc_get_timestamp - Retrieve PHC timestamp
* @ena_dev: ENA communication layer struct
* @timestamp: Retrieved PHC timestamp
+ * @error_bound: maximum possible deviation of the timestamp (nanosecond)
* @return - 0 on success, negative value on failure
*/
-int ena_com_phc_get_timestamp(struct ena_com_dev *ena_dev, u64 *timestamp);
+int ena_com_phc_get_timestamp(struct ena_com_dev *ena_dev, u64 *timestamp,
+ u32 *error_bound);
/* ena_com_set_mmio_read_mode - Enable/disable the indirect mmio reg read mechanism
* @ena_dev: ENA communication layer struct
diff --git a/drivers/net/ethernet/amazon/ena/ena_debugfs.c b/drivers/net/ethernet/amazon/ena/ena_debugfs.c
index 46ed80986724..db9d1843996b 100644
--- a/drivers/net/ethernet/amazon/ena/ena_debugfs.c
+++ b/drivers/net/ethernet/amazon/ena/ena_debugfs.c
@@ -32,6 +32,9 @@ static int phc_stats_show(struct seq_file *file, void *priv)
seq_printf(file,
"phc_err_ts: %llu\n",
adapter->ena_dev->phc.stats.phc_err_ts);
+ seq_printf(file,
+ "phc_err_eb: %llu\n",
+ adapter->ena_dev->phc.stats.phc_err_eb);
return 0;
}
diff --git a/drivers/net/ethernet/amazon/ena/ena_phc.c b/drivers/net/ethernet/amazon/ena/ena_phc.c
index c2a3ff1ef645..2bcb5af564e2 100644
--- a/drivers/net/ethernet/amazon/ena/ena_phc.c
+++ b/drivers/net/ethernet/amazon/ena/ena_phc.c
@@ -40,7 +40,8 @@ static int ena_phc_gettimex64(struct ptp_clock_info *clock_info,
ptp_read_system_prets(sts);
rc = ena_com_phc_get_timestamp(phc_info->adapter->ena_dev,
- ×tamp_nsec);
+ ×tamp_nsec,
+ NULL);
ptp_read_system_postts(sts);
--
2.47.3
^ permalink raw reply related
* [PATCH v5 net-next 5/7] net: ena: Update PHC admin interface for error bound support
From: Arthur Kiyanovski @ 2026-07-17 7:09 UTC (permalink / raw)
To: David Miller, Jakub Kicinski, netdev
Cc: Arthur Kiyanovski, Richard Cochran, Eric Dumazet, Paolo Abeni,
David Woodhouse, Thomas Gleixner, Miroslav Lichvar, Andrew Lunn,
Wen Gu, Xuan Zhuo, David Woodhouse, Yonatan Sarna,
Zorik Machulsky, Alexander Matushevsky, Saeed Bshara, Matt Wilson,
Anthony Liguori, Nafea Bshara, Evgeny Schmeilin, Netanel Belgazal,
Ali Saidi, Benjamin Herrenschmidt, Noam Dagan, David Arinzon,
Evgeny Ostrovsky, Ofir Tabachnik, Amit Bernstein, linux-kselftest,
linux-doc, shuah, Jonathan Corbet, Shuah Khan, Simon Horman,
Bjorn Helgaas, vadim.fedorenko
In-Reply-To: <20260717065924.2556-1-akiyano@amazon.com>
Extend the ENA admin interface to support error bound.
Add error_bound to the PHC response structure.
Introduce a feature version mechanism to indicate device supports
error_bound, and add an error flag for error_bound retrieval failures.
This enables the driver to retrieve error_bound information from the
device alongside timestamps.
Signed-off-by: Amit Bernstein <amitbern@amazon.com>
Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
---
.../net/ethernet/amazon/ena/ena_admin_defs.h | 17 +++++++++++------
drivers/net/ethernet/amazon/ena/ena_com.c | 11 ++++++-----
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/amazon/ena/ena_admin_defs.h b/drivers/net/ethernet/amazon/ena/ena_admin_defs.h
index 898ecd96b96a..2d132c4bc590 100644
--- a/drivers/net/ethernet/amazon/ena/ena_admin_defs.h
+++ b/drivers/net/ethernet/amazon/ena/ena_admin_defs.h
@@ -128,12 +128,14 @@ enum ena_admin_get_stats_scope {
ENA_ADMIN_ETH_TRAFFIC = 1,
};
-enum ena_admin_phc_type {
- ENA_ADMIN_PHC_TYPE_READLESS = 0,
+enum ena_admin_phc_feature_version {
+ /* Readless with error_bound */
+ ENA_ADMIN_PHC_FEATURE_VERSION_0 = 0,
};
enum ena_admin_phc_error_flags {
ENA_ADMIN_PHC_ERROR_FLAG_TIMESTAMP = BIT(0),
+ ENA_ADMIN_PHC_ERROR_FLAG_ERROR_BOUND = BIT(1),
};
/* ENA SRD configuration for ENI */
@@ -1035,10 +1037,10 @@ struct ena_admin_queue_ext_feature_desc {
};
struct ena_admin_feature_phc_desc {
- /* PHC type as defined in enum ena_admin_get_phc_type,
- * used only for GET command.
+ /* PHC version as defined in enum ena_admin_phc_feature_version,
+ * used only for GET command as max supported PHC version by the device.
*/
- u8 type;
+ u8 version;
/* Reserved - MBZ */
u8 reserved1[3];
@@ -1224,7 +1226,10 @@ struct ena_admin_phc_resp {
/* PHC timestamp (nsec) */
u64 timestamp;
- u8 reserved2[12];
+ u8 reserved2[8];
+
+ /* Timestamp error limit (nsec) */
+ u32 error_bound;
/* Bit field of enum ena_admin_phc_error_flags */
u32 error_flags;
diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c b/drivers/net/ethernet/amazon/ena/ena_com.c
index 297fb36ab8c1..40d1fd64bc34 100644
--- a/drivers/net/ethernet/amazon/ena/ena_com.c
+++ b/drivers/net/ethernet/amazon/ena/ena_com.c
@@ -1682,11 +1682,11 @@ int ena_com_phc_config(struct ena_com_dev *ena_dev)
struct ena_admin_set_feat_cmd set_feat_cmd;
int ret = 0;
- /* Get device PHC default configuration */
+ /* Get default device PHC configuration */
ret = ena_com_get_feature(ena_dev,
&get_feat_resp,
ENA_ADMIN_PHC_CONFIG,
- 0);
+ ENA_ADMIN_PHC_FEATURE_VERSION_0);
if (unlikely(ret)) {
netdev_err(ena_dev->net_device,
"Failed to get PHC feature configuration, error: %d\n",
@@ -1694,10 +1694,11 @@ int ena_com_phc_config(struct ena_com_dev *ena_dev)
return ret;
}
- /* Supporting only readless PHC retrieval */
- if (get_feat_resp.u.phc.type != ENA_ADMIN_PHC_TYPE_READLESS) {
+ /* Supporting only PHC V0 (readless mode with error bound) */
+ if (get_feat_resp.u.phc.version != ENA_ADMIN_PHC_FEATURE_VERSION_0) {
netdev_err(ena_dev->net_device,
- "Unsupported PHC type, error: %d\n",
+ "Unsupported PHC version (0x%X), error: %d\n",
+ get_feat_resp.u.phc.version,
-EOPNOTSUPP);
return -EOPNOTSUPP;
}
--
2.47.3
^ permalink raw reply related
* RE: [RFC PATCH 06/10] net: pcs: xpcs: improve SGMII AN state handling for Rockchip RK3568
From: Jiawen Wu @ 2026-07-17 7:03 UTC (permalink / raw)
To: 'Coia Prant'
Cc: 'Andrew Lunn', kuba, davem, edumazet, pabeni,
andrew+netdev, robh, krzk+dt, heiko, netdev, linux-rockchip,
devicetree, linux-arm-kernel, linux-phy, 'Mengyuan Lou'
In-Reply-To: <CALj3r0hH=mF+8oVbisoECYo6HRuSdfSt_nuhFunHowyPsw2srQ@mail.gmail.com>
On Fri, Jul 17, 2026 2:29 PM, Coia Prant wrote:
> Jiawen Wu <jiawenwu@trustnetic.com> 于2026年7月17日周五 10:23写道：
> >
> > On Wed, Jul 15, 2026 7:05 AM, Coia Prant wrote:
> > > Andrew Lunn <andrew@lunn.ch> 于2026年7月15日周三 06:44写道：
> > > >
> > > > On Wed, Jul 15, 2026 at 03:08:34AM +0800, Coia Prant wrote:
> > > > > Commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> > > >
> > > > You do not appear to Cc: the Wangxun NIC people. It would be good to
> > > > have there comments on this change.
> > >
> > > I apologize; the output from get_maintainer.pl is very long. I’ve
> > > heard that having too many recipients can cause the PATCH to be
> > > rejected by the LKML mail server.
> > >
> > > I have added Wangxun maintainer (Jiawen Wu <jiawenwu@trustnetic.com>
> > > and Mengyuan Lou <mengyuanlou@net-swift.com>) to the CC list.
> > >
> > > > > Fixes: 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> > > > > Signed-off-by: Coia Prant <coiaprant@gmail.com>
> > > >
> > > > Please don't mix fixed and new code. Is this a real fix? Should it be
> > > > back ported to stable?
> > >
> > > I am not sure if this is a specific characteristic of Wangxun NICs, as
> > > I do not have any available for testing.
> > >
> > > The behavior of the Rockchip DW XPCS IP core matches what is described
> > > in the commit message (even though phylink brings the link to down
> > > based on the phydev link status).
> > >
> > > This appears to be a bug (at least on Rockchip platforms) or Wangxun
> > > NICs features.
> > >
> > > However, I cannot confirm whether Wangxun NICs behave the same way.
> > > Therefore, I have kept their code as is for now.
> > >
> > > Could a Wangxun NICs maintainer provide some feedback based on testing?
> > >
> > > If we can confirm that this is indeed a bug, I can submit a separate fix.
> > >
> > > I would greatly appreciate it.
> > >
> > > Thanks.
> >
> > Hi Coia,
> >
> > I have tested this patch and it works on Wangxun NICs, thanks.
> >
> > The commit 2a22b7ae2fa3 ("net: pcs: xpcs: adapt Wangxun NICs for SGMII mode")
> > is too long ago for me to recall exactly what that thought was.
> >
> > The log shows:
> >
> > "On this device, CL37_ANSGM_STS (bit[4:1] of VR_MII_AN_INTR_STS) indicates
> > the status received from remote link during the auto-negotiation, and
> > self-clear after the auto-negotiation is complete.
> > Meanwhile, CL37_ANCMPLT_INTR will be set to 1, to indicate CL37 AN is
> > complete. So add another way to get the state for CL37 SGMII."
> >
> > I tried to reproduce this issue, but it didn't seem to exist.
> > In the current logic:
> >
> > link up -> read status from CL37_ANSGM_STS -> CL37_ANCMPLT_INTR not clear
> > link down -> read status from BMCR -> CL37_ANCMPLT_INTR clear
> >
> > It also works, although CL37_ANCMPLT_INTR is not cleared every time, and AN
> > restart is absent. But BMCR looks like it only wants to be return as 0, it is
> > weird.
> >
> > So I think Wangxun NICs also can be applied to general code as well, for
> > getting state in C37 SGMII mode.
>
> Hi Jiawen,
>
> Thanks so much for testing and confirming that the patch works on Wangxun
> NICs. That's a huge relief.
>
> You're right to ask about the CL37_ANCMPLT_INTR clear and ANRESTART. Let
> me explain what I observed on RK3568.
>
> The key difference is that on RK3568's XPCS, we're working in the MAC
> side (TX_CONFIG = 0), whereas on Wangxun it seems you're in the PHY side
> (TX_CONFIG = 1). This is based on the commit 2a22b7ae2fa3 where you set
> TX_CONFIG = 1.
Get it.
>
> > However, I am wondering whether CL37_ANCMPLT_INTR clear and ANRESTART are
> > necessary.
>
> On the RK3568 (MAC side), according to the DesignWare XPCS TRM, the
> hardware behavior is as follows:
>
> - After a software reset (BMCR_RESET), ANENABLE is automatically set to 1
> (the hardware reset value). So auto-negotiation starts automatically.
>
> - When the link is up, CL37_ANSGM_STS contains the negotiated speed/duplex
> and the link status.
>
> - When the link goes down, CL37_ANSGM_STS becomes all zero, but
> CL37_ANCMPLT_INTR remains set to 1.
>
> - Crucially, the PCS does **not** automatically restart AN when the link
> comes back up. Without an explicit ANRESTART, the link stays down
> forever.
>
> So on RK3568, the ANRESTART is mandatory to recover from a link-down
> event. Without it, the link never comes back up after a cable disconnect.
>
> In my current logic:
>
> 1. If CL37_ANSGM_STS has valid speed/duplex bits, report the link as up
> and return.
>
> 2. If CL37_ANSGM_STS is zero but CL37_ANCMPLT_INTR is set, the link is
> down. We clear the interrupt and issue an ANRESTART to start a new
> negotiation.
>
> This works reliably on RK3568 in SGMII MAC side mode.
>
> Since you confirmed that the general code path also works on Wangxun, I
> wonder: does the ANRESTART also work on your side? If yes, perhaps we can
> make this the common path for all hardware, not just RK3568.
>
> If you can test the ANRESTART logic on Wangxun and it works, I'd be happy
> to submit a standalone fix that makes this the common code path.
I've test this patch with removing the restriction on Wangxun PMA. At least
ANRESTART logic does not have a negative impact.
>
> Otherwise, the current approach (skipping the ANRESTART trigger on
> Wangxun NICs in c37_sgmii_get_state) remains safe.
>
> If you're comfortable with the change, I'd appreciate it if you could add
> your Tested-by tag to the commit. I'll also make sure to include you on
> the CC list for any future revisions or related fixes.
>
> Thanks again for testing!
Thanks for the improvements.
Tested-by: Jiawen Wu <jiawenwu@trustnetic.com>
^ permalink raw reply
* RE: [PATCH] tty: ldisc: fix deadlock between ldisc_sem and rtnl_mutex
From: Jagielski, Jedrzej @ 2026-07-17 7:02 UTC (permalink / raw)
To: Zhou, Yun, gregkh@linuxfoundation.org, jirislaby@kernel.org,
socketcan@hartkopp.net, sdf.kernel@gmail.com
Cc: linux-serial@vger.kernel.org, mkl@pengutronix.de,
linux-can@vger.kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <70f854e7-b066-4f30-8ebf-71abdece45c2@windriver.com>
From: Zhou, Yun <yun.zhou@windriver.com>
Sent: Friday, July 17, 2026 5:42 AM
>>> + tty_ldisc_unlock(tty);
>>>
>>> + /*
>>
>> this blank line is redundant i believe
>>
>
>Isn't it common practice to leave the first line of a multi-line comment
>blank? Does it violate the coding style guidelines?
>
>BR,
>Yun
First line of the comment unlike the last don't have to be necessarily
blank and indeed usually it is not for new code, it’s rather obsolete practice.
But that's only suggestion.
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: dwmac-rk: enable the reference clock for output mode
From: Jiaxing Hu @ 2026-07-17 7:00 UTC (permalink / raw)
To: maxime.chevallier
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, heiko, netdev,
linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <a1e6cf0a-a243-4739-8563-be385add37b2@bootlin.com>
Hi Maxime,
> So the statement "For RGMII, it must be input [...]" is now incorrect :
> - it can be output for RGMII
> - it will be 25Hz if set to output, from what I get from the commit log.
>
> Can you update it ?
Done in v2, added as patch 1:
https://lore.kernel.org/all/20260717065933.2629501-1-gahing@gahingwoo.com/
It rewords clock_in_out so that for RGMII, "output" means the SoC drives
a 25 MHz reference out to a crystal-less PHY. The driver change is now
patch 2 of the same series.
Thanks,
Jiaxing
^ 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