public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: "Bastien Curutchet (Schneider Electric)" <bastien.curutchet@bootlin.com>
Cc: "Woojung Huh" <woojung.huh@microchip.com>,
	UNGLinuxDriver@microchip.com, "Andrew Lunn" <andrew@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Richard Cochran" <richardcochran@gmail.com>,
	"Simon Horman" <horms@kernel.org>,
	"Pascal Eberhard" <pascal.eberhard@se.com>,
	"Miquèl Raynal" <miquel.raynal@bootlin.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v4 8/8] net: dsa: microchip: Add two-step PTP support for KSZ8463
Date: Mon, 2 Feb 2026 15:43:30 +0200	[thread overview]
Message-ID: <20260202134330.xzc2wmcwwqhw4dfc@skbuf> (raw)
In-Reply-To: <20260127-ksz8463-ptp-v4-8-652e021aae86@bootlin.com> <20260127-ksz8463-ptp-v4-8-652e021aae86@bootlin.com>

On Tue, Jan 27, 2026 at 10:06:50AM +0100, Bastien Curutchet (Schneider Electric) wrote:
> The KSZ8463 switch supports PTP but it's not supported by driver.
> 
> Add L2 two-step PTP support for the KSZ8463. IPv4 and IPv6 layers aren't
> supported. Neither is one-step PTP.
> 
> The pdelay_req and pdelay_resp timestamps share one interrupt bit status.
> So introduce last_tx_is_pdelayresp to keep track of the last sent event
> type. Use it to retrieve the relevant timestamp when the interrupt is
> caught.
> 
> Signed-off-by: Bastien Curutchet (Schneider Electric) <bastien.curutchet@bootlin.com>
> ---
> @@ -518,6 +535,8 @@ void ksz_port_txtstamp(struct dsa_switch *ds, int port, struct sk_buff *skb)
>  	if (!hdr)
>  		return;
>  
> +	prt->last_tx_is_pdelayresp = false;
> +
>  	ptp_msg_type = ptp_get_msgtype(hdr, type);
>  
>  	switch (ptp_msg_type) {
> @@ -528,6 +547,7 @@ void ksz_port_txtstamp(struct dsa_switch *ds, int port, struct sk_buff *skb)
>  	case PTP_MSGTYPE_PDELAY_REQ:
>  		break;
>  	case PTP_MSGTYPE_PDELAY_RESP:
> +		prt->last_tx_is_pdelayresp = true;
>  		if (prt->tstamp_config.tx_type == HWTSTAMP_TX_ONESTEP_P2P) {
>  			KSZ_SKB_CB(skb)->ptp_type = type;
>  			KSZ_SKB_CB(skb)->update_correction = true;
> @@ -972,7 +992,17 @@ void ksz_ptp_clock_unregister(struct dsa_switch *ds)
>  
>  static int ksz_read_ts(struct ksz_port *port, u16 reg, u32 *ts)
>  {
> -	return ksz_read32(port->ksz_dev, reg, ts);
> +	u16 ts_reg = reg;
> +
> +	/**
> +	 * On KSZ8463 DREQ and DRESP timestamps share one interrupt line
> +	 * so we have to check the nature of the latest event sent to know
> +	 * where the timestamp is located
> +	 */
> +	if (ksz_is_ksz8463(port->ksz_dev) && port->last_tx_is_pdelayresp)
> +		ts_reg += KSZ8463_DRESP_TS_OFFSET;
> +
> +	return ksz_read32(port->ksz_dev, ts_reg, ts);
>  }

There is a race condition here.

ksz_port_txtstamp() is called "at line rate" - it doesn't wait for the
timestamping of the currently in progress skb to finish.

See the order in
static netdev_tx_t dsa_user_xmit(struct sk_buff *skb, struct net_device *dev)
{
	struct dsa_user_priv *p = netdev_priv(dev);
	struct sk_buff *nskb;

	dev_sw_netstats_tx_add(dev, 1, skb->len);

	memset(skb->cb, 0, sizeof(skb->cb));

	dsa_skb_tx_timestamp(p, skb); // calls ksz_port_txtstamp()

	...

	nskb = p->xmit(skb, dev); // calls ksz9893_xmit() -> ksz_defer_xmit()
	if (!nskb) {
		kfree_skb(skb); // deferred xmit enters this code path
		return NETDEV_TX_OK;
	}

	return dsa_enqueue_skb(nskb, dev);
}

The deferred worker gets scheduled much later, time during which a
second PTP packet may be transmitted from the stack.

If you let the second skb change the port->last_tx_is_pdelayresp which
ksz_ptp_msg_thread_fn() -> ksz_read_ts() thinks is associated with the
first skb, you're in big trouble.

You need to set port->last_tx_is_pdelayresp in the atomic section where
you know for sure that there's a single TX timestampable skb in flight.
There's no explicit lock which creates that atomic section, but the fact
that the worker kthread of the tagger processes work items one by one is
what gives you that guarantee.

  reply	other threads:[~2026-02-02 13:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27  9:06 [PATCH net-next v4 0/8] net: dsa: microchip: Add PTP support for the KSZ8463 Bastien Curutchet (Schneider Electric)
2026-01-27  9:06 ` [PATCH net-next v4 1/8] net: dsa: microchip: Add support for KSZ8463 global irq Bastien Curutchet (Schneider Electric)
2026-01-27 19:42   ` Maxime Chevallier
2026-01-28  3:03   ` Jakub Kicinski
2026-01-28  9:22     ` Bastien Curutchet
2026-01-27  9:06 ` [PATCH net-next v4 2/8] net: dsa: microchip: Decorrelate IRQ domain from port Bastien Curutchet (Schneider Electric)
2026-01-27  9:06 ` [PATCH net-next v4 3/8] net: dsa: microchip: Decorrelate msg_irq index from IRQ bit offset Bastien Curutchet (Schneider Electric)
2026-01-27  9:06 ` [PATCH net-next v4 4/8] net: dsa: microchip: Add support for KSZ8463's PTP interrupts Bastien Curutchet (Schneider Electric)
2026-01-27  9:06 ` [PATCH net-next v4 5/8] net: dsa: microchip: Add KSZ8463 tail tag handling Bastien Curutchet (Schneider Electric)
2026-01-30  4:15   ` Jakub Kicinski
2026-02-18  9:35     ` Bastien Curutchet
2026-02-02 13:29   ` Vladimir Oltean
2026-02-18  9:36     ` Bastien Curutchet
2026-01-27  9:06 ` [PATCH net-next v4 6/8] net: dsa: microchip: Enable Ethernet PTP detection Bastien Curutchet (Schneider Electric)
2026-01-30  4:17   ` Jakub Kicinski
2026-01-30  5:16     ` Tristram.Ha
2026-02-18 10:22       ` Bastien Curutchet
2026-01-27  9:06 ` [PATCH net-next v4 7/8] net: dsa: microchip: Adapt port offset for KSZ8463's PTP register Bastien Curutchet (Schneider Electric)
2026-01-27  9:06 ` [PATCH net-next v4 8/8] net: dsa: microchip: Add two-step PTP support for KSZ8463 Bastien Curutchet (Schneider Electric)
2026-02-02 13:43   ` Vladimir Oltean [this message]
2026-02-18 15:21     ` Bastien Curutchet
2026-02-18 15:25       ` Vladimir Oltean
2026-02-18 16:42         ` Bastien Curutchet
2026-02-18 16:47           ` Vladimir Oltean
2026-02-18 16:49             ` Bastien Curutchet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260202134330.xzc2wmcwwqhw4dfc@skbuf \
    --to=olteanv@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=bastien.curutchet@bootlin.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pascal.eberhard@se.com \
    --cc=richardcochran@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=woojung.huh@microchip.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox