Re: [PATCH RESEND net-next v17 00/10] net: phy_port: SFP modules representation and phy_port listing

[Aleksei Sviridkin <f@lex.la>]

Hi Maxime,

I ran v17 on a Keenetic KN-1012 (MT7981B + MT7531). Switch port 5
(lan4) goes either to an SFP cage or to an EN8811H copper PHY, and the
bootloader picks one devicetree variant per boot. The series was
backported to OpenWrt's 6.18 kernel together with the phy_port base and
its fixes, with PROVE_LOCKING and DEBUG_ATOMIC_SLEEP enabled.

Copper variant: lan4 lists one mdi port, id 1, with 100/1000/2500baseT,
the same modes the PHY reports. The EN8811H attaches late, after the
netdev is registered, because it waits for its firmware. The port still
shows up, and traffic passes. The other user ports each list one mdi
port.

With a small netlink client I also checked the calls the ethtool CLI
can't make. An unfiltered dump returns the five ports and then DONE.
A dump filtered on a netdev without a topology returns nothing and a
clean DONE. A DO with a valid PORT_ID returns the port. An unknown id
gives ENODEV, id 0 gives ERANGE from the policy, and a request with no
id gives EINVAL. lockdep stayed clean and debug_locks stayed 1.

SFP variant, with the cage port and a module port:

  Port for lan4:
          Port id: 1
          Supported MII interfaces : sgmii, 1000base-x, 2500base-x
          Port type: sfp

  Port for lan4:
          Port id: 3
          Upstream id: 1
          Supported link modes:  2500baseX/Full
                                 1000baseX/Full
          Port type: mdi

That is a passive DAC. A GPON ONU stick gives 1000baseX/Full, and
phylink moves to 1000base-x. On every removal the module port goes away
and the cage port stays. Every insert gets a new id, with no stale or
duplicate entry. I tried a replug within one second, two fast
out/in cycles, and swapping the DAC for the ONU with no pause. The
double cycle didn't manage an insert while the previous probe was still
running, since a hand can't beat the ~0.9s probe. lockdep stayed clean
throughout.

Over the DAC at 1000base-X to a UniFi UDR7 (whose SFP+ path goes
through its CPU), iperf3 gives 926 Mbit/s board to UDR7 and 606 Mbit/s
back, with no interface errors, no link drops and lockdep clean. I also pulled
the DAC while a ping6 flood was running and plugged it back in: the
module port went away, came back with a new id, and the link and
traffic recovered.

Not covered:
- A module with its own PHY (06/10): neither of my modules probed one.
- A dump that spans more than one skb: five ports fit in one.

Three notes:

The ethtool branch linked in the cover still reads PORT_VACANT and a u8
port type, while v17 has UPSTREAM_PORT (u32) in that slot and a u32
type. I adapted it locally. Could you push the ethtool you used for the
cover letter?

The raw supported-modes of a PHY's default port also carry the
Autoneg, TP and MII bits, e.g. "... 1000baseT/Full Autoneg TP MII
2500baseT/Full" on lan4. ethtool hides them, but MII on an mdi port
looks odd to anyone reading the attribute directly. Is that intended?

A module port follows the netdev's admin state rather than module
presence. With lan4 down, a module sitting in the cage isn't listed,
because sfp_module_stop() runs phylink_del_sfp_mod_port(). After ifup
it comes back under a new id, so every ifdown/ifup renumbers it. Is
that intended? From userspace, "port 3 upstream 1" isn't stable across
an ifup.

Tested-by: Aleksei Sviridkin <f@lex.la>

Aleksei