public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
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


  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