12 Dec, 2019
4 commits
-
Knowing whether we need to delay the MAC configuration because a module
may have a PHY is useful to phylink to allow NBASE-T modules to work on
systems supporting no more than 2.5G speeds.This commit allows us to delay such configuration until after the PHY
has been probed by recording the parsed capabilities, and if the module
may have a PHY, doing no more until the module_start() notification is
called. At that point, we either have a PHY, or we don't.We move the PHY-based setup a little later, and use the PHYs support
capabilities rather than the EEPROM parsed capabilities to determine
whether we can support the PHY.Reviewed-by: Andrew Lunn
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
When dealing with some copper modules, we can't positively know the
module capabilities are until we have probed the PHY. Without the full
capabilities, we may end up failing a module that we could otherwise
drive with a restricted set of capabilities.An example of this would be a module with a NBASE-T PHY plugged into
a host that supports phy interface modes 2500BASE-X and SGMII. The
PHY supports 10GBASE-R, 5000BASE-X, 2500BASE-X, SGMII interface modes,
which means a subset of the capabilities are compatible with the host.However, reading the module EEPROM leads us to believe that the module
only supports ethtool link mode 10GBASE-T, which is incompatible with
the host - and thus results in the module being rejected.This patch adds an extra notification which are triggered after the
SFP module's PHY probe, and a corresponding notification just before
the PHY is removed.Reviewed-by: Andrew Lunn
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
SFF-8024 is used to define various constants re-used in several SFF
SFP-related specifications. Split these constants from the enum, and
rename them to indicate that they're defined by SFF-8024.Add and use updated SFF-8024 extended compliance code definitions for
10GBASE-T, 5GBASE-T and 2.5GBASE-T modules.Reviewed-by: Andrew Lunn
Signed-off-by: Russell King
Signed-off-by: David S. Miller -
We don't need the EEPROM ID to derive the phy interface mode as we can
derive it merely from the ethtool link modes. Remove the EEPROM ID
argument to sfp_select_interface().Reviewed-by: Andrew Lunn
Signed-off-by: Russell King
Signed-off-by: David S. Miller
21 Nov, 2019
1 commit
-
Add support for the soft status and control register, which allows
TX_FAULT and RX_LOS to be monitored and TX_DISABLE to be set. We
make use of this when the board does not support GPIOs for these
signals.Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
13 Nov, 2019
1 commit
-
When building with SFP disabled, the stub for sfp_bus_add_upstream()
missed "inline". Add it.Fixes: 727b3668b730 ("net: sfp: rework upstream interface")
Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
10 Nov, 2019
1 commit
-
The current upstream interface is an all-or-nothing, which is
sub-optimal for future changes, as it doesn't allow the upstream driver
to prepare for the SFP module becoming available, as it is at boot.Switch to a find-sfp-bus, add-upstream, del-upstream, put-sfp-bus
interface structure instead, which allows the upstream driver to
prepare for a module being available as soon as add-upstream is called.Signed-off-by: Russell King
Signed-off-by: David S. Miller
17 Oct, 2019
1 commit
-
Rather than parsing the sfp firmware node in phylink, parse it in the
sfp-bus code, so we can re-use this code for PHYs without having to
duplicate the parsing.Signed-off-by: Russell King
Signed-off-by: David S. Miller
01 Jun, 2019
2 commits
-
The sfp-bus code now no longer has any use for the network device
structure, so remove its use.Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller -
Add attach and detach methods for SFP buses, which will allow us to get
rid of the netdev storage in sfp-bus.Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
30 Nov, 2018
1 commit
-
SFP standards are now available from the SNIA (Storage Networking
Industry Association) website.Cc: Andrew Lunn
Cc: Florian Fainelli
Signed-off-by: Baruch Siach
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller
18 Jul, 2018
1 commit
-
SFP modules can contain a number of sensors. The EEPROM also contains
recommended alarm and critical values for each sensor, and indications
of if these have been exceeded. Export this information via
HWMON. Currently temperature, VCC, bias current, transmit power, and
possibly receiver power is supported.The sensors in the modules can either return calibrate or uncalibrated
values. Uncalibrated values need to be manipulated, using coefficients
provided in the SFP EEPROM. Uncalibrated receive power values require
floating point maths in order to calibrate them. Performing this in
the kernel is hard. So if the SFP module indicates it uses
uncalibrated values, RX power is not made available.With this hwmon device, it is possible to view the sensor values using
lm-sensors programs:in0: +3.29 V (crit min = +2.90 V, min = +3.00 V)
(max = +3.60 V, crit max = +3.70 V)
temp1: +33.0°C (low = -5.0°C, high = +80.0°C)
(crit low = -10.0°C, crit = +85.0°C)
power1: 1000.00 nW (max = 794.00 uW, min = 50.00 uW) ALARM (LCRIT)
(lcrit = 40.00 uW, crit = 1000.00 uW)
curr1: +0.00 A (crit min = +0.00 A, min = +0.00 A) ALARM (LCRIT, MIN)
(max = +0.01 A, crit max = +0.01 A)The scaling sensors performs on the bias current is not particularly
good. The raw values are more useful:curr1:
curr1_input: 0.000
curr1_min: 0.002
curr1_max: 0.010
curr1_lcrit: 0.000
curr1_crit: 0.011
curr1_min_alarm: 1.000
curr1_max_alarm: 0.000
curr1_lcrit_alarm: 1.000
curr1_crit_alarm: 0.000In order to keep the I2C overhead to a minimum, the constant values,
such as limits and calibration coefficients are read once at module
insertion time. Thus only reading *_input and *_alarm properties
requires i2c read operations.Signed-off-by: Andrew Lunn
Acked-by: Guenter Roeck
Signed-off-by: David S. Miller
01 Mar, 2018
1 commit
-
Negotiate the interface format with the MAC rather than requiring it to
be a fixed type specified solely by the SFP module. This allows modules
that can work with several different interface signalling formats to
select a format compatible with the MAC - for example, a Fiber module
supporing Gigabit ethernet and faster connected to a Gigabit only MAC
needs to select the 1000BASE-X mode.Signed-off-by: Russell King
Signed-off-by: David S. Miller
03 Jan, 2018
1 commit
-
Improve the support for direct-attach copper so that we avoid kernel
warning messages, and report the appropriate PORT_DA type to userspace.
Direct Attach cables can use a number of protocols depending on their
range of speeds.Signed-off-by: Russell King
Signed-off-by: David S. Miller
16 Dec, 2017
1 commit
-
Add support for SFF modules, which are soldered down SFP modules.
These have a different phys_id value, and also have the present and
rate select signals omitted compared with their socketed counter-parts.Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
06 Dec, 2017
2 commits
-
Convert sfp-bus to use fwnode rather than device_node internally, so
we can support more than just device tree firmware.Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
Add kernel-doc documentation for sfp kernel APIs, and link it into the
networking kapi documentation under "Network device support".Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
07 Aug, 2017
1 commit
-
Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller