[PATCH net] octeontx2-pf: Fix ethtool timestamping capabilities for SDP representors

Subsystems: marvell octeontx2 physical function driver, networking drivers, the rest

COLD16d

2 messages, 2 authors, 16d ago · open the first message on its own page

[PATCH net] octeontx2-pf: Fix ethtool timestamping capabilities for SDP representors

From: <hidden>
Date: 2026-08-20 17:23:35

From: Roy Franz <redacted>

SDP representors do not support hardware timestamping. The current
implementation of otx2_get_ts_info incorrectly advertises hardware
timestamping capabilities and a PHC index to userspace for these
interfaces.

Fix this by checking if the device is an SDP representor and returning
the default software timestamping capabilities instead.

Fixes: 2f7f33a09516 ("octeontx2-pf: Add representors for sdp MAC")
Signed-off-by: Nitin Shetty J <redacted>
Signed-off-by: Roy Franz <redacted>
---
 drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
index a0340f3422bf..f7a2202c4a3e 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
@@ -978,7 +978,7 @@ static int otx2_get_ts_info(struct net_device *netdev,
 {
 	struct otx2_nic *pfvf = netdev_priv(netdev);
 
-	if (!pfvf->ptp)
+	if (!pfvf->ptp || is_otx2_sdp_rep(pfvf->pdev))
 		return ethtool_op_get_ts_info(netdev, info);
 
 	info->so_timestamping = SOF_TIMESTAMPING_TX_SOFTWARE |
-- 
2.48.1

Re: [PATCH net] octeontx2-pf: Fix ethtool timestamping capabilities for SDP representors

From: Jakub Kicinski <kuba@kernel.org>
Date: 2026-08-22 20:53:09

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
octeontx2-pf: Fix ethtool timestamping capabilities for SDP representors

The patch makes otx2_get_ts_info() fall back to
ethtool_op_get_ts_info() for SDP representors, so ethtool -T reports
software timestamping only and phc_index = -1 for those interfaces.
quoted hunk
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
index a0340f3422bf9..f7a2202c4a3e0 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_ethtool.c
@@ -978,7 +978,7 @@ static int otx2_get_ts_info(struct net_device *netdev,
 {
 	struct otx2_nic *pfvf = netdev_priv(netdev);
 
-	if (!pfvf->ptp)
+	if (!pfvf->ptp || is_otx2_sdp_rep(pfvf->pdev))
 		return ethtool_op_get_ts_info(netdev, info);
[Severity: Medium]
Accepting hardware timestamping on SDP representors isn't a bug
introduced by this patch, but should the configuration path be closed
too, so the advertised capabilities and the set path agree?

otx2_config_hwtstamp_set() in otx2_pf.c is registered as
.ndo_hwtstamp_set in otx2vf_netdev_ops, which SDP representors use
(PCI_DEVID_OCTEONTX2_SDP_REP is in otx2_vf_id_table), and its only
guard is the pointer check:

drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c:otx2_config_hwtstamp_set() {
	struct otx2_nic *pfvf = netdev_priv(netdev);

	if (!pfvf->ptp)
		return -ENODEV;

	switch (config->tx_type) {
	...
}

pfvf->ptp is non-NULL for SDP representors, since otx2vf_probe() calls
otx2_ptp_init(vf) unconditionally and otx2_ptp_init() only clears the
pointer for LBK VFs:

drivers/net/ethernet/marvell/octeontx2/nic/otx2_ptp.c:otx2_ptp_init() {
	if (is_otx2_lbkvf(pfvf->pdev)) {
		pfvf->ptp = NULL;
		return 0;
	}
	...
}

The SIOCSHWTSTAMP path only range-checks the request in
net_hwtstamp_validate() and never consults get_ts_info, so
HWTSTAMP_TX_ON / HWTSTAMP_FILTER_ALL is still accepted on an interface
that ethtool -T now reports as software-only, and
otx2_config_hwtstamp_get() reports that hardware mode back from
pfvf->tstamp.

On the TX side, does anything actually get programmed? The AF handler
rvu_mbox_handler_nix_lf_ptp_tx_enable() -> rvu_nix_lf_ptp_tx_cfg()
returns success without writing NIX_AF_LFX_TX_CFG_PTP_EN for a
non-CGX-mapped (SDP) PF:

drivers/net/ethernet/marvell/octeontx2/af/rvu_nix.c:rvu_nix_lf_ptp_tx_cfg() {
	if (!is_mac_feature_supported(rvu, pf, RVU_LMAC_FEAT_PTP))
		return 0;
	...
}

So OTX2_FLAG_TX_TSTAMP_ENABLED gets set and otx2_set_txtstamp() starts
marking skbs SKBTX_IN_PROGRESS and appending the
NIX_SENDMEMALG_E_SETTSTMP MEM subdesc while the LF was never enabled
for PTP.

The RX half does not appear to be affected: rvu_mbox_handler_cgx_ptp_rx_enable()
returns -EPERM for a non-CGX-mapped PF, so OTX2_FLAG_RX_TSTAMP_ENABLED
stays clear.

Would it be simpler to mirror the existing LBK handling in
otx2_ptp_init() and also set pfvf->ptp = NULL for is_otx2_sdp_rep()?
That covers otx2_get_ts_info(), otx2_config_hwtstamp_set() and avoids
registering a PHC that the patch now hides with phc_index = -1 while it
remains reachable as /dev/ptpN.

Cross-instance finding from sashiko-gemini (5b35a8e8292d6d592200e0103dea956967dd21185968d0440290af6d0ae99293):
[Severity: Medium]
Incomplete fix for SDP representor hardware timestamping allows ioctl configuration and useless PTP clock registration.
-- 
pw-bot: cr
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help