Re: [PATCH RESEND net-next v2] net: stmmac: dwmac: Add a fixup for the Micrel KSZ9131 PHY

[Stefan Eichenberger <eichest@gmail.com>]

On Mon, Jan 05, 2026 at 05:09:13PM +0000, Russell King (Oracle) wrote:
> On Mon, Jan 05, 2026 at 05:42:23PM +0100, Stefan Eichenberger wrote:
> > Yes this is correct. ERR050694 from NXP states:
> > The IEEE 802.3 standard states that, in MII/GMII modes, the byte
> > preceding the SFD (0xD5), SMD-S (0xE6,0x4C, 0x7F, or 0xB3), or SMD-C
> > (0x61, 0x52, 0x9E, or 0x2A) byte can be a non-PREAMBLE byte or there can
> > be no preceding preamble byte. The MAC receiver must successfully
> > receive a packet without any preamble(0x55) byte preceding the SFD,
> > SMD-S, or SMD-C byte.
> > However due to the defect, in configurations where frame preemption is
> > enabled, when preamble byte does not precede the SFD, SMD-S, or SMD-C
> > byte, the received packet is discarded by the MAC receiver. This is
> > because, the start-of-packet detection logic of the MAC receiver
> > incorrectly checks for a preamble byte.
> > 
> > NXP refers to IEEE 802.3 where in clause 35.2.3.2.2 Receive case (GMII)
> > they show two tables one where the preamble is preceding the SFD and one
> > where it is not. The text says:
> > The operation of 1000 Mb/s PHYs can result in shrinkage of the preamble
> > between transmission at the source GMII and reception at the destination
> > GMII. Table 35–3 depicts the case where no preamble bytes are conveyed
> > across the GMII. This case may not be possible with a specific PHY, but
> > illustrates the minimum preamble with which MAC shall be able to
> > operate. Table 35–4 depicts the case where the entire preamble is
> > conveyed across the GMII.
> > 
> > We would change the behavior from "no preamble is preceding SFD" to "the
> > enitre preamble is preceding SFD". Both are listed in the standard and
> > shall be supported by the MAC.
> 
> Thanks for providing the full explanation, it would be good to have
> that in the commit message.

Okay thanks, I will provide the full explanation in the next commit
message.

> 
> The next question would be, is it just the NXP EQOS implementation
> that this breaks on, or are other EQOS implementations affected?
> 
> In other words, if we choose to conditionally enable the preable at
> the PHY, should the generic parts of stmmac handle this rather than
> ending up with multiple platform specific glue having to code this.
> (This is something I really want to avoid - it doesn't scale.)

From the errata from NXP it sounds to me like it is a configuration
issue by NXP. I checked the following ERRATAs from vendors where I have
access to:
- ST STM32MP1: not affected: https://www.st.com/resource/en/errata_sheet/es0438-stm32mp151x3x7x-device-errata-stmicroelectronics.pdf
- Renesas RZN1: not affected: https://www.renesas.com/en/document/tcu/ethernet-mac-gmac-function-issue-0?r=1054561
- Starvive JH7110: not affected: https://doc-en.rvspace.org/JH7110/PDF/JH7110_Errata.pdf
- NXP S32: affected: (ERR050706 under NDA)

So from that I would conclude that it is an NXP specific issue and it's
not the full EQOS implementation that is broken.

Regards,
Stefan