netdev - Re: [PATCH net-next 2/2] net: sfp: add quirk for 2.5G copper SFP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZB8Upcgv8EIovPCl@makrotopia.org>
Date:   Sat, 25 Mar 2023 15:35:01 +0000
From:   Daniel Golle <daniel@...rotopia.org>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Frank Wunderlich <frank-w@...lic-files.de>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net-next 2/2] net: sfp: add quirk for 2.5G copper SFP

On Sat, Mar 25, 2023 at 02:05:51PM +0000, Russell King (Oracle) wrote:
> On Sat, Mar 25, 2023 at 02:12:16AM +0000, Daniel Golle wrote:
> > Hi Russell,
> > 
> > On Tue, Mar 21, 2023 at 04:58:51PM +0000, Russell King (Oracle) wrote:
> > > Add a quirk for a copper SFP that identifies itself as "OEM"
> > > "SFP-2.5G-T". This module's PHY is inaccessible, and can only run
> > > at 2500base-X with the host without negotiation. Add a quirk to
> > > enable the 2500base-X interface mode with 2500base-T support, and
> > > disable autonegotiation.
> > > 
> > > Reported-by: Frank Wunderlich <frank-w@...lic-files.de>
> > > Tested-by: Frank Wunderlich <frank-w@...lic-files.de>
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
> > 
> > I've tried the same fix also with my 2500Base-T SFP module:
> > diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
> > index 4223c9fa6902..c7a18a72d2c5 100644
> > --- a/drivers/net/phy/sfp.c
> > +++ b/drivers/net/phy/sfp.c
> > @@ -424,6 +424,7 @@ static const struct sfp_quirk sfp_quirks[] = {
> >         SFP_QUIRK_F("Turris", "RTSFP-10", sfp_fixup_rollball),
> >         SFP_QUIRK_F("Turris", "RTSFP-10G", sfp_fixup_rollball),
> >         SFP_QUIRK_F("OEM", "SFP-GE-T", sfp_fixup_ignore_tx_fault),
> > +       SFP_QUIRK_M("TP-LINK", "TL-SM410U", sfp_quirk_oem_2_5g),
> >  };
> > 
> >  static size_t sfp_strlen(const char *str, size_t maxlen)
> 
> Thanks for testing.
> 
> > However, the results are a bit of a mixed bag. The link now does come up
> > without having to manually disable autonegotiation. However, I see this
> > new warning in the bootlog:
> > [   17.344155] sfp sfp2: module TP-LINK          TL-SM410U        rev 1.0  sn 12154J6000864    dc 210606  
> > ...
> > [   21.653812] mt7530 mdio-bus:1f sfp2: selection of interface failed, advertisement 00,00000000,00000000,00006440
> 
> This will be the result of issuing an ethtool command, and phylink
> doesn't know what to do with the advertising mask - which is saying:
> 
>    Autoneg, Fibre, Pause, AsymPause
> 
> In other words, there are no capabilities to be advertised, which is
> invalid, and suggests user error. What ethtool command was being
> issued?

This was simply adding the interface to a bridge and bringing it up.
No ethtool involved afaik.

> 
> > Also link speed and status appears unknown, though we do know at least
> > that the speed is 2500M, and also full duplex will always be true for
> > 2500Base-T:
> > [   56.004937] mt7530 mdio-bus:1f sfp2: Link is Up - Unknown/Unknown - flow control off
> 
> I would guess this is because we set the advertising mask to be 2.5bT
> FD, and the PCS resolution (being all that we have) reports that we
> got 2.5bX FD - and when we try to convert those to a speed/duplex we
> fail because there appears to be no mutual ethtool capabilities that
> can be agreed.
> 
> However, given that the media may be doing 2.5G, 1G or 100M with this
> module, and we have no idea what the media may be doing because we
> can't access the PHY, it seems to me that reporting "Unknown" speed
> and "Unknown" duplex is entirely appropriate and correct, if a little
> odd.
> 
> The solution... obviously is to have access to the PHY so we know
> what the media is doing.

In the case of this SFP the internal PHY *only* supports 2500Base-T.
Slower links (1000M/100M/10M) simply don't come up.

I don't know the situation with the 2.5G module Frank was testing, ie.
which modes it supports on the RJ-45 interface, it could be that in his
case you are right.