Getting a fix into net.git: mv88e6xxx and the missing PTP

Side effect of putting OpenWrt on a Sophos XGS 107w: its Marvell 88E6193X switch wouldn't probe under a recent kernel. Chasing that down turned into a net: dsa: mv88e6xxx fix, reviewed by Marvell switch driver maintainer Andrew Lunn and merged into net.git by netdev maintainer Jakub Kicinski.

The failure

Booting a mainline kernel against the XGS 107w's switch produced:

mv88e6xxx ...: unexpected cycle counter period of 0 ps

and the switch never probed — no ports, nothing. The 88E6193X is a 6393-family part, and the driver's mv88e6xxx_table entry for it points at mv88e6393x_ops with ptp_support = true. Since 7e3c18097a70 ("net: dsa: mv88e6xxx: read cycle counter period from hardware"), PTP setup reads that period straight from the TAI (Time Application Interface) hardware registers — and on this chip, that register reads back zero.

Root cause

The 88E6191X and 88E6193X share mv88e6393x_ops with the 88E6393X, which does have PTP and AVB. But Marvell's own UMSD reference driver describes the 88E6193X's package as "No AVB, No Routing, No Cut-through" — and reading the actual hardware on the reference unit confirmed it directly: the whole indirect AVB register space behind Global 2 registers 0x16/0x17 read zero for every port, block and address, tried with both the 6390 and 6352 command encodings. Writes to the TAI registers — including the clock period register the new probe code reads — read back as zero too. The chip has no AVB or PTP block at all; the driver was just assuming it did because it shares an ops struct with a sibling that does.

From workaround to real fix

The first attempt was a narrower workaround — just enough to stop the probe from reading a period of zero. Andrew Lunn, one of the mv88e6xxx maintainers, suggested the actual fix instead: give the 88E6191X and 88E6193X their own ops struct. Suggested-by on the final patch is his.

mv88e6191x_ops is a copy of mv88e6393x_ops with avb_ops and ptp_ops left out, and ptp_support dropped from both table entries:

-		.ptp_support = true,
-		.ops = &mv88e6393x_ops,
+		.ops = &mv88e6191x_ops,

(applied to both the MV88E6191X and MV88E6193X entries in mv88e6xxx_table). The 88E6393X itself is untouched — it keeps mv88e6393x_ops and real PTP support. Tested on the reference 88E6193X: the switch probes and every port works. There's no 88E6191X on hand to test directly, but UMSD describes it the same way as the 88E6193X, so it gets the same treatment.

Review and merge

Sent to netdev as [PATCH net v2], tagged Fixes: de776d0d316f since that's the commit that turned a latent assumption into an actual probe failure. Andrew Lunn reviewed it (Reviewed-by), and it was picked up by Jakub Kicinski — the netdev subsystem maintainer — into net.git:

net: dsa: mv88e6xxx: 88E6191X and 88E6193X have no PTP →

Timeline

Both series — the netdev fix above and a 3-patch series adding the Sophos vendor prefix and a device tree for the XGS 107w's Marvell CN9130 NPU board, sent to the mvebu/dt tree — went out together and were reviewed in parallel:

Device-tree patch 1/3 (the sophos vendor prefix) already had Krzysztof Kozlowski's Acked-by from the v1 review on 2026-09-20, carried unchanged into v2.

Device tree: signed off, not applied yet

As of 2026-09-28, all three device-tree patches have every reviewer's sign-off they need — 1/3 and 2/3 Acked-by Krzysztof Kozlowski, 3/3 Reviewed-by Andrew Lunn — but no Marvell/mvebu maintainer (Gregory Clement, Andrew Lunn or Sebastian Hesselbarth) has applied them to their tree yet. That's the one open item, no date yet. All four patches, the cover letter and the checks run on them are in the project repo's upstream/ directory.

Full project background: the Sophos XGS 107w docs page and the OpenWrt write-up.