On Wed, Jul 08, 2026 at 12:08:14AM +0200, Markus Breitenberger wrote:

Hi Andrew,

Thanks for looking at this, and you're right - the runtime case is the
more dangerous one. If a genuine interface change (SGMII <-> 2500BASE-X)
happened at runtime while the disk was live, reprogramming the shared
ModPHY LCPLL would disturb the SATA PHY under an active filesystem, and
a failed boot would be preferable to that.

Two points of clarification:

- A plain switch change does not reprogram the ModPHY on my fixed-PHY
  setup. mac_finish() only runs a real reconfiguration when the
  MAC-side interface mode changes (e.g. a multi-rate SFP moving between
  SGMII and 2500BASE-X).

A fibre SFP is unlikely to use SGMII. It will swap between 2500BaseX
and 1000BaseX, if the SFP module is ejected and a different one
plugged in.

On a fixed copper PHY the interface mode does
  not change, so changing the link partner / switch does not trigger
  the reconfiguration.

That depends on the PHY. Some change there host side interface to
match the line side. So they use 25000BaseX for 2.5G, but SGMII for
10/100/1G. Other use 'rate-adaptation'. They run the host side at the
fastest speed, 25000BaseX, and then insert pause frames to slow down
the MAC when the line side is running at 10/100/1G.

Given that, I'd like to keep this patch scoped to the boot regression
and leave the pre-existing shared-ModPHY-with-live-SATA question to the
maintainers, who have the hardware knowledge to decide whether a
stronger guard is warranted.

a42f6b3f1cc1 is from Intel, so i assume they thought about what
happens to the SATA controller, and are happy to take the risk of
destroying filesystems. So, yes, lets leave it as is for the moment.

	   Andrew