| 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
| ||
|
Message-ID: <CAFSKS=OZzodqriVqjV_rJMrjBoDzK1rAhnU9E4FAROtt553f=w@mail.gmail.com>
Date: Thu, 23 Jan 2020 13:10:09 -0600
From: George McCollister <george.mccollister@...il.com>
To: netdev@...r.kernel.org
Cc: Russell King <linux@...linux.org.uk>, Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>
Subject: net: phy: PHY connected SFP behavior
In my September email I asked about Copper SFP modules connected
through a Marvell 88E1512 PHY to an RGMII MAC. Realizing that is off
the table until netdev can support nested PHYs, I'd like to know what
PHY driver support for SFPs (using phy_sfp_probe()) is supposed to
achieve (other than diagnostics) and how. Maybe this discussion could
even lead to some documentation.
I was expecting ethtool to show "1000baseX/Full" for "Supported link
modes" when a 1000BASE-SX SFP is installed. Is this how it's supposed
to work? Is the PHY driver supposed to use the parsed SFP information
to limit the supported modes and settings? If so where should this
occur?
I added some code to print an error and return -EINVAL if
sfp_select_interface() doesn't return PHY_INTERFACE_MODE_1000BASEX in
my .module_insert implementation. However, I notice that if I install
an RJ45 SFP it prints the error but link is actually established (and
works at 1000 full)! Even if the product ships with no RJ45 SFP
support, someone will inevitably install an RJ45 SFP, plug into a
1000BaseT switch and assume it'll work in every case. Then I'll get
calls when it doesn't work on a 100BaseT switch. Any thoughts on
how/if this should be handled?
Information reported by ethtool when the 1000BASE-SX SFP module is
installed (after running ip link set eth1 up):
ethtool eth1
Settings for eth1:
Supported ports: [ TP MII FIBRE ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: No
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
It also shows these supported link modes if no SFP module is present.
As you can see below the SFP module is 1000BASE-SX.
ethtool -m eth1
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined
by 2-wire interface ID)
Connector : 0x07 (LC)
Transceiver codes : 0x00 0x00 0x00 0x01
0x20 0x40 0x0c 0x01 0x00
Transceiver type : Ethernet: 1000BASE-SX
Transceiver type : FC: intermediate distance (I)
Transceiver type : FC: Shortwave laser w/o OFC (SN)
Transceiver type : FC: Multimode, 62.5um (M6)
Transceiver type : FC: Multimode, 50um (M5)
Transceiver type : FC: 100 MBytes/sec
Encoding : 0x01 (8B/10B)
BR, Nominal : 1300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 550m
Length (62.5um) : 300m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 850nm
Vendor name : OPTOWAY
Vendor OUI : 00:0e:fa
Vendor PN : SPM-7100AWG
Vendor rev : 0000
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : 154501267
Date code : 151104
Optical diagnostics support : Yes
Laser bias current : 4.128 mA
Laser output power : 0.2104 mW / -6.77 dBm
Receiver signal average optical power : 0.1683 mW / -7.74 dBm
Module temperature : 41.59 degrees C /
106.87 degrees F
Module voltage : 3.2744 V
Alarm/warning flags implemented : Yes
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser output power high alarm : Off
Laser output power low alarm : Off
Laser output power high warning : Off
Laser output power low warning : Off
Module temperature high alarm : Off
Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : Off
Laser rx power high warning : Off
Laser rx power low warning : Off
Laser bias current high alarm threshold : 20.000 mA
Laser bias current low alarm threshold : 1.000 mA
Laser bias current high warning threshold : 15.000 mA
Laser bias current low warning threshold : 2.000 mA
Laser output power high alarm threshold : 0.6310 mW / -2.00 dBm
Laser output power low alarm threshold : 0.1000 mW / -10.00 dBm
Laser output power high warning threshold : 0.5012 mW / -3.00 dBm
Laser output power low warning threshold : 0.1259 mW / -9.00 dBm
Module temperature high alarm threshold : 95.00 degrees C /
203.00 degrees F
Module temperature low alarm threshold : -35.00 degrees C /
-31.00 degrees F
Module temperature high warning threshold : 85.00 degrees C /
185.00 degrees F
Module temperature low warning threshold : -30.00 degrees C /
-22.00 degrees F
Module voltage high alarm threshold : 3.6000 V
Module voltage low alarm threshold : 3.0000 V
Module voltage high warning threshold : 3.5000 V
Module voltage low warning threshold : 3.1000 V
Laser rx power high alarm threshold : 0.6310 mW / -2.00 dBm
Laser rx power low alarm threshold : 0.0126 mW / -19.00 dBm
Laser rx power high warning threshold : 0.5012 mW / -3.00 dBm
Laser rx power low warning threshold : 0.0200 mW / -16.99 dBm
I'm testing with the phy branch of git://git.armlinux.org.uk/linux-arm.git
I modified marvell.c to call phy_sfp_probe() exactly like marvell10g.c.
I then modified my devicetree to include the following (note fec2 is
connected to the Marvell 88E1512 PHY that is connected to the SFP
cage):
/ {
...
sfp: sfp {
compatible = "sff,sfp";
i2c-bus = <&i2c4>;
los-gpio = <&expander0 2 GPIO_ACTIVE_HIGH>;
mod-def0-gpio = <&expander0 0 GPIO_ACTIVE_LOW>;
tx-fault-gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
maximum-power-milliwatt = <1000>;
};
};
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
phy-mode = "rgmii-id";
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy0: ethernet-phy@0 {
reg = <0>;
sfp = <&sfp>;
};
};
fixed-link {
speed = <1000>;
full-duplex;
};
};
&fec2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet2>;
phy-mode = "rgmii-id";
phy-handle = <ðphy0>;
status = "okay";
};
Thanks!
George McCollister
Powered by blists - more mailing lists