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

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

[Stefan Eichenberger]

From: Stefan Eichenberger <stefan.eichenberger@toradex.com>

Add a fixup to the stmmac driver to keep the preamble before the SFD
(Start Frame Delimiter) on the Micrel KSZ9131 PHY when the driver is
used on an NXP i.MX8MP SoC.

This allows to workaround errata ERR050694 of the NXP i.MX8MP that
states:
ENET_QOS: MAC incorrectly discards the received packets when Preamble
Byte does not precede SFD or SMD.

The bit which disables this feature is not documented in the datasheet
from Micrel, but has been found by NXP and Micrel following this
discussion:
https://community.nxp.com/t5/i-MX-Processors/iMX8MP-eqos-not-working-for-10base-t/m-p/2151032

It has been tested on Verdin iMX8MP from Toradex by forcing the PHY to
10MBit. Without bit 2 being set in the remote loopback register, no
packets are received. With the bit set, reception works fine.

Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
---
Changes in v2:
- Use phy_register_fixup_for_uid() instead of adding a new device tree
  property
- I will send the conversion of the micrel.txt binding as a separate
  patch series
- Link to v1: https://lore.kernel.org/all/20251212084657.29239-1-eichest@gmail.com/

 .../net/ethernet/stmicro/stmmac/dwmac-imx.c   | 56 ++++++++++++++++++-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
index db288fbd5a4df..23bc917d3f0bd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-imx.c
@@ -19,6 +19,7 @@
 #include <linux/regmap.h>
 #include <linux/slab.h>
 #include <linux/stmmac.h>
+#include <linux/micrel_phy.h>
 
 #include "stmmac_platform.h"
 
@@ -39,6 +40,12 @@
 #define RMII_RESET_SPEED		(0x3 << 14)
 #define CTRL_SPEED_MASK			GENMASK(15, 14)
 
+/* Undocumented bit of the KSZ9131RNX in the remote loopback register to keep
+ * the preamble before sfd. It was reported by NXP in cooperation with Micrel.
+ */
+#define KSZ9x31_REMOTE_LOOPBACK			0x11
+#define KSZ9x31_REMOTE_LOOPBACK_KEEP_PREAMBLE	BIT(2)
+
 struct imx_priv_data;
 
 struct imx_dwmac_ops {
@@ -282,6 +289,30 @@ imx_dwmac_parse_dt(struct imx_priv_data *dwmac, struct device *dev)
 	return err;
 }
 
+static int imx8mp_dwmac_phy_micrel_fixup(struct phy_device *phydev)
+{
+	struct device *mdio_bus_dev = phydev->mdio.dev.parent;
+	struct device_node *mac_node;
+
+	if (!mdio_bus_dev || !mdio_bus_dev->parent)
+		return 0;
+
+	mac_node = mdio_bus_dev->parent->of_node;
+	if (!mac_node)
+		return 0;
+
+	if (!of_device_is_compatible(mac_node, "nxp,imx8mp-dwmac-eqos"))
+		return 0;
+
+	/* Keep the preamble before the SFD (Start Frame Delimiter) for the
+	 * Micrel KSZ9131. This is required on the i.MX8MP because of errata
+	 * ERR050694.
+	 */
+	return phy_modify_changed(phydev, KSZ9x31_REMOTE_LOOPBACK,
+				  KSZ9x31_REMOTE_LOOPBACK_KEEP_PREAMBLE,
+				  KSZ9x31_REMOTE_LOOPBACK_KEEP_PREAMBLE);
+}
+
 static int imx_dwmac_probe(struct platform_device *pdev)
 {
 	struct plat_stmmacenet_data *plat_dat;
@@ -389,7 +420,30 @@ static struct platform_driver imx_dwmac_driver = {
 		.of_match_table = imx_dwmac_match,
 	},
 };
-module_platform_driver(imx_dwmac_driver);
+
+static int __init imx_dwmac_init(void)
+{
+	int ret;
+
+	if (of_machine_is_compatible("fsl,imx8mp")) {
+		ret = phy_register_fixup_for_uid(PHY_ID_KSZ9131, MICREL_PHY_ID_MASK,
+						 imx8mp_dwmac_phy_micrel_fixup);
+		if (ret)
+			return ret;
+	}
+
+	return platform_driver_register(&imx_dwmac_driver);
+}
+module_init(imx_dwmac_init);
+
+static void __exit imx_dwmac_exit(void)
+{
+	if (of_machine_is_compatible("fsl,imx8mp"))
+		phy_unregister_fixup_for_uid(PHY_ID_KSZ9131, MICREL_PHY_ID_MASK);
+
+	platform_driver_unregister(&imx_dwmac_driver);
+}
+module_exit(imx_dwmac_exit);
 
 MODULE_AUTHOR("NXP");
 MODULE_DESCRIPTION("NXP imx8 DWMAC Specific Glue layer");
-- 
2.51.0

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

[Maxime Chevallier]

Hi Stefan,

On 05/01/2026 11:02, Stefan Eichenberger wrote:
> From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> 
> Add a fixup to the stmmac driver to keep the preamble before the SFD
> (Start Frame Delimiter) on the Micrel KSZ9131 PHY when the driver is
> used on an NXP i.MX8MP SoC.
> 
> This allows to workaround errata ERR050694 of the NXP i.MX8MP that
> states:
> ENET_QOS: MAC incorrectly discards the received packets when Preamble
> Byte does not precede SFD or SMD.
> 
> The bit which disables this feature is not documented in the datasheet
> from Micrel, but has been found by NXP and Micrel following this
> discussion:
> https://community.nxp.com/t5/i-MX-Processors/iMX8MP-eqos-not-working-for-10base-t/m-p/2151032
> 
> It has been tested on Verdin iMX8MP from Toradex by forcing the PHY to
> 10MBit. Without bit 2 being set in the remote loopback register, no
> packets are received. With the bit set, reception works fine.
> 
> Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>

I've also faced this issue, however I'm wondering wether this is the
correct approach to fix this. It seems that all Micrel / Microchip PHYs
have this behaviour of discaring the preamble at 10Mbps.

Some of these phys have accessible control registers to re-enable it,
however this register/bit changes depending on the PHY model. For
example, on KSZ8041, this is register 0x14 bit 6.

We may end-up with many many more fixups for this, basically for every
micrel/microchip PHY.

Wouldn't it be safer to just always enable preamble at 10M for these
PHYs, regardless of the MAC that's connected to it ? Is there any risk
always having the preamble there ?

Maxime

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

[Stefan Eichenberger]

Hi Maxime,

On Mon, Jan 05, 2026 at 01:23:46PM +0100, Maxime Chevallier wrote:
> Hi Stefan,
> 
> On 05/01/2026 11:02, Stefan Eichenberger wrote:
> > From: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> > 
> > Add a fixup to the stmmac driver to keep the preamble before the SFD
> > (Start Frame Delimiter) on the Micrel KSZ9131 PHY when the driver is
> > used on an NXP i.MX8MP SoC.
> > 
> > This allows to workaround errata ERR050694 of the NXP i.MX8MP that
> > states:
> > ENET_QOS: MAC incorrectly discards the received packets when Preamble
> > Byte does not precede SFD or SMD.
> > 
> > The bit which disables this feature is not documented in the datasheet
> > from Micrel, but has been found by NXP and Micrel following this
> > discussion:
> > https://community.nxp.com/t5/i-MX-Processors/iMX8MP-eqos-not-working-for-10base-t/m-p/2151032
> > 
> > It has been tested on Verdin iMX8MP from Toradex by forcing the PHY to
> > 10MBit. Without bit 2 being set in the remote loopback register, no
> > packets are received. With the bit set, reception works fine.
> > 
> > Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
> 
> I've also faced this issue, however I'm wondering wether this is the
> correct approach to fix this. It seems that all Micrel / Microchip PHYs
> have this behaviour of discaring the preamble at 10Mbps.
> 
> Some of these phys have accessible control registers to re-enable it,
> however this register/bit changes depending on the PHY model. For
> example, on KSZ8041, this is register 0x14 bit 6.
> 
> We may end-up with many many more fixups for this, basically for every
> micrel/microchip PHY.
> 
> Wouldn't it be safer to just always enable preamble at 10M for these
> PHYs, regardless of the MAC that's connected to it ? Is there any risk
> always having the preamble there ?

This is what Rob also suggested:
https://lore.kernel.org/all/20251215140330.GA2360845-robh@kernel.org/

Unfortunately, I'm afraid of breaking something on the platforms that
are already working, as this is an Ethernet controller issue. As I
understand it, the PHY works according to the standard. Since the bit is
undocumented, it seemed safer to only apply it to the i.MX8MP.

However, if this is preferred, I am also happy to always enable the
preamble. In theory, I don't see any reason why it should break
anything.

Regards,
Stefan

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

[Andrew Lunn]

> Unfortunately, I'm afraid of breaking something on the platforms
> that are already working, as this is an Ethernet controller
> issue. As I understand it, the PHY works according to the standard.

What is the exact wording of the standard? I'm assuming this is IEEE
802.3?  Please could you quote the relevant part.

Thanks
	Andrew

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

[Stefan Eichenberger]

Hi Andrew,

On Mon, Jan 05, 2026 at 04:26:40PM +0100, Andrew Lunn wrote:
> > Unfortunately, I'm afraid of breaking something on the platforms
> > that are already working, as this is an Ethernet controller
> > issue. As I understand it, the PHY works according to the standard.
> 
> What is the exact wording of the standard? I'm assuming this is IEEE
> 802.3?  Please could you quote the relevant part.

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.

I hope this helps.

Regards,
Stefan

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

[Russell King (Oracle)]

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.

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.)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Stefan Eichenberger]

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

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

[Stefan Eichenberger]

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

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

[Maxime Chevallier]

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 :(

Maxime

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

[Stefan Eichenberger]

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

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

[Russell King (Oracle)]

On Sat, Jan 10, 2026 at 02:42:13PM +0100, Stefan Eichenberger wrote:
> Hi Maxime,
> 
> 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.

We could add a flag to:

/* Generic phy_device::dev_flags */
#define PHY_F_NO_IRQ            0x80000000
#define PHY_F_RXC_ALWAYS_ON     0x40000000

indicating that the MAC requires the full preamble, which the PHY can
then test for and configure appropiately.

The question is, whether the requirement for the full preamble applies
to many MACs, and whether there are PHYs that default to producing
short preambles.

Looking at Marvell 88e151x, the only control it has is to pad odd
nibbles of preambles on copper (page 2, register 16, bit 6.)

AR8035 seems to make no mention of preamble for the MII interfaces, so
I guess it has no control over it.

I've not looked further than that.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

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

[Stefan Eichenberger]

On Sat, Jan 10, 2026 at 03:47:21PM +0000, Russell King (Oracle) wrote:
> On Sat, Jan 10, 2026 at 02:42:13PM +0100, Stefan Eichenberger wrote:
> > Hi Maxime,
> > 
> > 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.
> 
> We could add a flag to:
> 
> /* Generic phy_device::dev_flags */
> #define PHY_F_NO_IRQ            0x80000000
> #define PHY_F_RXC_ALWAYS_ON     0x40000000
> 
> indicating that the MAC requires the full preamble, which the PHY can
> then test for and configure appropiately.
> 
> The question is, whether the requirement for the full preamble applies
> to many MACs, and whether there are PHYs that default to producing
> short preambles.
> 
> Looking at Marvell 88e151x, the only control it has is to pad odd
> nibbles of preambles on copper (page 2, register 16, bit 6.)
> 
> AR8035 seems to make no mention of preamble for the MII interfaces, so
> I guess it has no control over it.
> 
> I've not looked further than that.

From what I have seen only the S32 and i.MX8MP MAC require the full
preamble because of the errata. I also checked the i.MX93 and i.MX8DX,
they don't mention the errata, so I assume they are not affected.

Not sure if adding the flag would be a bit overkill. However, assuming
we would do it that way. Would ndo_open be the right place to set the
flag in the mac so that the phy knows about it?

I would think about something like:
- Add a flag STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD to stmmac.h
- Add a flag PHY_F_KEEP_PREAMBLE_BEFORE_SFD to phy.h
- Add STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD to priv->plat->flags in the
  mac driver platform probe (e.g. dwmac-imx.c).
- Set PHY_F_KEEP_PREAMBLE_BEFORE_SFD in stmmac_init_phy (during
  ndo_open) if STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD is set under
  priv->plat->flags.
- If PHY_F_KEEP_PREAMBLE_BEFORE_SFD is set in the phy driver keep the
  full preamble if the phy supports it during config_init.

I could send the next version doing it that way, to see if that's the
better approach.

Regards,
Stefan