Re: [PATCH v2 net-next 7/7] net: dsa: mediatek: support EN751221 switch

[Cristian Papa <pcristian292@gmail.com>]

On Sun, 20 Sep 2026 12:33:21 +0200, Benjamin Larsson wrote:
> Thus I suggest that dts property also is added and that the calibration
> is performed if that property is not present.
>
> The original SDK and production units seem to have a fixed setting and
> user testing also indicate that a fixed value results in a working
> trgmii link.

Some of that user testing may be mine (fixed RX taps on an XR500v in
Matheus Sampaio Queiroga's airoha tree, airoha/kernel PR #54 on his
Gitea, https://sirherobrine23.com.br/airoha/kernel/pulls/54 - viewing
it needs a login there), so here are the numbers behind it. One unit:
TP-Link Archer XR500v v1 (EN7526G, on-die switch plus MCM), running
that tree's driver on Linux 6.18, not v2.

That driver uses the same PLL frequency (362.5 MHz) and TX drive values
as v2, but the rest of the sequence differs. v2 sets the MCM TX delay
to 0 (it reads 8 here), writes RCK_RTT and 0x7a14 on the on-die side
and disables SSC on the MCM; that driver does none of that and instead
writes the full vendor MTRAP word (0x01017e8f, between TOP_SIG_CTRL 0
and 1) on both switches, where v2 only changes individual MTRAP bits,
and the vendor CKGCR value (0x30f0 = 0x1e02) on the MCM, which v2 does
not touch. So the taps may shift with v2.

With the 0x55 pattern, sweeping RD_TAP from 1, all five lanes pass up
to tap 37-45 for SoC->MCM and up to tap 16-18 for MCM->SoC (one boot).
The eye with real traffic is much narrower. With all lanes on the same
tap, iperf3 through the cascade and the RX CRC counter of the receiving
port (same result on two boots):

  SoC->MCM (MCM port 6):    clean up to tap 24, nearly dead at 28
                            (1-6 Mbit/s with CRC errors), dead from 32
  MCM->SoC (on-die port 5): clean up to tap 10, CRC errors at 12,
                            unusable from 14 to 64, and a second
                            narrow eye around 72

Tap 1, the lowest I tried, was clean in both directions, so the lower
edge of the eye never showed up. The midpoints of the 0x55 windows
(19-23 and 8-9 here) are only 1-5 and 1-2 taps below the last clean
tap measured.

That driver uses RX tap 4 in both directions (for SoC->MCM the 0x55
sweep still runs, as a check). With it, 12 boots (8 warm reboots and 4
power cycles of about 30 s) had 0 CRC errors on both cascade ports
after 6 s of iperf3 each way, 29k-101k frames per direction. One value
(4) works for both directions here, although the margin to the last
clean tap differs (about 20 taps vs 6).

Separately: an out-of-tree U-Boot port for this board (since fixed)
left the on-die switch's PHY auto-polling on (AP_EN in PPSC, 0x7018).
With it on, 8 of 240 TFTP boots trained no SoC->MCM lane until the
switch was re-probed, and a stress test found repeated tap writes
landing in the MCM's 0x7a04 (4 of 4 boots, 0 of 4 with AP_EN off).
Clearing AP_EN before registering the MDIO bus gave 120 of 120 boots
with all lanes trained. In v2 the on-die switch is set up (and reset)
before the MCM, which should clear it, but I have not tested that; it
may matter if v3 touches the MCM earlier.

Per-boot logs on request. Happy to test whichever approach v3 takes.

Thanks,
Cristian