From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Baruch Siach <baruch@tkos.co.il>
Cc: Andrew Lunn <andrew@lunn.ch>,
netdev@vger.kernel.org, Heiner Kallweit <hkallweit1@gmail.com>
Subject: Re: Get MAC supported link modes for SFP port
Date: Thu, 26 Nov 2020 16:13:48 +0000 [thread overview]
Message-ID: <20201126161348.GO1551@shell.armlinux.org.uk> (raw)
In-Reply-To: <87mtz4umxs.fsf@tarshish>
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!
prev parent reply other threads:[~2020-11-26 16:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-26 15:37 Get MAC supported link modes for SFP port Baruch Siach
2020-11-26 15:45 ` Russell King - ARM Linux admin
2020-11-26 15:47 ` Andrew Lunn
2020-11-26 16:01 ` Baruch Siach
2020-11-26 16:13 ` Russell King - ARM Linux admin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201126161348.GO1551@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=baruch@tkos.co.il \
--cc=hkallweit1@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.