[PATCH v3 0/3] ksz87xx: add support for low-loss cable equalizer errata

[PATCH v3 0/3] ksz87xx: add support for low-loss cable equalizer errata

[Fidelio Lawson]

Hello,

This patch implements the “Module 3: Equalizer fix for short cables” erratum
described in Microchip document DS80000687C for KSZ87xx switches.

According to the erratum, the embedded PHY receiver in KSZ87xx switches is
tuned by default for long, high-loss Ethernet cables. When operating with
short or low-loss cables (for example CAT5e or CAT6), the PHY equalizer may
over-amplify the incoming signal, leading to internal distortion and link
establishment failures.

Microchip provides two workarounds, each requiring a write to a different
indirect PHY register access mechanism.

The workaround requires programming internal PHY/DSP registers located in the
LinkMD table, accessed through the KSZ8 indirect register mechanism. Since these
registers belong to the switch address space and are not directly accessible
from a standalone PHY driver, the erratum control is modeled as a vendor-specific
Clause 22 PHY register, virtualized by the KSZ8 DSA driver.

Reads and writes to this register are intercepted by ksz8_r_phy() /
ksz8_w_phy() and translated into the required TABLE_LINK_MD_V indirect accesses.
The erratum affects the shared PHY analog front-end and therefore applies
globally to the switch.

The control register defines the following modes:
0: disabled (default behavior)
1: EQ training workaround
2: LPF 90 MHz
3: LPF 62 MHz
4: LPF 55 MHz
5: LPF 44 MHz

The register can be read and written from userspace via a phy tunable.
Note that current ethtool userspace only supports a fixed set of PHY tunables;
vendor-specific tunables may require either phytool or a newer userspace extension.

This series is based on Linux v7.0-rc1.

Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
Changes in v3:
- Exposed all LPF bandwidth values supported by the hardware.
- Added phy tunable.
- Link to v2: https://patch.msgid.link/20260408-ksz87xx_errata_low_loss_connections-v2-1-9cfe38691713@exotec.com

Changes in v2:
- Dropped the device tree approach based on review feedback
- Modeled the errata control as a vendor-specific Clause 22 PHY register
- Added KSZ87xx-specific guards and replaced magic values with named macros
- Rebased on Linux v7.0-rc1
- Link to v1: https://patch.msgid.link/20260326-ksz87xx_errata_low_loss_connections-v1-0-79a698f43626@exotec.com

---
Fidelio Lawson (3):
      net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
      net: ethtool: add KSZ87xx low-loss PHY tunable
      net: phy: micrel: expose KSZ87xx low-loss erratum via PHY tunable

 drivers/net/dsa/microchip/ksz8.c       | 45 ++++++++++++++++++++++++++++++++++
 drivers/net/dsa/microchip/ksz8_reg.h   | 36 ++++++++++++++++++++++++++-
 drivers/net/dsa/microchip/ksz_common.h |  3 +++
 drivers/net/phy/micrel.c               | 39 +++++++++++++++++++++++++++++
 include/uapi/linux/ethtool.h           |  1 +
 net/ethtool/common.c                   |  1 +
 net/ethtool/ioctl.c                    |  1 +
 7 files changed, 125 insertions(+), 1 deletion(-)
---
base-commit: 2d1373e4246da3b58e1df058374ed6b101804e07
change-id: 20260323-ksz87xx_errata_low_loss_connections-b65e76e2b403

Best regards,
--  
Fidelio Lawson <fidelio.lawson@exotec.com>

[PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Fidelio Lawson]

Implement the "Module 3: Equalizer fix for short cables" erratum from
Microchip document DS80000687C for KSZ87xx switches.

The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
where the PHY receiver equalizer may amplify high-amplitude signals
excessively, resulting in internal distortion and link establishment
failures.

KSZ87xx devices require a workaround for the Module 3 low-loss cable
condition, controlled through the switch TABLE_LINK_MD_V indirect
registers.

The affected registers are part of the switch address space and are not
directly accessible from the PHY driver. To keep the PHY-facing API
clean and avoid leaking switch-specific details, model this errata
control as vendor-specific Clause 22 PHY registers.

A vendor-specific Clause 22 PHY register is introduced as a mode
selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
translate accesses to these bits into the appropriate indirect
TABLE_LINK_MD_V accesses.

The control register defines the following modes:
0: disabled (default behavior)
1: EQ training workaround
2: LPF 90 MHz
3: LPF 62 MHz
4: LPF 55 MHz
5: LPF 44 MHz

Workaround 1: Adjusts the DSP EQ training behavior via LinkMD register
0x3C. Widens and optimizes the DSP EQ compensation range,
and is expected to solve most short/low-loss cable issues.

Workaround 2: for the cases where Workaround 1 is not sufficient.
This one adjusts the receiver low-pass filter bandwidth, effectively
reducing the high-frequency component of the received signal

The register is accessible through standard PHY read/write operations
(e.g. phytool), without requiring any switch-specific userspace
interface. This allows robust link establishment on short or
low-loss cabling without requiring DTS properties and without
constraining hardware design choices.

The erratum affects the shared PHY analog front-end and therefore
applies globally to the switch.

Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
 drivers/net/dsa/microchip/ksz8.c       | 45 ++++++++++++++++++++++++++++++++++
 drivers/net/dsa/microchip/ksz8_reg.h   | 36 ++++++++++++++++++++++++++-
 drivers/net/dsa/microchip/ksz_common.h |  3 +++
 3 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/drivers/net/dsa/microchip/ksz8.c b/drivers/net/dsa/microchip/ksz8.c
index c354abdafc1b..596c85654f24 100644
--- a/drivers/net/dsa/microchip/ksz8.c
+++ b/drivers/net/dsa/microchip/ksz8.c
@@ -1058,6 +1058,11 @@ int ksz8_r_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 *val)
 		if (ret)
 			return ret;
 
+		break;
+	case PHY_REG_KSZ87XX_LOW_LOSS:
+		if (!ksz_is_ksz87xx(dev))
+			return -EOPNOTSUPP;
+		data = dev->low_loss_wa_mode;
 		break;
 	default:
 		processed = false;
@@ -1271,6 +1276,46 @@ int ksz8_w_phy(struct ksz_device *dev, u16 phy, u16 reg, u16 val)
 		if (ret)
 			return ret;
 		break;
+	case PHY_REG_KSZ87XX_LOW_LOSS:
+		if (!ksz_is_ksz87xx(dev))
+			return -EOPNOTSUPP;
+
+		switch (val & PHY_KSZ87XX_LOW_LOSS_MASK) {
+		case PHY_LOW_LOSS_ERRATA_DISABLED:
+			ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_EQ_TRAIN,
+					      KSZ87XX_EQ_TRAIN_DEFAULT);
+			if (!ret)
+				ret = ksz8_ind_write8(dev, TABLE_LINK_MD,
+						      KSZ87XX_REG_PHY_LPF,
+						      KSZ87XX_LOW_LOSS_LPF_90MHZ);
+			break;
+		case KSZ87XX_LOW_LOSS_EQ_TRAIN:
+			ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_EQ_TRAIN,
+					      KSZ87XX_EQ_TRAIN_LOW_LOSS);
+			break;
+		case KSZ87XX_LOW_LOSS_LPF_90MHZ:
+			ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+					      KSZ87XX_PHY_LPF_90MHZ);
+			break;
+		case KSZ87XX_LOW_LOSS_LPF_62MHZ:
+			ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+					      KSZ87XX_PHY_LPF_62MHZ);
+			break;
+		case KSZ87XX_LOW_LOSS_LPF_55MHZ:
+			ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+					      KSZ87XX_PHY_LPF_55MHZ);
+			break;
+		case KSZ87XX_LOW_LOSS_LPF_44MHZ:
+			ret = ksz8_ind_write8(dev, TABLE_LINK_MD, KSZ87XX_REG_PHY_LPF,
+					      KSZ87XX_PHY_LPF_44MHZ);
+			break;
+		default:
+			return -EINVAL;
+		}
+
+		if (!ret)
+			dev->low_loss_wa_mode = val & PHY_KSZ87XX_LOW_LOSS_MASK;
+		return ret;
 	default:
 		break;
 	}
diff --git a/drivers/net/dsa/microchip/ksz8_reg.h b/drivers/net/dsa/microchip/ksz8_reg.h
index 332408567b47..4e02e044339c 100644
--- a/drivers/net/dsa/microchip/ksz8_reg.h
+++ b/drivers/net/dsa/microchip/ksz8_reg.h
@@ -202,6 +202,10 @@
 #define REG_PORT_3_STATUS_0		0x38
 #define REG_PORT_4_STATUS_0		0x48
 
+/* KSZ87xx LinkMD registers (TABLE_LINK_MD_V) */
+#define KSZ87XX_REG_EQ_TRAIN		0x3C
+#define KSZ87XX_REG_PHY_LPF			0x4C
+
 /* For KSZ8765. */
 #define PORT_REMOTE_ASYM_PAUSE		BIT(5)
 #define PORT_REMOTE_SYM_PAUSE		BIT(4)
@@ -342,7 +346,7 @@
 #define TABLE_EEE			(TABLE_EEE_V << TABLE_EXT_SELECT_S)
 #define TABLE_ACL			(TABLE_ACL_V << TABLE_EXT_SELECT_S)
 #define TABLE_PME			(TABLE_PME_V << TABLE_EXT_SELECT_S)
-#define TABLE_LINK_MD			(TABLE_LINK_MD << TABLE_EXT_SELECT_S)
+#define TABLE_LINK_MD			(TABLE_LINK_MD_V << TABLE_EXT_SELECT_S)
 #define TABLE_READ			BIT(4)
 #define TABLE_SELECT_S			2
 #define TABLE_STATIC_MAC_V		0
@@ -729,6 +733,36 @@
 #define PHY_POWER_SAVING_ENABLE		BIT(2)
 #define PHY_REMOTE_LOOPBACK		BIT(1)
 
+/* Equalizer low-loss workaround */
+#define PHY_REG_KSZ87XX_LOW_LOSS       0x1C
+#define PHY_KSZ87XX_LOW_LOSS_MASK      GENMASK(2, 0)
+
+/* KSZ87xx low-loss EQ mode selector (vendor-specific PHY reg 0x1c)
+ *
+ * Values:
+ *  0: disabled (default behavior)
+ *  1: EQ training workaround
+ *  2: LPF 90 MHz
+ *  3: LPF 62 MHz
+ *  4: LPF 55 MHz
+ *  5: LPF 44 MHz
+ */
+#define PHY_LOW_LOSS_ERRATA_DISABLED		0
+#define KSZ87XX_LOW_LOSS_EQ_TRAIN			1
+#define KSZ87XX_LOW_LOSS_LPF_90MHZ			2
+#define KSZ87XX_LOW_LOSS_LPF_62MHZ			3
+#define KSZ87XX_LOW_LOSS_LPF_55MHZ			4
+#define KSZ87XX_LOW_LOSS_LPF_44MHZ			5
+
+#define KSZ87XX_EQ_TRAIN_DEFAULT       0x0A
+#define KSZ87XX_EQ_TRAIN_LOW_LOSS      0x15
+
+/* LPF bandwidth bits [7:6]: 00 = 90MHz, 01 = 62MHz, 10 = 55MHz, 11 = 44MHz  */
+#define KSZ87XX_PHY_LPF_90MHZ          0x00
+#define KSZ87XX_PHY_LPF_62MHZ          0x40
+#define KSZ87XX_PHY_LPF_55MHZ          0x80
+#define KSZ87XX_PHY_LPF_44MHZ          0xC0
+
 /* KSZ8463 specific registers. */
 #define P1MBCR				0x4C
 #define P1MBSR				0x4E
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index 929aff4c55de..16a6074ea4b4 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -219,6 +219,9 @@ struct ksz_device {
 	 * the switch’s internal PHYs, bypassing the main SPI interface.
 	 */
 	struct mii_bus *parent_mdio_bus;
+
+	/* Equalizer low-loss workaround tunable */
+	u8 low_loss_wa_mode; /* KSZ87xx low-loss EQ/LPF mode selector (0-5) */
 };
 
 /* List of supported models */

-- 
2.53.0

[PATCH v3 2/3] net: ethtool: add KSZ87xx low-loss PHY tunable

[Fidelio Lawson]

Introduce a new PHY tunable identifier,
ETHTOOL_PHY_KSZ87XX_LOW_LOSS, to allow userspace to control the
KSZ87xx low-loss cable erratum through the ethtool PHY tunable
interface.

KSZ87xx switches integrate embedded PHYs whose receiver behavior may
require specific equalizer or low-pass filter adjustments when used
with short or low-loss Ethernet cables, as described in Microchip
errata DS80000687C (Module 3). The new tunable provides a userspace
interface for selecting the desired operating mode.

The tunable uses a u8 value and is vendor-specific by design. The
actual handling is implemented by the corresponding PHY driver.

Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
 include/uapi/linux/ethtool.h | 1 +
 net/ethtool/common.c         | 1 +
 net/ethtool/ioctl.c          | 1 +
 3 files changed, 3 insertions(+)

diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index b74b80508553..5c539e1bca4b 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -295,6 +295,7 @@ enum phy_tunable_id {
 	 * Add your fresh new phy tunable attribute above and remember to update
 	 * phy_tunable_strings[] in net/ethtool/common.c
 	 */
+	ETHTOOL_PHY_KSZ87XX_LOW_LOSS,
 	__ETHTOOL_PHY_TUNABLE_COUNT,
 };
 
diff --git a/net/ethtool/common.c b/net/ethtool/common.c
index e252cf20c22f..e1c98ce66093 100644
--- a/net/ethtool/common.c
+++ b/net/ethtool/common.c
@@ -101,6 +101,7 @@ phy_tunable_strings[__ETHTOOL_PHY_TUNABLE_COUNT][ETH_GSTRING_LEN] = {
 	[ETHTOOL_PHY_DOWNSHIFT]	= "phy-downshift",
 	[ETHTOOL_PHY_FAST_LINK_DOWN] = "phy-fast-link-down",
 	[ETHTOOL_PHY_EDPD]	= "phy-energy-detect-power-down",
+	[ETHTOOL_PHY_KSZ87XX_LOW_LOSS] = "phy-ksz87xx-low-loss",
 };
 
 #define __LINK_MODE_NAME(speed, type, duplex) \
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index ff4b4780d6af..9e7bd887acf5 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -3109,6 +3109,7 @@ static int ethtool_phy_tunable_valid(const struct ethtool_tunable *tuna)
 	switch (tuna->id) {
 	case ETHTOOL_PHY_DOWNSHIFT:
 	case ETHTOOL_PHY_FAST_LINK_DOWN:
+	case ETHTOOL_PHY_KSZ87XX_LOW_LOSS:
 		if (tuna->len != sizeof(u8) ||
 		    tuna->type_id != ETHTOOL_TUNABLE_U8)
 			return -EINVAL;

-- 
2.53.0

[PATCH v3 3/3] net: phy: micrel: expose KSZ87xx low-loss erratum via PHY tunable

[Fidelio Lawson]

Expose the KSZ87xx low-loss cable erratum control through the PHY
tunable interface.

KSZ87xx switches integrate embedded PHYs whose receiver analog front-end
may require specific equalizer or low-pass filter adjustments when used
with short or low-loss Ethernet cables, as described in Microchip errata
DS80000687C (Module 3).

Implement get_tunable / set_tunable callbacks in the Micrel PHY driver
for KSZ87xx devices, mapping the ETHTOOL_PHY_KSZ87XX_LOW_LOSS tunable
to a vendor-specific Clause 22 PHY register. Accesses are routed through
standard phy_read() / phy_write() operations and translated by the KSZ8
DSA driver into the appropriate internal LinkMD table updates.

The tunable uses a u8 mode selector, allowing userspace to select
between the documented equalizer and LPF bandwidth configurations.

Signed-off-by: Fidelio Lawson <fidelio.lawson@exotec.com>
---
 drivers/net/phy/micrel.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index c6b011a9d636..7cbca6a7ed84 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -287,6 +287,11 @@
 /* PHY Control 2 / PHY Control (if no PHY Control 1) */
 #define MII_KSZPHY_CTRL_2			0x1f
 #define MII_KSZPHY_CTRL				MII_KSZPHY_CTRL_2
+
+/* Vendor-specific Clause 22 register, virtualized by KSZ87xx embedded PHYs DSA driver */
+#define MII_KSZ87XX_LOW_LOSS			0x1c
+#define KSZ87XX_LOW_LOSS_MAX			5
+
 /* bitmap of PHY register to set interrupt mode */
 #define KSZ8081_CTRL2_HP_MDIX			BIT(15)
 #define KSZ8081_CTRL2_MDI_MDI_X_SELECT		BIT(14)
@@ -940,6 +945,38 @@ static int ksz8795_match_phy_device(struct phy_device *phydev,
 	return ksz8051_ksz8795_match_phy_device(phydev, false);
 }
 
+static int ksz87xx_get_tunable(struct phy_device *phydev,
+			       struct ethtool_tunable *tuna, void *data)
+{
+	int ret;
+
+	switch (tuna->id) {
+	case ETHTOOL_PHY_KSZ87XX_LOW_LOSS:
+		ret = phy_read(phydev, MII_KSZ87XX_LOW_LOSS);
+		if (ret < 0)
+			return ret;
+		*(u8 *)data = ret;
+		return 0;
+	default:
+		return -EOPNOTSUPP;
+	}
+}
+
+static int ksz87xx_set_tunable(struct phy_device *phydev,
+			       struct ethtool_tunable *tuna, const void *data)
+{
+	u8 val = *(const u8 *)data;
+
+	switch (tuna->id) {
+	case ETHTOOL_PHY_KSZ87XX_LOW_LOSS:
+		if (val > KSZ87XX_LOW_LOSS_MAX)
+			return -EINVAL;
+		return phy_write(phydev, MII_KSZ87XX_LOW_LOSS, val);
+	default:
+		return -EOPNOTSUPP;
+	}
+}
+
 static int ksz9021_load_values_from_of(struct phy_device *phydev,
 				       const struct device_node *of_node,
 				       u16 reg,
@@ -6809,6 +6846,8 @@ static struct phy_driver ksphy_driver[] = {
 	/* PHY_BASIC_FEATURES */
 	.config_init	= kszphy_config_init,
 	.match_phy_device = ksz8795_match_phy_device,
+	.get_tunable	= ksz87xx_get_tunable,
+	.set_tunable	= ksz87xx_set_tunable,
 	.suspend	= genphy_suspend,
 	.resume		= genphy_resume,
 }, {

-- 
2.53.0

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Marek Vasut]

On 4/14/26 11:12 AM, Fidelio Lawson wrote:
> Implement the "Module 3: Equalizer fix for short cables" erratum from
> Microchip document DS80000687C for KSZ87xx switches.
> 
> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
> where the PHY receiver equalizer may amplify high-amplitude signals
> excessively, resulting in internal distortion and link establishment
> failures.
> 
> KSZ87xx devices require a workaround for the Module 3 low-loss cable
> condition, controlled through the switch TABLE_LINK_MD_V indirect
> registers.
> 
> The affected registers are part of the switch address space and are not
> directly accessible from the PHY driver. To keep the PHY-facing API
> clean and avoid leaking switch-specific details, model this errata
> control as vendor-specific Clause 22 PHY registers.
> 
> A vendor-specific Clause 22 PHY register is introduced as a mode
> selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
> translate accesses to these bits into the appropriate indirect
> TABLE_LINK_MD_V accesses.
> 
> The control register defines the following modes:
> 0: disabled (default behavior)
> 1: EQ training workaround
> 2: LPF 90 MHz
> 3: LPF 62 MHz
> 4: LPF 55 MHz
> 5: LPF 44 MHz
I may not fully understand this, but aren't the EQ and LPF settings 
orthogonal ?

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Fidelio LAWSON]

On 4/14/26 13:05, Marek Vasut wrote:
> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>> Microchip document DS80000687C for KSZ87xx switches.
>>
>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>> where the PHY receiver equalizer may amplify high-amplitude signals
>> excessively, resulting in internal distortion and link establishment
>> failures.
>>
>> KSZ87xx devices require a workaround for the Module 3 low-loss cable
>> condition, controlled through the switch TABLE_LINK_MD_V indirect
>> registers.
>>
>> The affected registers are part of the switch address space and are not
>> directly accessible from the PHY driver. To keep the PHY-facing API
>> clean and avoid leaking switch-specific details, model this errata
>> control as vendor-specific Clause 22 PHY registers.
>>
>> A vendor-specific Clause 22 PHY register is introduced as a mode
>> selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
>> translate accesses to these bits into the appropriate indirect
>> TABLE_LINK_MD_V accesses.
>>
>> The control register defines the following modes:
>> 0: disabled (default behavior)
>> 1: EQ training workaround
>> 2: LPF 90 MHz
>> 3: LPF 62 MHz
>> 4: LPF 55 MHz
>> 5: LPF 44 MHz
> I may not fully understand this, but aren't the EQ and LPF settings 
> orthogonal ?
You are right that EQ training and LPF bandwidth control
are orthogonal from a hardware point of view.

In this case, the interface is intentionally modeled after the erratum
guidance rather than exposing all possible combinations. Microchip
documents the workarounds as alternative solutions:

"If work around 1 does not solve the short cable issue in a CAT-5E or 
CAT-6 application, change the work around 1 register (0x3C) to its 
default value (0x0A), and use the following settings"
from: 
https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/Errata/KSZ87xx-Errata-DS80000687C.pdf

If you’d prefer exposing these as orthogonal controls, I can revise the
interface in the next iteration.

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Andrew Lunn]

On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
> > Implement the "Module 3: Equalizer fix for short cables" erratum from
> > Microchip document DS80000687C for KSZ87xx switches.
> > 
> > The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
> > where the PHY receiver equalizer may amplify high-amplitude signals
> > excessively, resulting in internal distortion and link establishment
> > failures.
> > 
> > KSZ87xx devices require a workaround for the Module 3 low-loss cable
> > condition, controlled through the switch TABLE_LINK_MD_V indirect
> > registers.
> > 
> > The affected registers are part of the switch address space and are not
> > directly accessible from the PHY driver. To keep the PHY-facing API
> > clean and avoid leaking switch-specific details, model this errata
> > control as vendor-specific Clause 22 PHY registers.
> > 
> > A vendor-specific Clause 22 PHY register is introduced as a mode
> > selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
> > translate accesses to these bits into the appropriate indirect
> > TABLE_LINK_MD_V accesses.
> > 
> > The control register defines the following modes:
> > 0: disabled (default behavior)
> > 1: EQ training workaround
> > 2: LPF 90 MHz
> > 3: LPF 62 MHz
> > 4: LPF 55 MHz
> > 5: LPF 44 MHz
> I may not fully understand this, but aren't the EQ and LPF settings
> orthogonal ?

What is the real life experience using this feature? Is it needed for
1cm cables, but most > 1m cables are O.K with the defaults? Do we need
all these configuration options? How is a user supposed to discover
the different options? Can we simplify it down to a Boolean?

Ethernet is just supposed to work with any valid length of cable,
KISS. So maybe we should try to keep this feature KISS. Just tell the
driver it is a short cable, pick different defaults which should work
with any short cable?

A boolean should also help with making this tunable reusable with
other devices. It is unlikely any other devices have these same
configuration options, unless it is from the same vendor.

     Andrew

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Fidelio LAWSON]

On 4/14/26 14:40, Andrew Lunn wrote:
> On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
>> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
>>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>>> Microchip document DS80000687C for KSZ87xx switches.
>>>
>>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>>> where the PHY receiver equalizer may amplify high-amplitude signals
>>> excessively, resulting in internal distortion and link establishment
>>> failures.
>>>
>>> KSZ87xx devices require a workaround for the Module 3 low-loss cable
>>> condition, controlled through the switch TABLE_LINK_MD_V indirect
>>> registers.
>>>
>>> The affected registers are part of the switch address space and are not
>>> directly accessible from the PHY driver. To keep the PHY-facing API
>>> clean and avoid leaking switch-specific details, model this errata
>>> control as vendor-specific Clause 22 PHY registers.
>>>
>>> A vendor-specific Clause 22 PHY register is introduced as a mode
>>> selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
>>> translate accesses to these bits into the appropriate indirect
>>> TABLE_LINK_MD_V accesses.
>>>
>>> The control register defines the following modes:
>>> 0: disabled (default behavior)
>>> 1: EQ training workaround
>>> 2: LPF 90 MHz
>>> 3: LPF 62 MHz
>>> 4: LPF 55 MHz
>>> 5: LPF 44 MHz
>> I may not fully understand this, but aren't the EQ and LPF settings
>> orthogonal ?
> 
> What is the real life experience using this feature? Is it needed for
> 1cm cables, but most > 1m cables are O.K with the defaults? Do we need
> all these configuration options? How is a user supposed to discover
> the different options? Can we simplify it down to a Boolean?
> 
> Ethernet is just supposed to work with any valid length of cable,
> KISS. So maybe we should try to keep this feature KISS. Just tell the
> driver it is a short cable, pick different defaults which should work
> with any short cable?
> 
> A boolean should also help with making this tunable reusable with
> other devices. It is unlikely any other devices have these same
> configuration options, unless it is from the same vendor.
> 
>       Andrew

The issue has been observed with very short or low‑loss
cables, typically in industrial or embedded setups where the cable is
below 3m or in a board-to-board setup.

 From our practical experience, this issue occurs in our setup where a 
very short CAT‑6e cable (~20cm) is used.
We were seeing random link dropouts with the default settings, and since 
enabling the workaround 2, the link has remained stable and we have not 
observed any further issues.

We don’t need all these configuration options.

According to the Microchip erratum, the user should try workaround 1 (EQ 
training), and if that does not resolve the random link dropouts,
fall back to workaround 2 by reducing the LPF bandwidth to 62MHz.

Since this procedure for determining which workaround is effective is 
inherently experimental and requires observation in real deployments, 
this is why I originally chose to expose the selection of the workaround 
to the user, at least allowing them to choose between workaround 1 and 
workaround 2.

regards

Fidelio

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Andrew Lunn]

On Tue, Apr 14, 2026 at 03:48:33PM +0200, Fidelio LAWSON wrote:
> On 4/14/26 14:40, Andrew Lunn wrote:
> > On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
> > > On 4/14/26 11:12 AM, Fidelio Lawson wrote:
> > > > Implement the "Module 3: Equalizer fix for short cables" erratum from
> > > > Microchip document DS80000687C for KSZ87xx switches.
> > > > 
> > > > The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
> > > > where the PHY receiver equalizer may amplify high-amplitude signals
> > > > excessively, resulting in internal distortion and link establishment
> > > > failures.
> > > > 
> > > > KSZ87xx devices require a workaround for the Module 3 low-loss cable
> > > > condition, controlled through the switch TABLE_LINK_MD_V indirect
> > > > registers.
> > > > 
> > > > The affected registers are part of the switch address space and are not
> > > > directly accessible from the PHY driver. To keep the PHY-facing API
> > > > clean and avoid leaking switch-specific details, model this errata
> > > > control as vendor-specific Clause 22 PHY registers.
> > > > 
> > > > A vendor-specific Clause 22 PHY register is introduced as a mode
> > > > selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
> > > > translate accesses to these bits into the appropriate indirect
> > > > TABLE_LINK_MD_V accesses.
> > > > 
> > > > The control register defines the following modes:
> > > > 0: disabled (default behavior)
> > > > 1: EQ training workaround
> > > > 2: LPF 90 MHz
> > > > 3: LPF 62 MHz
> > > > 4: LPF 55 MHz
> > > > 5: LPF 44 MHz
> > > I may not fully understand this, but aren't the EQ and LPF settings
> > > orthogonal ?
> > 
> > What is the real life experience using this feature? Is it needed for
> > 1cm cables, but most > 1m cables are O.K with the defaults? Do we need
> > all these configuration options? How is a user supposed to discover
> > the different options? Can we simplify it down to a Boolean?
> We were seeing random link dropouts with the default settings, and since
> enabling the workaround 2, the link has remained stable and we have not
> observed any further issues.

So for you, a boolean which enables workaround 2 would be sufficient.

Marek, what is your experience?

       Andrew

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Marek Vasut]

On 4/14/26 2:40 PM, Andrew Lunn wrote:
> On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
>> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
>>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>>> Microchip document DS80000687C for KSZ87xx switches.
>>>
>>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>>> where the PHY receiver equalizer may amplify high-amplitude signals
>>> excessively, resulting in internal distortion and link establishment
>>> failures.
>>>
>>> KSZ87xx devices require a workaround for the Module 3 low-loss cable
>>> condition, controlled through the switch TABLE_LINK_MD_V indirect
>>> registers.
>>>
>>> The affected registers are part of the switch address space and are not
>>> directly accessible from the PHY driver. To keep the PHY-facing API
>>> clean and avoid leaking switch-specific details, model this errata
>>> control as vendor-specific Clause 22 PHY registers.
>>>
>>> A vendor-specific Clause 22 PHY register is introduced as a mode
>>> selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
>>> translate accesses to these bits into the appropriate indirect
>>> TABLE_LINK_MD_V accesses.
>>>
>>> The control register defines the following modes:
>>> 0: disabled (default behavior)
>>> 1: EQ training workaround
>>> 2: LPF 90 MHz
>>> 3: LPF 62 MHz
>>> 4: LPF 55 MHz
>>> 5: LPF 44 MHz
>> I may not fully understand this, but aren't the EQ and LPF settings
>> orthogonal ?
> 
> What is the real life experience using this feature? Is it needed for
> 1cm cables, but most > 1m cables are O.K with the defaults? Do we need
> all these configuration options? How is a user supposed to discover
> the different options? Can we simplify it down to a Boolean?

The report I got was, that if the device is cooled down AND the user 
used special short low-loss CAT6 cable, then there was packet loss until 
the communication completely broke down.

With the LPF set to 62 MHz and DSP EQ initial value set to 0, that 
situation improved and there was still up to 0.14% packet less, but it 
is better than total breakdown of communication. We couldn't get the 
packet loss down to 0% no matter which tuning we applied.

> Ethernet is just supposed to work with any valid length of cable,
> KISS. So maybe we should try to keep this feature KISS. Just tell the
> driver it is a short cable, pick different defaults which should work
> with any short cable?

I think the user should be able to configure the LPF bandwidth and DSP 
EQ initial value as needed. While the short cable improvement settings 
are "LPF set to 62 MHz bandwidth and DSP EQ initial value to 0", there 
might be future configurations which require different settings.

I think the ideal setup would be if those two settings were configurable 
separately, with a bit of documentation explaining the two currently 
known good settings:
- Default (LPF 90 MHz BW, DSP EQ initial value as needed)
- Short cable (LPF 62 MHz BW, DSP EQ initial value 0)
But if the user needs to reduce the BW further e.g. to improve noise 
resistance further, they shouldn't be prevented from doing so.

> A boolean should also help with making this tunable reusable with
> other devices. It is unlikely any other devices have these same
> configuration options, unless it is from the same vendor.
Could the LPF PHY tunable simply take integer as a parameter ? Then it 
would be portable across other PHYs I think ?

The DSP EQ initial value can also be an integer tunable.

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Marek Vasut]

On 4/14/26 4:54 PM, Andrew Lunn wrote:
> On Tue, Apr 14, 2026 at 03:48:33PM +0200, Fidelio LAWSON wrote:
>> On 4/14/26 14:40, Andrew Lunn wrote:
>>> On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
>>>> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
>>>>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>>>>> Microchip document DS80000687C for KSZ87xx switches.
>>>>>
>>>>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>>>>> where the PHY receiver equalizer may amplify high-amplitude signals
>>>>> excessively, resulting in internal distortion and link establishment
>>>>> failures.
>>>>>
>>>>> KSZ87xx devices require a workaround for the Module 3 low-loss cable
>>>>> condition, controlled through the switch TABLE_LINK_MD_V indirect
>>>>> registers.
>>>>>
>>>>> The affected registers are part of the switch address space and are not
>>>>> directly accessible from the PHY driver. To keep the PHY-facing API
>>>>> clean and avoid leaking switch-specific details, model this errata
>>>>> control as vendor-specific Clause 22 PHY registers.
>>>>>
>>>>> A vendor-specific Clause 22 PHY register is introduced as a mode
>>>>> selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
>>>>> translate accesses to these bits into the appropriate indirect
>>>>> TABLE_LINK_MD_V accesses.
>>>>>
>>>>> The control register defines the following modes:
>>>>> 0: disabled (default behavior)
>>>>> 1: EQ training workaround
>>>>> 2: LPF 90 MHz
>>>>> 3: LPF 62 MHz
>>>>> 4: LPF 55 MHz
>>>>> 5: LPF 44 MHz
>>>> I may not fully understand this, but aren't the EQ and LPF settings
>>>> orthogonal ?
>>>
>>> What is the real life experience using this feature? Is it needed for
>>> 1cm cables, but most > 1m cables are O.K with the defaults? Do we need
>>> all these configuration options? How is a user supposed to discover
>>> the different options? Can we simplify it down to a Boolean?
>> We were seeing random link dropouts with the default settings, and since
>> enabling the workaround 2, the link has remained stable and we have not
>> observed any further issues.
> 
> So for you, a boolean which enables workaround 2 would be sufficient.
I agree with the observation from Fidelio, the hardware behaves that 
way. As for the rest format of the tunables, I now replied to previous 
email.

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Fidelio LAWSON]

On 4/14/26 17:49, Marek Vasut wrote:
> On 4/14/26 2:40 PM, Andrew Lunn wrote:
>> On Tue, Apr 14, 2026 at 01:05:49PM +0200, Marek Vasut wrote:
>>> On 4/14/26 11:12 AM, Fidelio Lawson wrote:
>>>> Implement the "Module 3: Equalizer fix for short cables" erratum from
>>>> Microchip document DS80000687C for KSZ87xx switches.
>>>>
>>>> The issue affects short or low-loss cable links (e.g. CAT5e/CAT6),
>>>> where the PHY receiver equalizer may amplify high-amplitude signals
>>>> excessively, resulting in internal distortion and link establishment
>>>> failures.
>>>>
>>>> KSZ87xx devices require a workaround for the Module 3 low-loss cable
>>>> condition, controlled through the switch TABLE_LINK_MD_V indirect
>>>> registers.
>>>>
>>>> The affected registers are part of the switch address space and are not
>>>> directly accessible from the PHY driver. To keep the PHY-facing API
>>>> clean and avoid leaking switch-specific details, model this errata
>>>> control as vendor-specific Clause 22 PHY registers.
>>>>
>>>> A vendor-specific Clause 22 PHY register is introduced as a mode
>>>> selector in PHY_REG_LOW_LOSS_CTRL, and ksz8_r_phy() / ksz8_w_phy()
>>>> translate accesses to these bits into the appropriate indirect
>>>> TABLE_LINK_MD_V accesses.
>>>>
>>>> The control register defines the following modes:
>>>> 0: disabled (default behavior)
>>>> 1: EQ training workaround
>>>> 2: LPF 90 MHz
>>>> 3: LPF 62 MHz
>>>> 4: LPF 55 MHz
>>>> 5: LPF 44 MHz
>>> I may not fully understand this, but aren't the EQ and LPF settings
>>> orthogonal ?
>>
>> What is the real life experience using this feature? Is it needed for
>> 1cm cables, but most > 1m cables are O.K with the defaults? Do we need
>> all these configuration options? How is a user supposed to discover
>> the different options? Can we simplify it down to a Boolean?
> 
> The report I got was, that if the device is cooled down AND the user 
> used special short low-loss CAT6 cable, then there was packet loss until 
> the communication completely broke down.
> 
> With the LPF set to 62 MHz and DSP EQ initial value set to 0, that 
> situation improved and there was still up to 0.14% packet less, but it 
> is better than total breakdown of communication. We couldn't get the 
> packet loss down to 0% no matter which tuning we applied.
> 
>> Ethernet is just supposed to work with any valid length of cable,
>> KISS. So maybe we should try to keep this feature KISS. Just tell the
>> driver it is a short cable, pick different defaults which should work
>> with any short cable?
> 
> I think the user should be able to configure the LPF bandwidth and DSP 
> EQ initial value as needed. While the short cable improvement settings 
> are "LPF set to 62 MHz bandwidth and DSP EQ initial value to 0", there 
> might be future configurations which require different settings.
> 
> I think the ideal setup would be if those two settings were configurable 
> separately, with a bit of documentation explaining the two currently 
> known good settings:
> - Default (LPF 90 MHz BW, DSP EQ initial value as needed)
> - Short cable (LPF 62 MHz BW, DSP EQ initial value 0)
> But if the user needs to reduce the BW further e.g. to improve noise 
> resistance further, they shouldn't be prevented from doing so.
> 
>> A boolean should also help with making this tunable reusable with
>> other devices. It is unlikely any other devices have these same
>> configuration options, unless it is from the same vendor.
> Could the LPF PHY tunable simply take integer as a parameter ? Then it 
> would be portable across other PHYs I think ?
> 
> The DSP EQ initial value can also be an integer tunable.

Yes, I think a reasonable compromise could be to expose three tunables:

- a boolean "short-cable" tunable, which applies the known good settings
   (LPF 62 MHz BW, DSP EQ initial value 0).

- an integer LPF bandwidth tunable, for advanced use cases where further
   tuning is needed;

- an integer DSP EQ initial value tunable, for the same advanced cases.

The boolean tunable would follow the KISS principle and cover the common
scenario, while the more granular controls would remain optional.

What do you think?

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Andrew Lunn]

> Yes, I think a reasonable compromise could be to expose three tunables:
> 
> - a boolean "short-cable" tunable, which applies the known good settings
>   (LPF 62 MHz BW, DSP EQ initial value 0).
> 
> - an integer LPF bandwidth tunable, for advanced use cases where further
>   tuning is needed;
> 
> - an integer DSP EQ initial value tunable, for the same advanced cases.
> 
> The boolean tunable would follow the KISS principle and cover the common
> scenario, while the more granular controls would remain optional.

How do the three interact? Do you need to first enable short-cable
before you set LPG bandwidth or DSP EQ? If it is not enabled, do you
get -EINVAL?

It seems like having extack would be useful to return informative
error messages to user space, however, that requires netlink
ethtool. And ETHTOOL_PHY_STUNABLE has not been added to netlink
ethtool yet :-(

	Andrew

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Fidelio LAWSON]

On 4/16/26 14:25, Andrew Lunn wrote:
>> Yes, I think a reasonable compromise could be to expose three tunables:
>>
>> - a boolean "short-cable" tunable, which applies the known good settings
>>    (LPF 62 MHz BW, DSP EQ initial value 0).
>>
>> - an integer LPF bandwidth tunable, for advanced use cases where further
>>    tuning is needed;
>>
>> - an integer DSP EQ initial value tunable, for the same advanced cases.
>>
>> The boolean tunable would follow the KISS principle and cover the common
>> scenario, while the more granular controls would remain optional.
> 
> How do the three interact? Do you need to first enable short-cable
> before you set LPG bandwidth or DSP EQ? If it is not enabled, do you
> get -EINVAL?
> 
> It seems like having extack would be useful to return informative
> error messages to user space, however, that requires netlink
> ethtool. And ETHTOOL_PHY_STUNABLE has not been added to netlink
> ethtool yet :-(
> 
> 	Andrew

My intention would be to keep the interactions as simple and
non-surprising as possible, and avoid requiring any particular ordering
or state machine between the tunables.

The boolean short-cable tunable would simply apply the preset
in one step. The LPF bandwidth and DSP EQ initial value tunables would 
be orthogonal knobs which can be set independently at any time, 
regardless of whether short-cable is enabled or not.

With this model, we don’t need to return -EINVAL for combinations or
ordering, and userspace does not need detailed error reporting. The
tunables behave more like simple setters than a mode switch, which
keeps the API predictable and avoids the need for extack or netlink
ethtool support at this point.

Fidelio

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Andrew Lunn]

> With this model, we don’t need to return -EINVAL for combinations or
> ordering, and userspace does not need detailed error reporting. The
> tunables behave more like simple setters than a mode switch, which
> keeps the API predictable and avoids the need for extack or netlink
> ethtool support at this point.

Sounds good.

       Andrew
       

Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata

[Marek Vasut]

On 4/16/26 4:30 PM, Andrew Lunn wrote:
>> With this model, we don’t need to return -EINVAL for combinations or
>> ordering, and userspace does not need detailed error reporting. The
>> tunables behave more like simple setters than a mode switch, which
>> keeps the API predictable and avoids the need for extack or netlink
>> ethtool support at this point.
> 
> Sounds good.
Fine by me too.