Re: [PATCH net-next v3 2/2] net: stmmac: dwmac-socfpga: mask XGMAC_TSIE during cross-timestamp

zhu xin <[email protected]>
Newsgroups gmane.linux.network,gmane.linux.ports.arm.kernel,gmane.linux.kernel
Message-ID <CAP7veT+OwAT15f==wqmKumZnc_Q12NYtS4fJFN9X1cTRm=+e0A@mail.gmail.com>
Hi, Andrew

On Tue, Aug 18, 2026 at 11:07 PM Andrew Lunn <[email protected]> wrote:
>
> On Tue, Aug 18, 2026 at 09:27:22PM +0800, Zxyan Zhu wrote:
> > The Agilex5 smtg_crosststamp() handler arms an internal auxiliary
> > snapshot, toggles GPO0 and then polls XGMAC_INT_STATUS for TSIS in
> > process context to learn that the snapshot is ready.
> >
> > Once XGMAC_TSIE is unmasked (done by a companion change that enables it
> > in XGMAC_INT_DEFAULT_EN), the DWXGMAC2 timestamp interrupt handler runs
> > from hardirq on every timestamp event and clears TSIS by reading
> > XGMAC_TIMESTAMP_STATUS.  That read can win the race against the poll
> > loop, which then times out and makes PTP_SYS_OFFSET_PRECISE fail with
> > "Wait for time sync operation timeout".
> >
> > Mask XGMAC_TSIE around the snapshot trigger and FIFO read so the hardirq
> > handler cannot clear TSIS while smtg_crosststamp() owns it, and restore
> > it on every return path.
>
> Did you look at the other system which implement crosststamp?
> dwmac-intel.c? Does it need similar changes?

Yes, I looked at dwmac-intel.c.  It does not need the same change.

intel_crosststamp() sets STMMAC_FLAG_INT_SNAPSHOT_EN and waits on
tstamp_busy_wait for the interrupt:

  priv->plat->flags |= STMMAC_FLAG_INT_SNAPSHOT_EN;
  ...
  wait_event_interruptible_timeout(priv->tstamp_busy_wait,
                                   stmmac_cross_ts_isr(priv), HZ / 100);

and the generic timestamp_interrupt() early-returns when that flag is
set:

  if (priv->plat->flags & STMMAC_FLAG_INT_SNAPSHOT_EN) {
          wake_up(&priv->tstamp_busy_wait);
          return;
  }

so the Intel handler never reads GMAC_TIMESTAMP_STATUS and does not
clear TSIS.  Intel is interrupt-driven, so it depends on TSIE being
enabled; masking it would break the wake-up.

socfpga is the odd one: it does not set INT_SNAPSHOT_EN, polls
XGMAC_INT_STATUS for TSIS in process context, and sits on
DWMAC_CORE_XGMAC -- the core type this series newly enables TSIE on.
So only socfpga needs the mask.

That said, the cleaner long-term fix is to align socfpga with the
Intel approach: set INT_SNAPSHOT_EN and wait_event instead of polling.
The trade-off:

  - Masking TSIE (this series): minimal, keeps the poll loop, but a
    local workaround for the XGMAC hardirq-vs-poll race only.
  - Intel pattern: no per-platform masking, similar across XGMAC and
    GMAC4; but a bigger rewrite -- stmmac_cross_ts_isr() reads
    GMAC_INT_STATUS (wrong offset for XGMAC), needing an XGMAC variant,
    and the poll becomes wait_event.

I went with the mask as the minimal regression fix, and can do the
Intel-style conversion as a separate follow-up if preferred.

Best regards,
Zxyan Zhu

>
>         Andrew
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.