netdev - 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 for Android: free password hash cracker in your pocket

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

Message-ID: <aWC_ZDu0HipuVhQS@eichest-laptop>
Date: Fri, 9 Jan 2026 09:42:12 +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

Hi everyone,

On Mon, Jan 05, 2026 at 06:58:24PM +0100, Stefan Eichenberger wrote:
> 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.

I just wanted to check whether I should continue with the current
approach or if I should instead enable the preamble in the PHY for all
MACs. While I prefer the current approach, as the issue lies with the
MAC rather than the PHY, I can also see the advantage of always enabling
the feature.

Regards,
Stefan