On Thu, Nov 26, 2020 at 06:01:35PM +0200, Baruch Siach wrote: > Hi Andrew, > > On Thu, Nov 26 2020, Andrew Lunn wrote: > > On Thu, Nov 26, 2020 at 05:37:22PM +0200, Baruch Siach wrote: > >> I am trying to retrieve all MAC supported link modes > >> (ETHTOOL_LINK_MODE_*) for network interfaces with SFP port. The > >> 'supported' bit mask that ETHTOOL_GLINKSETTINGS provides in > >> link_mode_masks[] changes to match the SFP module that happens to be > >> plugged in. When no SFP module is plugged, the bit mask looks > >> meaningless. > > > > That sounds like it is doing the correct thing. > > > >> I understand that ETHTOOL_LINK_MODE_* bits are meant to describe PHY > >> level capabilities. So I would settle for a MAC level "supported rates" > >> list. > > > > What is your use cases? > > I would like to report the port supported data rates to the system > user. I need to tell whether 10Gbps SFP module are supported in that > port in a generic way. The driver has this information. It is necessary > to implement the validate callback in phylink_mac_ops. But I see no way > to read this information from userspace.
If we want to know whether 10Gbps SFPs are supported in a cage, and that information is important, we really ought to use a different DT compatible for it. I've debated about using "sff,sfp+" since that's what they are - but I have no use practical for it, so I've not made the change. This is especially important as there are boards out there (Macchiatobin) where the SFP+ sockets do not support SFP modules from the electrical point of view, and if you happen to plug in a SFP module, you may end up with its EEPROM being corrupted merely as a result of plugging the module in and the ID trying to be read. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!