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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aVv7wD2JFikGkt3F@eichest-laptop>
Date: Mon, 5 Jan 2026 18:58:24 +0100
From: Stefan Eichenberger <eichest@...il.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>,
	Maxime Chevallier <maxime.chevallier@...tlin.com>,
	andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, shawnguo@...nel.org,
	s.hauer@...gutronix.de, kernel@...gutronix.de, festevam@...il.com,
	mcoquelin.stm32@...il.com, alexandre.torgue@...s.st.com,
	linux-stm32@...md-mailman.stormreply.com, netdev@...r.kernel.org,
	imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, francesco.dolcini@...adex.com,
	robh@...nel.org,
	Stefan Eichenberger <stefan.eichenberger@...adex.com>
Subject: Re: [PATCH RESEND net-next v2] net: stmmac: dwmac: Add a fixup for
 the Micrel KSZ9131 PHY

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