Hi Maxime, On 2/7/25 17:36, Maxime Chevallier wrote:
Hello everyone, This series follows the 2 RFC that were sent a few weeks ago : RFC V2: https://lore.kernel.org/netdev/20250122174252.82730-1-maxime.chevallier@xxxxxxxxxxx/ RFC V1: https://lore.kernel.org/netdev/20241220201506.2791940-1-maxime.chevallier@xxxxxxxxxxx/ The goal of this series is to introduce an internal way of representing the "outputs" of ethernet devices, for now only focusing on PHYs. This allows laying the groundwork for multi-port devices support (both 1 PHY 2 ports, or more exotic setups with 2 PHYs in parallel, or MII multiplexers). Compared to the RFCs, this series tries to properly support SFP, especially PHY-driven SFPs through special phy_ports named "serdes" ports. They have the particularity of outputing a generic interface, that feeds into another component (usually, an SFP cage and therefore an SFP module). This allows getting a fairly generic PHY-driven SFP support (MAC-driven SFP is handled by phylink). This series doesn't address PHY-less interfaces (bare MAC devices, MACs with embedded PHYs not driven by phylink, or MAC connected to optical SFPs) to stay within the 15 patches limit, nor does it include the uAPI part that exposes these ports to userspace. I've kept the cover short, much more details can be found in the RFC covers. Thanks everyone, Maxime
Forgive me for my ignorance, but why have a new ethtool interface instead of extending ethtool_link_settings.port? It's a rather ancient interface, but it seems to be tackling the exact same problem as you are trying to address. Older NICs used to have several physical connectors (e.g. BNC, MII, twisted-pair) but only one could be used at once. This seems directly analogous to a PHY that supports multiple "port"s but not all at once. In fact, the only missing connector type seems to be PORT_BACKPLANE. I can think of a few reasons why you wouldn't use PORT_*: - It describes the NIC and not the PHY, and perhaps there is too much impedance mismatch? - There is too much legacy in userspace (or in the kernel) to use that API in this way? - You need more flexibility? At the very least, I think some discussion in one of the commits would be warranted. Perhaps there was some on the RFC that I missed? --Sean
