From: Fidelio LAWSON <lawson.fidelio@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Woojung Huh <woojung.huh@microchip.com>,
UNGLinuxDriver@microchip.com, 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>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Marek Vasut <marex@denx.de>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Fidelio Lawson <fidelio.lawson@exotec.com>
Subject: Re: [PATCH 1/3] dt-bindings: dsa: microchip: add KSZ low-loss cable errata properties
Date: Fri, 3 Apr 2026 10:28:08 +0200 [thread overview]
Message-ID: <72c9a165-74bb-42a5-b5fe-67bfa2c8ce2e@gmail.com> (raw)
In-Reply-To: <521cf729-50d2-44c1-8c96-c1fba2127b9d@lunn.ch>
On 3/26/26 13:14, Andrew Lunn wrote:
> On Thu, Mar 26, 2026 at 10:10:21AM +0100, Fidelio Lawson wrote:
>> Microchip KSZ87xx switches are affected by the "Module 3: Equalizer fix
>> for short cables" erratum described in DS80000687C.
>> The embedded PHY receivers are tuned for long, high-loss cables,
>> which may cause signal distortion when operated with short or low-loss
>> cabling such as CAT5e or CAT6. In these cases,
>> the PHY may fail to establish a link due to internal over-amplification.
>>
>> Two workarounds are provided by Microchip, each configuring a different
>> indirect register value to adjust the PHY equalizer settings.
>>
>> This patch introduces two new device tree properties to enable and
>> select the appropriate workaround:
>>
>> - microchip,low-loss-errata-enable: boolean enabling the feature
>> - microchip,low-loss-errata: selects workaround 1 or 2 (default: 1)
>>
>> These properties allow board designers to opt into the errata fix
>> according to the targeted cable characteristics of their platform.
>
> Does the errata give any indication how the two different workarounds
> differ? How would a user decided which to use?
>
> I also question if this should be a DT property. The length of the
> cables is not a property of the board.
>
> A PHY tunable would better reflect the same board can be used with
> different cables, with different lengths/quality.
>
> Andrew
Hi Andrew,
Thanks for the review.
Regarding the difference between the two workarounds:
Microchip’s errata does provide some insight into how they behave and
when each should be used.
Workaround 1 modifies the PHY equalizer settings by adjusting an
indirect register (0x3c).
According to Microchip’s support article:
“The above register change makes the equalizer’s compensation range
wider, and therefore cables with various characteristics can be
tolerated. Adjust equalizer EQ training algorithm to cover a few type of
short cables issue. Also is appropriate for board‑to‑board connection
and port‑to‑port connection with the capacitor AC coupling mode.”
Microchip also explains that although the default value in register 0x3c
handles standard short Ethernet cables (CAT‑5/CAT‑5e), a more optimized
value (0x15) provides better tolerance for corner cases, especially very
short or board‑to‑board links:
“Based on tests, a more optimized equalizer adjustment value 0x15 is
better for all corner cases of the short cable and short distance
connection for port‑to‑port or board‑to‑board cases.”
So Workaround 1 primarily widens and optimizes the DSP equalizer EQ
compensation range, and is expected to solve most short/low‑loss cable
issues.
Workaround 2 is intended 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:
“Based on the root cause above, adjust the receiver low pass filter to
reduce the high frequency component to keep the receive signal within a
reasonable range when using CAT‑5E and CAT‑6 cable.”
So Workaround 2 is a more aggressive filtering approach, applied only
when the EQ adjustment alone does not stabilize the link on CAT‑5e/CAT‑6
short cable scenarios.
Regarding the question of whether this should be exposed through a PHY
tunable:
I understand your concern. The erratum is indeed linked to cable
characteristics, not the board itself.
Since this patch modifies registers that belong to the DSA switch
itself, and not the PHY driver, I’m not entirely sure it would be
architecturally correct to expose these adjustments as PHY tunables. The
workarounds target internal receiver/equalizer settings inside the
KSZ87xx switch block, accessed via the switch’s indirect register
mechanism, not via a standard phy_device.
Given that, I’m unsure whether mapping these switch‑level registers into
the PHY tunables framework would be appropriate or even feasible.
What do you think?
Best regards,
Fidelio
next prev parent reply other threads:[~2026-04-03 8:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-26 9:10 [PATCH 0/3] ksz87xx: add support for low-loss cable equalizer errata Fidelio Lawson
2026-03-26 9:10 ` [PATCH 1/3] dt-bindings: dsa: microchip: add KSZ low-loss cable errata properties Fidelio Lawson
2026-03-26 10:33 ` Rob Herring (Arm)
2026-03-26 12:14 ` Andrew Lunn
2026-04-03 8:28 ` Fidelio LAWSON [this message]
2026-04-04 14:21 ` Andrew Lunn
2026-03-26 9:10 ` [PATCH 2/3] net: dsa: microchip: parse KSZ87xx low-loss errata from DT Fidelio Lawson
2026-03-26 9:10 ` [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata Fidelio Lawson
2026-03-26 9:42 ` Vladimir Oltean
2026-03-27 14:47 ` Bastien Curutchet
2026-03-27 14:55 ` Marek Vasut
2026-03-27 15:38 ` Bastien Curutchet
2026-04-03 9:35 ` Fidelio LAWSON
2026-03-26 12:18 ` Andrew Lunn
2026-04-03 9:43 ` Fidelio LAWSON
2026-04-04 14:45 ` Andrew Lunn
2026-03-26 12:38 ` Marek Vasut
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=72c9a165-74bb-42a5-b5fe-67bfa2c8ce2e@gmail.com \
--to=lawson.fidelio@gmail.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=fidelio.lawson@exotec.com \
--cc=krzk+dt@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marex@denx.de \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--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