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]
Date:   Wed, 8 Aug 2018 14:29:23 +0100
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Marek BehĂșn <marek.behun@....cz>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: Is it currently possible to connect SFP to dsa port?

On Wed, Aug 08, 2018 at 03:00:13PM +0200, Marek BehĂșn wrote:
> Btw: some SFP modules can operate in 2500BASE-X mode. Currently the SFP
> driver does not support this, and there even isn't code in the
> mainline kernel for mvneta to switch to 2500BASEX. On Armada 3720 this
> has to be done by configuring comphy, which is currently done in
> u-boot. As a side project I am working on supporting Armada 3720 comphy
> in the kernel, so that it will be possible to set 2500BASE-X mode.

With mvneta, it works the same way as other Marvell stuff - the comphy
needs to be told to up-clock the 1000base-X to 2500base-X.  That's all
that 2500base-X is - an up-clocked 1000base-X.

With Armada 388, it's just a matter of poking one register to configure
the comphy to 2500base-X.

As mvneta has no support for comphys, and I don't have the full details
for the comphy stuff, I've not bothered implementing anything for mvneta
other than some bare bones support in my repository to support the mode,
and resorting to poking the comphy register with devmem2 as required.

However, I can assure you that SFP definitely does support 2500base-X.
As 2500base-X is rather unofficial (there's no 802.3 standard for it)
there's no bits in SFP module eeprom that identify a module as
supporting this mode.

Consequently, the only way I'm aware of is to detect a Fibrechannel
SFP which supports the range of bitrates that would allow this mode
to work.  Currently, the code does this:

        /* For fibre channel SFP, derive possible BaseX modes */
        if (id->base.fc_speed_100 ||
            id->base.fc_speed_200 ||
            id->base.fc_speed_400) {
                if (id->base.br_nominal >= 31)
                        phylink_set(modes, 2500baseX_Full);
                if (id->base.br_nominal >= 12)
                        phylink_set(modes, 1000baseX_Full);
        }

So, the SFP core supports it.  What's expected from network drivers is
that they say they support 2500base-X, and then things get rather icky.
There is no way to autonegotiate between 2500base-X and 1000base-X.

What results is ultimately up to the driver implementation, but how I
have it locally via a local "phylink: add helper for configuring
2500BaseX modes" commit is:

- report 2500baseX_Full and 1000baseX_Full as supported to userspace.
- if both 2500baseX_Full and 1000baseX_Full are attempted to be set
   as advertised modes, clear 1000baseX_Full.
- select PHY_INTERFACE_MODE_2500BASEX or PHY_INTERFACE_MODE_1000BASEX
   depending whether the resulting advertising mask wants 2500baseX_Full
   or 1000baseX_Full.  If manual speed configuration, select between
   the PHY interface modes according to the requested speed.

With the exception of this commit (which is probably going to provoke
discussion about exactly what semantics we want) the SFP and phylink
code is all in place to support 2500base-X - I've proved it out using
a Macchiatobin (with the Marvell mvpp2x driver) and a Clearfog.

Without this patch, we detect in sfp_parse_support() that the module
is capable of 2500base-X, and, provided the network interface supports
2500base-X, sfp_select_interface() will select the 2500base-X PHY
interface mode, otherwise it'll select 1000base-X mode.

> The mv88e6190/6390 can configure ports 9 and 10 to either
> 1000BASE-X/SGMII od 2500BASE-X, but this has to be done by setting a
> pin and reseting the switch. Our board is able to configure this pin,
> and the plan is to do this in u-boot when SFP board is detected to be
> connected to the switch board. In this case the port is configured to
> 1000BASE-X.

It's really not that simple, unfortunately.  If you are talking about
pluggable SFPs (btw, SFP itself means the hot-pluggable modules, not
the soldered down modules, although we support both), SFP modules can
require *either* 1000base-X or SGMII.  There are some copper modules
with a PHY on board that want 1000base-X, but the vast majority of
copper modules want SGMII.  Conversely, gigabit fiber modules want
1000base-X.

Even more annoying, there is nothing that definitively tells you which
mode you should be using - and if you use the wrong mode, it may or
may not work, and you may or may not end up with a mismatched config
at either end of the link.

So, merely detecting a SFP modules presence doesn't tell you which
mode you should be in - and the annoying part is, if you hotplug the
module, you might need to change the port mode.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ