Re: [PATCH] net: dsa: qca8k: Disable mgmt Ethernet for qca8327

[Luiz Angelo Daros de Luca]

Hi everyone,

To add to this thread, there are a couple of other well-documented
issues tied to management Ethernet in qca8k:

1) TP-Link Archer C7 v2 (dual CPU ports 0 and 6): One CPU port becomes
muted/unusable during setup when state transitions alter the
management conduit. (ref:
https://github.com/openwrt/openwrt/pull/24011)
2) CZ.NIC Turris 1.0 and 1.1: Internal PHY access via management
frames leaks onto the external MDC/MDIO pins, corrupting communication
between the kernel and the external WAN PHY (commit 526c8ee was
insufficient to fully fix this). (ref:
https://github.com/openwrt/openwrt/pull/24755)

There are also several historical reports for other TP-Link Archer
devices (single CPU port) where ports randomly drop after some uptime,
exhibiting similar symptoms Michał described. At least for the two
cases I cited before, bypassing Ethernet-based PHY management and
sticking to MDIO works around the issue reliably.

As noted in Turris 1.0 PR patch, when the switch translates an
Ethernet management frame into an internal MDIO transaction, that
signal leaks onto the external MDC/MDIO lines. Because the switch acts
as an MDIO master for that internal query while the host CPU remains
the primary MDIO master, electrical bus conflict might break the
switch's internal MDIO translator state machine. Commit 526c8ee
attempted to solve this by acquiring bus->mdio_lock before
transmitting management frames, but software-level locking cannot
prevent hardware-level bus contention or state corruption if
QCA8K_MDIO_MASTER_EN toggles or leaks while lines are shared.

This raises the question: does Ethernet-based PHY access actually
yield any meaningful performance benefit (or is it worth it)? PHY
polling occurs at a low frequency. Also, maintaining a dual code path
(Ethernet management with silent fallback to direct MDIO)
significantly complicates troubleshooting. By comparison, drivers like
rtl8365mb enforce a single, deterministic code path for register/PHY
accesses to keep behavior predictable across all boards, even when we
could use an optimized path.

Given that Ethernet management frames for PHY access introduce
multiple hard-to-diagnose regressions across different board
topologies, should we consider dropping qca8k_phy_eth_command()
entirely in favor of direct MDIO, or at least providing a mechanism to
disable it? If MIB access becomes an issue, we could introduce a cache
mechanism.

Best regards,

Luiz