From: Fidelio LAWSON <lawson.fidelio@gmail.com>
To: Marek Vasut <marex@nabladev.com>,
Woojung Huh <woojung.huh@microchip.com>,
UNGLinuxDriver@microchip.com, Andrew Lunn <andrew@lunn.ch>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Marek Vasut <marex@denx.de>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Simon Horman <horms@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Fidelio Lawson <fidelio.lawson@exotec.com>
Subject: Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
Date: Tue, 14 Apr 2026 13:59:17 +0200 [thread overview]
Message-ID: <4f009fa6-5fe1-4ba9-bacb-1bd8de820a98@gmail.com> (raw)
In-Reply-To: <ea90a671-70be-4d89-b842-1e54d687336f@nabladev.com>
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.
next prev parent reply other threads:[~2026-04-14 11:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 9:12 [PATCH v3 0/3] ksz87xx: add support for low-loss cable equalizer errata Fidelio Lawson
2026-04-14 9:12 ` [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata Fidelio Lawson
2026-04-14 11:05 ` Marek Vasut
2026-04-14 11:59 ` Fidelio LAWSON [this message]
2026-04-14 12:40 ` Andrew Lunn
2026-04-14 13:48 ` Fidelio LAWSON
2026-04-14 14:54 ` Andrew Lunn
2026-04-14 15:50 ` Marek Vasut
2026-04-14 15:49 ` Marek Vasut
2026-04-16 11:53 ` Fidelio LAWSON
2026-04-16 12:25 ` Andrew Lunn
2026-04-16 14:25 ` Fidelio LAWSON
2026-04-16 14:30 ` Andrew Lunn
2026-04-16 15:05 ` Marek Vasut
2026-04-14 9:12 ` [PATCH v3 2/3] net: ethtool: add KSZ87xx low-loss PHY tunable Fidelio Lawson
2026-04-14 9:12 ` [PATCH v3 3/3] net: phy: micrel: expose KSZ87xx low-loss erratum via " Fidelio Lawson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4f009fa6-5fe1-4ba9-bacb-1bd8de820a98@gmail.com \
--to=lawson.fidelio@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fidelio.lawson@exotec.com \
--cc=hkallweit1@gmail.com \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=marex@denx.de \
--cc=marex@nabladev.com \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=woojung.huh@microchip.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox