On Tue, 11 Feb 2025 15:04:27 +0100 Andrew Lunn <andrew@xxxxxxx> wrote: > > With net drivers having PHY managed by the firmware or DSA, there is no linux > > description of their PHYs. > > DSA should not be special, Linux is driving the PHY so it has to exist > as a linux device. > > Firmware is a different case. If the firmware has decided to hide the > PHY, the MAC driver is using a higher level API, generally just > ksetting_set etc. It would be up to the MAC driver to export its PHY > topology and provide whatever other firmware calls are needed. We > should keep this in mind when designing the kAPI, but don't need to > actually implement it. The kAPI should not directly reference a > phydev/phylink instance, but an abstract object which represents a > PHY. That's fine by me for the port representation, and I'm on the same page here. In the end, the ways for a NIC to register its interfaces would be : - phylib, as done in this series. The port is controlled by the PHY, the phy_port_ops are implemented in the PHY driver + phylib, we discover the ports based on what the PHY reports, the new port binding and the presence of an SFP phandle under the PHY. - phylink, and what I mean by phylink is actually SFP (phylink is the SFP upstream in PHY-less SFP setups, so it would create the phy_port, nothing more). what we cover here are MACs that are connected directly to an SFP cage. This is simply because phylink parses the sfp phandle, so it's an easy spot to make sure we create the NIC's port without rewriting all drivers. - NIC drivers themselves, for drivers that don't use phylink/phylib. For now this series only has the "phy_add_port" kAPI, which only really covers case 1. But netdev_add_port() can clearly be implemented as well. I'm having a hard time splitting that work in digestable chunks :( I've focused on PHY as a reference use for ports, but the end-goal clearly is a generic way to expose what interfaces a netdev has, either through PHY, SFP or firmware. Thanks, Maxime
