This contains a number of changes deferred from part 1 (patches 1-6):
https://lore.kernel.org/linux-phy/20251125114847.804961-1-vladimir.oltean@nxp.com/

They are reworked in ways detailed in their individual change logs.

I have a special request to linux-phy maintainers: after merging, please
provide a stable branch/tag of this plus part 1, that can be pulled into
netdev. It is needed because phy_exit() calls from consumers would
compile but would cause a functionally broken link, so we need a linear
git history to avoid (temporary) regressions.

Ioana Ciornei (1):
  phy: lynx-28g: add support for 25GBASER

Vladimir Oltean (7):
  phy: lynx-28g: skip CDR lock workaround for lanes disabled in the
    device tree
  dt-bindings: phy: lynx-28g: add compatible strings per SerDes and
    instantiation
  dt-bindings: phy: lynx-28g: add constraint on LX2162A lane indices
  phy: lynx-28g: probe on per-SoC and per-instance compatible strings
  phy: lynx-28g: use timeouts when waiting for lane halt and reset
  phy: lynx-28g: truly power the lanes up or down
  phy: lynx-28g: implement phy_exit() operation

 .../devicetree/bindings/phy/fsl,lynx-28g.yaml |  50 ++-
 drivers/phy/freescale/phy-fsl-lynx-28g.c      | 418 ++++++++++++++++--
 2 files changed, 420 insertions(+), 48 deletions(-)

-- 
2.34.1

Hello PHY maintainers,

On Wed, Jan 14, 2026 at 05:21:03PM +0200, Vladimir Oltean wrote:
> This contains a number of changes deferred from part 1 (patches 1-6):
> https://lore.kernel.org/linux-phy/20251125114847.804961-1-vladimir.oltean@nxp.com/
> 
> They are reworked in ways detailed in their individual change logs.
> 
> I have a special request to linux-phy maintainers: after merging, please
> provide a stable branch/tag of this plus part 1, that can be pulled into
> netdev. It is needed because phy_exit() calls from consumers would
> compile but would cause a functionally broken link, so we need a linear
> git history to avoid (temporary) regressions.

Given how close to the merge window we are, I am dropping my special
request for a stable tag. But can you please take a look at this until
the merge window opens? It will simplify further development to have it
for v6.20 (or whatever next release number will be).