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

[Stefan Eichenberger <eichest@gmail.com>]

Hi Maxime,

On Fri, Jan 09, 2026 at 10:38:30AM +0100, Maxime Chevallier wrote:
> Hi Stefan,
> 
> On 09/01/2026 09:42, Stefan Eichenberger wrote:
> > 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.
> 
> My main concern was that we may end-up with a lot of different fixups
> for the various KSZ-family PHY devices, especially since this feature is
> sometimes undocumented.
> 
> I've gone through the micrel.c driver, and looked at the datasheet of
> most PHYs in there, and so far I've found that to fix this issue, we
> need to set :
> 
> KSZ9131 / KSZ8041: Register 0x14 bit 6
> KSZ8061 / KSZ8051 : Register 0x18 bit 6
> 
> So in the end, the complexity appears to be a bit less exponential than
> I originally thought, we may end-up with only a few fixups in this driver.
> 
> I'd say, I'm fine with you proceeding with this original approach as it
> minimizes the impact and risk to break other setups.
> 
> I'm sorry for triggering this whole discussion only to get back to the
> starting point :(

Not problem, thanks a lot for the feedback and the discussion. I will
then proceed with the current approach and send a new version with an
updated commit message.

Regards,
Stefan