Re: ethtool settings and SFP modules with PHYs

[Maxime Chevallier <maxime.chevallier@bootlin.com>]

On Mon, 16 Sep 2024 18:12:32 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > A notification would indeed be better, and is something I can prototype
> > quickly. I was hesitating to add that, but as you show interest in
> > this, I'm OK to move forward on that :)  
> 
> This might need further brainstorming. What are we actually interested
> in?
> 
> The EEPROM has been read, we know what sort of SFP it is?
> 
> It happens to be a copper SFP, we know what MDIO over I2C protocol to
> use, it responds, and the PHY device has been created? Does the SFP
> layer actually know this? Are we actually adding a notification for
> any PHY, not just an SFP PHY?

What I was refering to is to notify on a phy_link_topo_add_phy() call,
which deals with both "regular" PHYs and SFP PHYs.

I'm still not fully expert on the netlink aspect, but could
ETHTOOL_A_PHY_NTF be emitted upon PHY addition to the topology,
containing exactly the same info as a regular ETHTOOL_A_PHY_GET message
?

At that time, we know what PHY it is, and that it's attached to the
netdev, the eeprom has been read and phydev created.

That covers the PHY aspect, but not the whole SFP aspect. We won't get
that notif for Fibre modules, as there's no PHY.

Triggering notifications upon SFP insertion will require extra
plumbing. As of today, the sfp-bus itself doesn't know which netdev
it's attached to (there's not sfp_bus.netdev pointer), so a notif won't
help much as we don't know which interface the event concerns.

That attachment can happen at link-up time or probe-time, so for example
there might be no easy way to trigger that notification when a module
is inserted while the link is down, that behaviour would depend on the
driver(s) (wether or not it uses phylink, whether or not the SFP is
driver by a PHY or directly by the MAC).

I have prototype code here[1] (beware, one giant hard-to-read patch
without commit log for now, will be split eventually) that deals with
parts of that issue, the end-goal being to report the state of all
front-facing ports (including SFP and their module) to users.

Maxime

[1] : https://github.com/minimaxwell/linux/tree/mc/main