[PATCH net-next v7 0/3] net: stmmac: dwxgmac2: timestamp interrupt support + Agilex5 fix

zhu xin zxyan0222 at gmail.com
Sun Oct 4 05:22:27 PDT 2026


On Sun, Oct 4, 2026 at 8:08 PM <netdev-bot+sinfo at kernel.org> wrote:
>
> Hi!
>
> This is an automated message. This series looks like a fix, but its
> commit messages seem to be missing some information:
>
>  - How the issue was discovered, e.g. hit in production, hit during
>    development, syzbot report, manual code inspection, LLM or static
>    analysis tool scan.
>

- How discovered: Patch 1 and Patch 2 were found by code inspection
  during review.  Patch 3 was found during development testing on a
  local DWXGMAC2 board: the PTP clock advertised the aux snapshot
  channels and PTP_EXTTS_REQUEST succeeded, but no PTP_CLOCK_EXTTS
  event ever arrived - inspection then showed the XGMAC hwif pointed
  at the generic stmmac_ptp ops, which read the dwmac4 offset instead
  of the XGMAC register.

>  - Whether the issue was actually triggered, or is only theoretical
>    (e.g. found by code inspection). If it was triggered please include
>    the symptoms, like the stack trace or error messages.
>

- Actually triggered: the EXTTS failure of Patch 3 was hit on real
  hardware as described above.  The races fixed by Patch 1 and the
  OOB index of Patch 2 were found by inspection and have not been
  observed in isolation.

>  - What hardware the change was tested on. For driver fixes please
>    mention the device (and if relevant firmware version) used for
>    testing, or say that the change was not tested on real hardware.
>

- Tested on: local DWXGMAC2 hardware (not Agilex5), for the Patch EXTTS
  issue and basic PTP operation. Agilex5 has not been tested locally.

> Please do not repost the series just to address the above. Instead,
> reply to this email with the missing information, so that reviewers
> can take it into account. If the series needs another revision for
> other reasons, please include the information in the commit messages
> then.
>
> The evaluation is done by an LLM so it may be wrong, if you think
> that is the case please reply and explain.



More information about the linux-arm-kernel mailing list