On Mon, Feb 17, 2025 at 09:29:11AM +0100, Maxime Chevallier wrote: > Hello Russell, > > On Sat, 15 Feb 2025 18:57:01 +0000 > "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx> wrote: > > > On Thu, Feb 13, 2025 at 11:15:53AM +0100, Maxime Chevallier wrote: > > > Some PHY devices may be used as media-converters to drive SFP ports (for > > > example, to allow using SFP when the SoC can only output RGMII). This is > > > already supported to some extend by allowing PHY drivers to registers > > > themselves as being SFP upstream. > > > > > > However, the logic to drive the SFP can actually be split to a per-port > > > control logic, allowing support for multi-port PHYs, or PHYs that can > > > either drive SFPs or Copper. > > > > > > To that extent, create a phy_port when registering an SFP bus onto a > > > PHY. This port is considered a "serdes" port, in that it can feed data > > > to anther entity on the link. The PHY driver needs to specify the > > > various PHY_INTERFACE_MODE_XXX that this port supports. > > > > > > Signed-off-by: Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx> > > > > With this change, using phy_port requires phylink to also be built in > > an appropriate manner. Currently, phylink depends on phylib. phy_port > > becomes part of phylib. This patch makes phylib depend on phylink, > > thereby creating a circular dependency when modular. > > > > I think a different approach is needed here. > > That's true. > > One way to avoid that would be to extract out of phylink/phylib all the > functions for linkmode handling that aren't tied to phylink/phylib > directly, but are about managing the capabilities of each interface, > linkmode, speed, duplex, etc. For phylink, that would be : > > phylink_merge_link_mode > phylink_get_capabilities > phylink_cap_from_speed_duplex > phylink_limit_mac_speed > phylink_caps_to_linkmodes > phylink_interface_max_speed > phylink_interface_signal_rate > phylink_is_empty_linkmode > phylink_an_mode_str > phylink_set_port_modes > > For now all these are phylink internal and that makes sense, but if we want > phy-driven SFP support, stackable PHYs and so on, we'll need some ways for > the PHY to expose its media-side capabilities, and we'd reuse these. > > These would go into linkmode.c/h for example, and we'd have a shared set > of helpers that we can use in phylink, phylib and phy_port. > > Before I go around and rearrange that, are you OK with this approach ? I'm not convinced. If you're thinking of that level of re-use, you're probably going to miss out on a lot of logic that's in phylink. Maybe there should be a way to re-use phylink in its entirety between the PHY and SFP. Some of the above (that deal only with linkmodes) would make sense to move out though. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
