kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-15 19:56:03 +00:00
Code Issues Releases Packages Activity
linux/drivers/net/phy/sfp.c

3307 lines
82 KiB
Raw Normal View History

net: phy: Convert some PHY and MDIO driver files to SPDX headers Where the license text and the MODULE_LICENSE() value agree, convert to using an SPDX header, removing the license text. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-01-21 19:05:50 +01:00
net: sfp: add debugfs support Add debugfs support to SFP so that the internal state of the SFP state machines and hardware signal state can be viewed from userspace, rather than having to compile a debug kernel to view state transitions in the kernel log. The 'state' output looks like: Module state: empty Module probe attempts: 0 0 Device state: up Main state: down Fault recovery remaining retries: 5 PHY probe remaining retries: 12 moddef0: 0 rx_los: 1 tx_fault: 1 tx_disable: 1 Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1kyYRe-0004kN-3F@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:59:38 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: Fix sfp.c build against GPIO definitions include/gpio.h does not contain the references we want, we should be including linux/gpio/consumer.h instead. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-30 21:42:58 -07:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net/phy/mdio-i2c: Move header file to include/linux/mdio In preparation for moving all MDIO drivers into drivers/net/mdio, move the mdio-i2c header file into include/linux/mdio so it can be used by both the MDIO driver and the SFP code which instantiates I2C MDIO busses. v2: Add include/linux/mdio Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-08-27 04:00:29 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add module start/stop upstream notifications 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 <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:56:09 +00:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
net: sfp: ensure TX_FAULT has deasserted before probing the PHY TX_FAULT should be deasserted to indicate that the module has completed its initialisation. This may include the on-board PHY, so wait until the module has deasserted TX_FAULT before probing the PHY. This means that we need an extra state to handle a TX_FAULT that remains set for longer than t_init, since using the existing handling state would bypass the PHY probe. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:09 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: add module start/stop upstream notifications 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 <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:56:09 +00:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
net: sfp: ensure TX_FAULT has deasserted before probing the PHY TX_FAULT should be deasserted to indicate that the module has completed its initialisation. This may include the on-board PHY, so wait until the module has deasserted TX_FAULT before probing the PHY. This means that we need an extra state to handle a TX_FAULT that remains set for longer than t_init, since using the existing handling state would bypass the PHY probe. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:09 +00:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: Fix typo in state machine debug string The string should be "tx_disable" to match the state enum. Fixes: 4005a7cb4f55 ("net: phy: sftp: print debug message with text, not numbers") Signed-off-by: Sean Anderson <sean.anderson@seco.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-10-04 17:50:02 -04:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: rename gpio_of_names[] There's nothing DT specific about the gpio_of_names array, let's drop the _of infix. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-18 10:21:08 +00:00
net: phy: sfp: rename dt properties to match the binding Make the Rx rate select control gpio property name match the documented binding. This would make the addition of 'rate-select1-gpios' for SFP+ support more natural. Also, make the MOD-DEF0 gpio property name match the documentation. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-09-07 12:25:50 +03:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sfp: rename dt properties to match the binding Make the Rx rate select control gpio property name match the documented binding. This would make the addition of 'rate-select1-gpios' for SFP+ support more natural. Also, make the MOD-DEF0 gpio property name match the documentation. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-09-07 12:25:50 +03:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: avoid tx-fault with Nokia GPON module The Nokia GPON module can hold tx-fault active while it is initialising which can take up to 60s. Avoid this causing the module to be declared faulty after the SFP MSA defined non-cooled module timeout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 13:40:23 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: use a definition for the fault recovery attempts Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:15:55 +00:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
net: sfp: rework the RollBall PHY waiting code RollBall SFP modules allow the access to PHY registers only after a certain time has passed. Until then, the registers read 0xffff. Currently we have quirks for modules where we need to wait either 25 seconds or 4 seconds, but recently I got hands on another module where the wait is even shorter. Instead of hardcoding different wait times, lets rework the code: - increase the PHY retry count to 25 - when RollBall module is detected, increase the PHY retry time from 50ms to 1s Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-11-21 18:20:24 +01:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: rename T_PROBE_WAIT to T_SERIAL SFF-8472 rev 12.2 defines the time for the serial bus to become ready using t_serial. Use this as our identifier for this timeout to make it clear what we are referring to. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:33 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow sfp to probe slow to initialise GPON modules Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:30 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: Cosmetic fixes to phylink/sfp/sfp-bus.c Perform a number of stylistic changes to phylink.c, sfp.c and sfp-bus.c: - align with netdev-style comments - align function arguments to the opening parenthesis - remove blank lines - fixup a few lines over 80 columns Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-30 21:42:57 -07:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: initialize sfp->i2c_block_size at sfp allocation sfp->i2c_block_size is initialized at SFP module insertion in sfp_sm_mod_probe(). Because of that, if SFP module was never inserted since boot, sfp_read() call will lead to zero-length I2C read attempt, and not all I2C controllers are happy with zero-length reads. One way to issue sfp_read() on empty SFP cage is to execute ethtool -m. If SFP module was never plugged since boot, there will be a zero-length I2C read attempt. # ethtool -m xge0 i2c i2c-3: adapter quirk: no zero length (addr 0x0050, size 0, read) Cannot get Module EEPROM data: Operation not supported If SFP module was plugged then removed at least once, sfp->i2c_block_size will be initialized and ethtool -m will fail with different exit code and without I2C error # ethtool -m xge0 Cannot get Module EEPROM data: Remote I/O error Fix this by initializing sfp->i2_block_size at struct sfp allocation stage so no wild sfp_read() could issue zero-length I2C read. Signed-off-by: Ivan Bornyakov <i.bornyakov@metrotek.ru> Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Cc: stable@vger.kernel.org Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-04-06 16:08:32 +03:00
net: sfp: improve poll interval handling The poll interval is a fixed value, so we don't need a static variable for it. The change also allows to use standard macro module_platform_driver, avoiding some boilerplate code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/b8079f96-6865-431c-a908-a0b9e9bd5379@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-27 22:23:19 +02:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
net: phy: sfp: Add support for SMBus module access The SFP module's eeprom and internals are accessible through an i2c bus. It is possible that the SFP might be connected to an SMBus-only controller, such as the one found in some PHY devices in the VSC85xx family. Introduce a set of sfp read/write ops that are going to be used if the i2c bus is only capable of doing smbus byte accesses. As Single-byte SMBus transaction go against SFF-8472 and breaks the atomicity for diagnostics data access, hwmon is disabled in the case of SMBus access. Moreover, as this may cause other instabilities, print a warning at probe time to indicate that the setup may be unreliable because of the hardware design. As hwmon may be disabled for both broken EEPROM and smbus, the warnings are udpated accordingly. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250322075745.120831-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-22 08:57:44 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: Stop SFP polling and interrupt handling during shutdown SFP device polling can cause problems during the shutdown process if the parent devices of the network controller have been shut down already. This problem was seen on the iMX6 platform with PCIe devices, where accessing the device after the bus is shut down causes a hang. Free any acquired GPIO interrupts and stop all delayed work in the SFP driver during the shutdown process, so that we ensure that no pending operations are still occurring after the SFP shutdown completes. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:35 -06:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: add mutex to prevent concurrent state checks sfp_check_state can potentially be called by both a threaded IRQ handler and delayed work. If it is concurrently called, it could result in incorrect state management. Add a st_mutex to protect the state - this lock gets taken outside of code that checks and handle state changes, and the existing sm_mutex nests inside of it. Suggested-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:36 -06:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: re-implement ignoring the hardware TX_FAULT signal Re-implement how we ignore the hardware TX_FAULT signal. Rather than having a separate boolean for this, use a bitmask of the hardware signals that we wish to ignore. This gives more flexibility in the future to ignore other signals such as RX_LOS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/E1qnfXc-008UDY-91@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-03 14:34:24 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add mutex to prevent concurrent state checks sfp_check_state can potentially be called by both a threaded IRQ handler and delayed work. If it is concurrently called, it could result in incorrect state management. Add a st_mutex to protect the state - this lock gets taken outside of code that checks and handle state changes, and the existing sm_mutex nests inside of it. Suggested-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:36 -06:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow sfp to probe slow to initialise GPON modules Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:30 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: rename sm_retries Rename sm_retries as sm_fault_retries, as this is what this member is tracking. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:00 +00:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
net: sfp: avoid tx-fault with Nokia GPON module The Nokia GPON module can hold tx-fault active while it is initialising which can take up to 60s. Avoid this causing the module to be declared faulty after the SFP MSA defined non-cooled module timeout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 13:40:23 +00:00
net: sfp: fix PHY discovery for FS SFP-10G-T module Commit 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") changed the long wait before accessing RollBall / FS modules into probing for PHY every 1 second, and trying 25 times. Wei Lei reports that this does not work correctly on FS modules: when initializing, they may report values different from 0xffff in PHY ID registers for some MMDs, causing get_phy_c45_ids() to find some bogus MMD. Fix this by adding the module_t_wait member back, and setting it to 4 seconds for FS modules. Fixes: 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") Reported-by: Wei Lei <quic_leiwei@quicinc.com> Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Lei Wei <quic_leiwei@quicinc.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-19 17:24:15 +01:00
net: sfp: rework the RollBall PHY waiting code RollBall SFP modules allow the access to PHY registers only after a certain time has passed. Until then, the registers read 0xffff. Currently we have quirks for modules where we need to wait either 25 seconds or 4 seconds, but recently I got hands on another module where the wait is even shorter. Instead of hardcoding different wait times, lets rework the code: - increase the PHY retry count to 25 - when RollBall module is detected, increase the PHY retry time from 50ms to 1s Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-11-21 18:20:24 +01:00
net: sfp: add A2h presence flag The hwmon code wants to know when it is safe to access the A2h data stored in a separate address. We indicate that this is present when we have SFF-8472 compliance and the lack of an address-change sequence., The same conditions are also true if we want to access other controls and status in the A2h address. So let's make a flag to indicate whether we can access it, instead of repeating the conditions throughout the code. For now, only convert the hwmon code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-09 15:57:11 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: add A2h presence flag The hwmon code wants to know when it is safe to access the A2h data stored in a separate address. We indicate that this is present when we have SFF-8472 compliance and the lack of an address-change sequence., The same conditions are also true if we want to access other controls and status in the A2h address. So let's make a flag to indicate whether we can access it, instead of repeating the conditions throughout the code. For now, only convert the hwmon code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-09 15:57:11 +00:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: sfp: add debugfs support Add debugfs support to SFP so that the internal state of the SFP state machines and hardware signal state can be viewed from userspace, rather than having to compile a debug kernel to view state transitions in the kernel log. The 'state' output looks like: Module state: empty Module probe attempts: 0 0 Device state: up Main state: down Fault recovery remaining retries: 5 PHY probe remaining retries: 12 moddef0: 0 rx_los: 1 tx_fault: 1 tx_disable: 1 Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1kyYRe-0004kN-3F@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:59:38 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: improve poll interval handling The poll interval is a fixed value, so we don't need a static variable for it. The change also allows to use standard macro module_platform_driver, avoiding some boilerplate code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/b8079f96-6865-431c-a908-a0b9e9bd5379@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-27 22:23:19 +02:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
net: sfp: add more extended compliance codes 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 <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:56:04 +00:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant The Ubiquiti U-Fiber Instant SFP GPON module has nonsensical information stored in its EEPROM. It claims to support all transceiver types including 10G Ethernet. Clear all claimed modes and set only 1000baseX_Full, which is the only one supported. This module has also phys_id set to SFF, and the SFP subsystem currently does not allow to use SFP modules detected as SFFs. Add exception for this module so it can be detected as supported. This change finally allows to detect and use SFP GPON module Ubiquiti U-Fiber Instant on Linux system. EEPROM content of this SFP module is (where XX is serial number): 00: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8 ???........??.?? 10: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20 ....UBNT 20: 20 20 20 20 00 18 e8 29 55 46 2d 49 4e 53 54 41 .??)UF-INSTA 30: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 36 NT 4 ??.6 40: 00 06 00 00 55 42 4e 54 XX XX XX XX XX XX XX XX .?..UBNTXXXXXXXX 50: 20 20 20 20 31 34 30 31 32 33 20 20 60 80 02 41 140123 `??A Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:28 +01:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
net: sfp: move Alcatel Lucent 3FE46541AA fixup Add a new fixup mechanism to the SFP quirks, and use it for this module. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:37 +01:00
net: sfp: improve Nokia GPON sfp fixup Improve the Nokia GPON fixup - we need to ignore not only the hardware LOS signal, but also the software implementation as well. Do this by using the new state_ignore_mask to indicate that we should ignore not only the hardware RX_LOS signal, and also clear the LOS bits in the option field. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/E1qnfXh-008UDe-F9@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-03 14:34:29 +01:00
net: sfp: move Huawei MA5671A fixup Move this module over to the new fixup mechanism. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:42 +01:00
net: sfp: re-implement ignoring the hardware TX_FAULT signal Re-implement how we ignore the hardware TX_FAULT signal. Rather than having a separate boolean for this, use a bitmask of the hardware signals that we wish to ignore. This gives more flexibility in the future to ignore other signals such as RX_LOS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/E1qnfXc-008UDY-91@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-03 14:34:24 +01:00
net: sfp: move Huawei MA5671A fixup Move this module over to the new fixup mechanism. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:42 +01:00
net: sfp: improve Huawei MA5671a fixup With the current sfp_fixup_ignore_tx_fault() fixup we ignore the TX_FAULT signal, but we also need to apply sfp_fixup_ignore_los() in order to be able to communicate with the module even if the fiber isn't connected for configuration purposes. This is needed for all the MA5671a firmwares, excluding the FS modded firmware. Fixes: 2069624dac19 ("net: sfp: Add tx-fault workaround for Huawei MA5671A SFP ONT") Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260306125139.213637-1-noltari@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-06 13:29:55 +01:00
net: sfp: add quirk for Potron SFP+ XGSPON ONU Stick Add quirk for Potron SFP+ XGSPON ONU Stick (YV SFP+ONT-XGSPON). This device uses pins 2 and 7 for UART communication, so disable TX_FAULT and LOS. Additionally as it is an embedded system in an SFP+ form factor provide it enough time to fully boot before we attempt to use it. https://www.potrontec.com/index/index/list/cat_id/2.html#11-83 https://pon.wiki/xgs-pon/ont/potron-technology/x-onu-sfpp/ Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://patch.msgid.link/20250617180324.229487-1-macroalpha82@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-17 13:03:24 -05:00
net: sfp: improve Nokia GPON sfp fixup Improve the Nokia GPON fixup - we need to ignore not only the hardware LOS signal, but also the software implementation as well. Do this by using the new state_ignore_mask to indicate that we should ignore not only the hardware RX_LOS signal, and also clear the LOS bits in the option field. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/E1qnfXh-008UDe-F9@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-03 14:34:29 +01:00
net: sfp: add support for a couple of copper multi-rate modules Add support for the Fiberstore SFP-10G-T and Walsun HXSX-ATRC-1 modules. Internally, the PCB silkscreen has what seems to be a part number of WT_502. Fiberstore use v2.2 whereas Walsun use v2.6. These modules contain a Marvell AQrate AQR113C PHY, accessible through I2C 0x51 using the "rollball" protocol. In both cases, the PHY is programmed to use 10GBASE-R with pause-mode rate adaption. Unlike the other rollball modules, these only need a four second delay before we can talk to the PHY. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1q0JfS-006Dqc-8t@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-20 11:18:30 +01:00
net: sfp: rework the RollBall PHY waiting code RollBall SFP modules allow the access to PHY registers only after a certain time has passed. Until then, the registers read 0xffff. Currently we have quirks for modules where we need to wait either 25 seconds or 4 seconds, but recently I got hands on another module where the wait is even shorter. Instead of hardcoding different wait times, lets rework the code: - increase the PHY retry count to 25 - when RollBall module is detected, increase the PHY retry time from 50ms to 1s Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-11-21 18:20:24 +01:00
net: sfp: add support for a couple of copper multi-rate modules Add support for the Fiberstore SFP-10G-T and Walsun HXSX-ATRC-1 modules. Internally, the PCB silkscreen has what seems to be a part number of WT_502. Fiberstore use v2.2 whereas Walsun use v2.6. These modules contain a Marvell AQrate AQR113C PHY, accessible through I2C 0x51 using the "rollball" protocol. In both cases, the PHY is programmed to use 10GBASE-R with pause-mode rate adaption. Unlike the other rollball modules, these only need a four second delay before we can talk to the PHY. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1q0JfS-006Dqc-8t@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-20 11:18:30 +01:00
net: sfp: rework the RollBall PHY waiting code RollBall SFP modules allow the access to PHY registers only after a certain time has passed. Until then, the registers read 0xffff. Currently we have quirks for modules where we need to wait either 25 seconds or 4 seconds, but recently I got hands on another module where the wait is even shorter. Instead of hardcoding different wait times, lets rework the code: - increase the PHY retry count to 25 - when RollBall module is detected, increase the PHY retry time from 50ms to 1s Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-11-21 18:20:24 +01:00
net: sfp: add support for a couple of copper multi-rate modules Add support for the Fiberstore SFP-10G-T and Walsun HXSX-ATRC-1 modules. Internally, the PCB silkscreen has what seems to be a part number of WT_502. Fiberstore use v2.2 whereas Walsun use v2.6. These modules contain a Marvell AQrate AQR113C PHY, accessible through I2C 0x51 using the "rollball" protocol. In both cases, the PHY is programmed to use 10GBASE-R with pause-mode rate adaption. Unlike the other rollball modules, these only need a four second delay before we can talk to the PHY. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1q0JfS-006Dqc-8t@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-20 11:18:30 +01:00
net: sfp: add quirk for FS SFP-10GM-T copper SFP+ module Add quirk for a copper SFP that identifies itself as "FS" "SFP-10GM-T". It uses RollBall protocol to talk to the PHY and needs 4 sec wait before probing the PHY. Signed-off-by: Martin Schiller <ms@dev.tdt.de> Link: https://patch.msgid.link/20250227071058.1520027-1-ms@dev.tdt.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-27 08:10:58 +01:00
net: sfp: add support for a couple of copper multi-rate modules Add support for the Fiberstore SFP-10G-T and Walsun HXSX-ATRC-1 modules. Internally, the PCB silkscreen has what seems to be a part number of WT_502. Fiberstore use v2.2 whereas Walsun use v2.6. These modules contain a Marvell AQrate AQR113C PHY, accessible through I2C 0x51 using the "rollball" protocol. In both cases, the PHY is programmed to use 10GBASE-R with pause-mode rate adaption. Unlike the other rollball modules, these only need a four second delay before we can talk to the PHY. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1q0JfS-006Dqc-8t@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-20 11:18:30 +01:00
net: sfp: rework the RollBall PHY waiting code RollBall SFP modules allow the access to PHY registers only after a certain time has passed. Until then, the registers read 0xffff. Currently we have quirks for modules where we need to wait either 25 seconds or 4 seconds, but recently I got hands on another module where the wait is even shorter. Instead of hardcoding different wait times, lets rework the code: - increase the PHY retry count to 25 - when RollBall module is detected, increase the PHY retry time from 50ms to 1s Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-11-21 18:20:24 +01:00
net: sfp: fix PHY discovery for FS SFP-10G-T module Commit 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") changed the long wait before accessing RollBall / FS modules into probing for PHY every 1 second, and trying 25 times. Wei Lei reports that this does not work correctly on FS modules: when initializing, they may report values different from 0xffff in PHY ID registers for some MMDs, causing get_phy_c45_ids() to find some bogus MMD. Fix this by adding the module_t_wait member back, and setting it to 4 seconds for FS modules. Fixes: 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") Reported-by: Wei Lei <quic_leiwei@quicinc.com> Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Lei Wei <quic_leiwei@quicinc.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-19 17:24:15 +01:00
net: sfp: enhance quirk for Fibrestore 2.5G copper SFP module Enhance the quirk for Fibrestore 2.5G copper SFP module. The original commit e27aca3760c0 ("net: sfp: add quirk for FS's 2.5G copper SFP") introducing the quirk says that the PHY is inaccessible, but that is not true. The module uses Rollball protocol to talk to the PHY, and needs a 4 second wait before probing it, same as FS 10G module. The PHY inside the module is Realtek RTL8221B-VB-CG PHY. The realtek driver recently gained support to set it up via clause 45 accesses. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240423085039.26957-2-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-23 10:50:39 +02:00
net: sfp: fix PHY discovery for FS SFP-10G-T module Commit 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") changed the long wait before accessing RollBall / FS modules into probing for PHY every 1 second, and trying 25 times. Wei Lei reports that this does not work correctly on FS modules: when initializing, they may report values different from 0xffff in PHY ID registers for some MMDs, causing get_phy_c45_ids() to find some bogus MMD. Fix this by adding the module_t_wait member back, and setting it to 4 seconds for FS modules. Fixes: 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") Reported-by: Wei Lei <quic_leiwei@quicinc.com> Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Lei Wei <quic_leiwei@quicinc.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-19 17:24:15 +01:00
net: sfp: add support for a couple of copper multi-rate modules Add support for the Fiberstore SFP-10G-T and Walsun HXSX-ATRC-1 modules. Internally, the PCB silkscreen has what seems to be a part number of WT_502. Fiberstore use v2.2 whereas Walsun use v2.6. These modules contain a Marvell AQrate AQR113C PHY, accessible through I2C 0x51 using the "rollball" protocol. In both cases, the PHY is programmed to use 10GBASE-R with pause-mode rate adaption. Unlike the other rollball modules, these only need a four second delay before we can talk to the PHY. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1q0JfS-006Dqc-8t@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-20 11:18:30 +01:00
net: sfp: enhance quirk for Fibrestore 2.5G copper SFP module Enhance the quirk for Fibrestore 2.5G copper SFP module. The original commit e27aca3760c0 ("net: sfp: add quirk for FS's 2.5G copper SFP") introducing the quirk says that the PHY is inaccessible, but that is not true. The module uses Rollball protocol to talk to the PHY, and needs a 4 second wait before probing it, same as FS 10G module. The PHY inside the module is Realtek RTL8221B-VB-CG PHY. The realtek driver recently gained support to set it up via clause 45 accesses. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240423085039.26957-2-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-23 10:50:39 +02:00
net: sfp: add quirk for FS SFP-10GM-T copper SFP+ module Add quirk for a copper SFP that identifies itself as "FS" "SFP-10GM-T". It uses RollBall protocol to talk to the PHY and needs 4 sec wait before probing the PHY. Signed-off-by: Martin Schiller <ms@dev.tdt.de> Link: https://patch.msgid.link/20250227071058.1520027-1-ms@dev.tdt.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-27 08:10:58 +01:00
net: sfp: enhance quirk for Fibrestore 2.5G copper SFP module Enhance the quirk for Fibrestore 2.5G copper SFP module. The original commit e27aca3760c0 ("net: sfp: add quirk for FS's 2.5G copper SFP") introducing the quirk says that the PHY is inaccessible, but that is not true. The module uses Rollball protocol to talk to the PHY, and needs a 4 second wait before probing it, same as FS 10G module. The PHY inside the module is Realtek RTL8221B-VB-CG PHY. The realtek driver recently gained support to set it up via clause 45 accesses. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240423085039.26957-2-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-23 10:50:39 +02:00
net: sfp: add support for HALNy GPON SFP Add a quirk for the HALNy HL-GSFP module, which appears to have an inverted RX_LOS signal, and maybe uses TX_FAULT as a serial port transmit pin. Rather than use these hardware signals, switch to using software polling for these status signals. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:48 +01:00
net: sfp: add quirk for Potron SFP+ XGSPON ONU Stick Add quirk for Potron SFP+ XGSPON ONU Stick (YV SFP+ONT-XGSPON). This device uses pins 2 and 7 for UART communication, so disable TX_FAULT and LOS. Additionally as it is an embedded system in an SFP+ form factor provide it enough time to fully boot before we attempt to use it. https://www.potrontec.com/index/index/list/cat_id/2.html#11-83 https://pon.wiki/xgs-pon/ont/potron-technology/x-onu-sfpp/ Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://patch.msgid.link/20250617180324.229487-1-macroalpha82@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-17 13:03:24 -05:00
net: sfp: add support for HALNy GPON SFP Add a quirk for the HALNy HL-GSFP module, which appears to have an inverted RX_LOS signal, and maybe uses TX_FAULT as a serial port transmit pin. Rather than use these hardware signals, switch to using software polling for these status signals. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:48 +01:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: add quirk for 2.5G copper SFP 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@public-files.de> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-21 16:58:51 +00:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: add quirk for 2.5G copper SFP 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@public-files.de> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-21 16:58:51 +00:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: add quirk for 2.5G copper SFP 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@public-files.de> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-21 16:58:51 +00:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: add quirk for 2.5G copper SFP 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@public-files.de> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-21 16:58:51 +00:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: add quirk for 2.5G copper SFP 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@public-files.de> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-21 16:58:51 +00:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: Fix Ubiquiti U-Fiber Instant SFP module on mvneta In commit 8110633db49d7de2 ("net: sfp-bus: allow SFP quirks to override Autoneg and pause bits") we moved the setting of Autoneg and pause bits before the call to SFP quirk when parsing SFP module support. Since the quirk for Ubiquiti U-Fiber Instant SFP module zeroes the support bits and sets 1000baseX_Full only, the above mentioned commit changed the overall computed support from 1000baseX_Full, Autoneg, Pause, Asym_Pause to just 1000baseX_Full. This broke the SFP module for mvneta, which requires Autoneg for 1000baseX since commit c762b7fac1b249a9 ("net: mvneta: deny disabling autoneg for 802.3z modes"). Fix this by setting back the Autoneg, Pause and Asym_Pause bits in the quirk. Fixes: 8110633db49d7de2 ("net: sfp-bus: allow SFP quirks to override Autoneg and pause bits") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20260326122038.2489589-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-26 13:20:38 +01:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: Fix Ubiquiti U-Fiber Instant SFP module on mvneta In commit 8110633db49d7de2 ("net: sfp-bus: allow SFP quirks to override Autoneg and pause bits") we moved the setting of Autoneg and pause bits before the call to SFP quirk when parsing SFP module support. Since the quirk for Ubiquiti U-Fiber Instant SFP module zeroes the support bits and sets 1000baseX_Full only, the above mentioned commit changed the overall computed support from 1000baseX_Full, Autoneg, Pause, Asym_Pause to just 1000baseX_Full. This broke the SFP module for mvneta, which requires Autoneg for 1000baseX since commit c762b7fac1b249a9 ("net: mvneta: deny disabling autoneg for 802.3z modes"). Fix this by setting back the Autoneg, Pause and Asym_Pause bits in the quirk. Fixes: 8110633db49d7de2 ("net: sfp-bus: allow SFP quirks to override Autoneg and pause bits") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20260326122038.2489589-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-26 13:20:38 +01:00
net: sfp: Fix quirk for Ubiquiti U-Fiber Instant SFP module Commit fd580c9830316eda ("net: sfp: augment SFP parsing with phy_interface_t bitmap") did not add augumentation for the interface bitmap in the quirk for Ubiquiti U-Fiber Instant. The subsequent commit f81fa96d8a6c7a77 ("net: phylink: use phy_interface_t bitmaps for optical modules") then changed phylink code for selection of SFP interface: instead of using link mode bitmap, the interface bitmap is used, and the fastest interface mode supported by both SFP module and MAC is chosen. Since the interface bitmap contains also modes faster than 1000base-x, this caused a regression wherein this module stopped working out-of-the-box. Fix this. Fixes: fd580c9830316eda ("net: sfp: augment SFP parsing with phy_interface_t bitmap") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20260129082227.17443-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-29 09:22:27 +01:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: Add and use macros for SFP quirks definitions Add macros SFP_QUIRK(), SFP_QUIRK_M() and SFP_QUIRK_F() for defining SFP quirk table entries. Use them to deduplicate the code a little bit. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:07 +02:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: Add and use macros for SFP quirks definitions Add macros SFP_QUIRK(), SFP_QUIRK_M() and SFP_QUIRK_F() for defining SFP quirk table entries. Use them to deduplicate the code a little bit. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:07 +02:00
net: sfp: change quirks for Alcatel Lucent G-010S-P Seems Alcatel Lucent G-010S-P also have the same problem that it uses TX_FAULT pin for SOC uart. So apply sfp_fixup_ignore_tx_fault to it. Signed-off-by: Shengyu Qu <wiagn233@outlook.com> Link: https://patch.msgid.link/TYCPR01MB84373677E45A7BFA5A28232C98792@TYCPR01MB8437.jpnprd01.prod.outlook.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2024-10-12 01:39:17 +08:00
net: sfp: Add and use macros for SFP quirks definitions Add macros SFP_QUIRK(), SFP_QUIRK_M() and SFP_QUIRK_F() for defining SFP quirk table entries. Use them to deduplicate the code a little bit. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:07 +02:00
net: sfp: improve Nokia GPON sfp fixup Improve the Nokia GPON fixup - we need to ignore not only the hardware LOS signal, but also the software implementation as well. Do this by using the new state_ignore_mask to indicate that we should ignore not only the hardware RX_LOS signal, and also clear the LOS bits in the option field. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/E1qnfXh-008UDe-F9@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-03 14:34:29 +01:00
net: sfp: Add and use macros for SFP quirks definitions Add macros SFP_QUIRK(), SFP_QUIRK_M() and SFP_QUIRK_F() for defining SFP quirk table entries. Use them to deduplicate the code a little bit. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:07 +02:00
net: sfp: extend Potron XGSPON quirk to cover additional EEPROM variant Some Potron SFP+ XGSPON ONU sticks are shipped with different EEPROM vendor ID and vendor name strings, but are otherwise functionally identical to the existing "Potron SFP+ XGSPON ONU Stick" handled by sfp_quirk_potron(). These modules, including units distributed under the "Better Internet" branding, use the same UART pin assignment and require the same TX_FAULT/LOS behaviour and boot delay. Re-use the existing Potron quirk for this EEPROM variant. Signed-off-by: Marcus Hughes <marcus.hughes@betterinternet.ltd> Link: https://patch.msgid.link/20251207210355.333451-1-marcus.hughes@betterinternet.ltd Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-12-07 21:03:55 +00:00
net: sfp: add quirk for FLYPRO copper SFP+ module Add quirk for a copper SFP that identifies itself as "FLYPRO" "SFP-10GT-CS-30M". It uses RollBall protocol to talk to the PHY. Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20250831105910.3174-1-olek2@wp.pl Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-08-31 12:59:07 +02:00
net: sfp: update comment for FS SFP-10G-T quirk Update the comment for the Fibrestore SFP-10G-T module: since commit e9301af385e7 ("net: sfp: fix PHY discovery for FS SFP-10G-T module") we also do a 4 second wait before probing the PHY. Fixes: e9301af385e7 ("net: sfp: fix PHY discovery for FS SFP-10G-T module") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240423085039.26957-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-23 10:50:38 +02:00
net: sfp: add support for a couple of copper multi-rate modules Add support for the Fiberstore SFP-10G-T and Walsun HXSX-ATRC-1 modules. Internally, the PCB silkscreen has what seems to be a part number of WT_502. Fiberstore use v2.2 whereas Walsun use v2.6. These modules contain a Marvell AQrate AQR113C PHY, accessible through I2C 0x51 using the "rollball" protocol. In both cases, the PHY is programmed to use 10GBASE-R with pause-mode rate adaption. Unlike the other rollball modules, these only need a four second delay before we can talk to the PHY. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1q0JfS-006Dqc-8t@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-20 11:18:30 +01:00
net: sfp: add quirk for FS SFP-10GM-T copper SFP+ module Add quirk for a copper SFP that identifies itself as "FS" "SFP-10GM-T". It uses RollBall protocol to talk to the PHY and needs 4 sec wait before probing the PHY. Signed-off-by: Martin Schiller <ms@dev.tdt.de> Link: https://patch.msgid.link/20250227071058.1520027-1-ms@dev.tdt.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-27 08:10:58 +01:00
net: sfp: enhance quirk for Fibrestore 2.5G copper SFP module Enhance the quirk for Fibrestore 2.5G copper SFP module. The original commit e27aca3760c0 ("net: sfp: add quirk for FS's 2.5G copper SFP") introducing the quirk says that the PHY is inaccessible, but that is not true. The module uses Rollball protocol to talk to the PHY, and needs a 4 second wait before probing it, same as FS 10G module. The PHY inside the module is Realtek RTL8221B-VB-CG PHY. The realtek driver recently gained support to set it up via clause 45 accesses. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20240423085039.26957-2-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-23 10:50:39 +02:00
net: sfp: add quirk for Fiberstone GPON-ONU-34-20BI Fiberstone GPON-ONU-34-20B can operate at 2500base-X, but report 1.2GBd NRZ in their EEPROM. The module also require the ignore tx fault fixup similar to Huawei MA5671A as it gets disabled on error messages with serial redirection enabled. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20230919124720.8210-1-ansuelsmth@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-09-19 14:47:20 +02:00
net: sfp: Add and use macros for SFP quirks definitions Add macros SFP_QUIRK(), SFP_QUIRK_M() and SFP_QUIRK_F() for defining SFP quirk table entries. Use them to deduplicate the code a little bit. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:07 +02:00
net: sfp: add potron quirk to the H-COM SPP425H-GAB4 SFP+ Stick This is another one of those XGSPON ONU sticks that's using the X-ONU-SFPP internally, thus it also requires the potron quirk to avoid tx faults. So, add an entry for it in sfp_quirks[]. Cc: stable@vger.kernel.org Signed-off-by: Hamza Mahfooz <someguy@effective-light.com> Link: https://patch.msgid.link/20260113232957.609642-1-someguy@effective-light.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-13 18:29:57 -05:00
net: sfp: add quirk enabling 2500Base-x for HG MXPD-483II The HG MXPD-483II 1310nm SFP module is meant to operate with 2500Base-X, however, in their EEPROM they incorrectly specify: Transceiver type : Ethernet: 1000BASE-LX ... BR, Nominal : 2600MBd Use sfp_quirk_2500basex for this module to allow 2500Base-X mode anyway. https://forum.banana-pi.org/t/bpi-r3-sfp-module-compatibility/14573/60 Reported-by: chowtom <chowtom@gmail.com> Tested-by: chowtom <chowtom@gmail.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-04-02 12:44:37 +01:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: add quirk enabling 2500Base-x for HG MXPD-483II The HG MXPD-483II 1310nm SFP module is meant to operate with 2500Base-X, however, in their EEPROM they incorrectly specify: Transceiver type : Ethernet: 1000BASE-LX ... BR, Nominal : 2600MBd Use sfp_quirk_2500basex for this module to allow 2500Base-X mode anyway. https://forum.banana-pi.org/t/bpi-r3-sfp-module-compatibility/14573/60 Reported-by: chowtom <chowtom@gmail.com> Tested-by: chowtom <chowtom@gmail.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-04-02 12:44:37 +01:00
net: sfp: Add and use macros for SFP quirks definitions Add macros SFP_QUIRK(), SFP_QUIRK_M() and SFP_QUIRK_F() for defining SFP quirk table entries. Use them to deduplicate the code a little bit. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:07 +02:00
net: sfp: improve Huawei MA5671a fixup With the current sfp_fixup_ignore_tx_fault() fixup we ignore the TX_FAULT signal, but we also need to apply sfp_fixup_ignore_los() in order to be able to communicate with the module even if the fiber isn't connected for configuration purposes. This is needed for all the MA5671a firmwares, excluding the FS modded firmware. Fixes: 2069624dac19 ("net: sfp: Add tx-fault workaround for Huawei MA5671A SFP ONT") Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260306125139.213637-1-noltari@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-06 13:29:55 +01:00
net: sfp: Add and use macros for SFP quirks definitions Add macros SFP_QUIRK(), SFP_QUIRK_M() and SFP_QUIRK_F() for defining SFP quirk table entries. Use them to deduplicate the code a little bit. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:07 +02:00
net: sfp: add quirks for Hisense and HSGQ GPON ONT SFP modules Several GPON ONT SFP sticks based on Realtek RTL960x report 1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X. On hosts capable of 2500base-X (e.g. Banana Pi R3 / MT7986), the kernel negotiates only 1G because it trusts the incorrect EEPROM data. Add quirks for: - Hisense-Leox LXT-010S-H - Hisense ZNID-GPON-2311NA - HSGQ HSGQ-XPON-Stick Each quirk advertises 2500base-X and ignores TX_FAULT during the module's ~40s Linux boot time. Tested on Banana Pi R3 (MT7986) with OpenWrt 25.12.1, confirmed 2.5Gbps link and full throughput with flow offloading. Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Suggested-by: Marcin Nita <marcin.nita@leolabs.pl> Signed-off-by: John Pavlick <jspavlick@posteo.net> Link: https://patch.msgid.link/20260406132321.72563-1-jspavlick@posteo.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-06 13:23:33 +00:00
net: sfp: add quirk for Lantech 8330-265D Similar to Lantech 8330-262D-E, the Lantech 8330-265D also reports 2500MBd instead of 3125MBd. Also, all 8330-265D report normal RX_LOS in EEPROM, but some signal inverted RX_LOS. We therefore need to ignore RX_LOS on these modules. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://patch.msgid.link/20260128170044.15576-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28 18:00:44 +01:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: add quirk for Lantech 8330-265D Similar to Lantech 8330-262D-E, the Lantech 8330-265D also reports 2500MBd instead of 3125MBd. Also, all 8330-265D report normal RX_LOS in EEPROM, but some signal inverted RX_LOS. We therefore need to ignore RX_LOS on these modules. Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://patch.msgid.link/20260128170044.15576-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-28 18:00:44 +01:00
net: sfp: Add and use macros for SFP quirks definitions Add macros SFP_QUIRK(), SFP_QUIRK_M() and SFP_QUIRK_F() for defining SFP quirk table entries. Use them to deduplicate the code a little bit. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:07 +02:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
net: sfp: add support for HXSX-ATRI-1 copper SFP+ module Walsun offers commercial ("C") and industrial ("I") variants of multi-rate copper SFP+ modules. Add quirk for HXSX-ATRI-1 using same parameters as the already supported commercial variant HXSX-ATRC-1. Signed-off-by: Josua Mayer <josua@solid-run.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20230522145242.30192-2-josua@solid-run.com/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-22 17:52:42 +03:00
net: sfp: add support for a couple of copper multi-rate modules Add support for the Fiberstore SFP-10G-T and Walsun HXSX-ATRC-1 modules. Internally, the PCB silkscreen has what seems to be a part number of WT_502. Fiberstore use v2.2 whereas Walsun use v2.6. These modules contain a Marvell AQrate AQR113C PHY, accessible through I2C 0x51 using the "rollball" protocol. In both cases, the PHY is programmed to use 10GBASE-R with pause-mode rate adaption. Unlike the other rollball modules, these only need a four second delay before we can talk to the PHY. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1q0JfS-006Dqc-8t@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-20 11:18:30 +01:00
net: sfp: add support for HXSX-ATRI-1 copper SFP+ module Walsun offers commercial ("C") and industrial ("I") variants of multi-rate copper SFP+ modules. Add quirk for HXSX-ATRI-1 using same parameters as the already supported commercial variant HXSX-ATRC-1. Signed-off-by: Josua Mayer <josua@solid-run.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20230522145242.30192-2-josua@solid-run.com/ Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-22 17:52:42 +03:00
net: sfp: add support for a couple of copper multi-rate modules Add support for the Fiberstore SFP-10G-T and Walsun HXSX-ATRC-1 modules. Internally, the PCB silkscreen has what seems to be a part number of WT_502. Fiberstore use v2.2 whereas Walsun use v2.6. These modules contain a Marvell AQrate AQR113C PHY, accessible through I2C 0x51 using the "rollball" protocol. In both cases, the PHY is programmed to use 10GBASE-R with pause-mode rate adaption. Unlike the other rollball modules, these only need a four second delay before we can talk to the PHY. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1q0JfS-006Dqc-8t@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-20 11:18:30 +01:00
net: sfp: add quirk for Potron SFP+ XGSPON ONU Stick Add quirk for Potron SFP+ XGSPON ONU Stick (YV SFP+ONT-XGSPON). This device uses pins 2 and 7 for UART communication, so disable TX_FAULT and LOS. Additionally as it is an embedded system in an SFP+ form factor provide it enough time to fully boot before we attempt to use it. https://www.potrontec.com/index/index/list/cat_id/2.html#11-83 https://pon.wiki/xgs-pon/ont/potron-technology/x-onu-sfpp/ Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Link: https://patch.msgid.link/20250617180324.229487-1-macroalpha82@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-17 13:03:24 -05:00
net: sfp: add quirk for ATS SFP-GE-T 1000Base-TX module Add quirk for ATS SFP-GE-T 1000Base-TX module. This copper module comes with broken TX_FAULT indicator which must be ignored for it to work. Co-authored-by: Josef Schlehofer <pepe.schlehofer@gmail.com> Signed-off-by: Daniel Golle <daniel@makrotopia.org> [ rebased on top of net-next ] Signed-off-by: Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20240423090025.29231-1-kabel@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-23 11:00:25 +02:00
net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c The "OEM"/"SFP-10G-T" quirk entry in sfp_fixup_rollball_cc() unconditionally forces MDIO_I2C_ROLLBALL for all modules matching that vendor/part-number combination. This works for modules that genuinely implement a RollBall I2C-to-MDIO bridge, but silently breaks modules that share the same EEPROM strings without having such a bridge. The Realtek RTL8261BE-CG is one such module: a pure copper 10G SFP+ media converter with no I2C-to-MDIO bridge. Its EEPROM reports vendor="OEM", part="SFP-10G-T-I", and -- critically -- Vendor OUI 00:00:00, making OUI-based differentiation impossible. With MDIO_I2C_ROLLBALL forced, the module silently ACKs the unlock password write, the MDIO bus is created, but no PHY responds; the SFP state machine cycles through the RollBall PHY-probe retry window before reporting no PHY. Move the probe into i2c_mii_init_rollball() in mdio-i2c.c, where the RollBall protocol constants are already defined. After sending the unlock password, issue a CMD_READ and poll for CMD_DONE up to 200 ms (10 x 20 ms, matching the existing rollball poll tolerance). A genuine RollBall bridge asserts CMD_DONE within that window; modules without a bridge never do, so i2c_mii_init_rollball() returns -ENODEV. mdio_i2c_alloc() propagates -ENODEV to the caller to signal that no bridge is present and PHY probing should be skipped. sfp_sm_add_mdio_bus() catches -ENODEV and transitions sfp->mdio_protocol to MDIO_I2C_NONE so the rest of the state machine skips PHY probing for this module. Any I2C-level error (NACK, timeout) during the probe is also treated as -ENODEV: if the module does not respond at I2C address 0x51 at all, there is certainly no RollBall bridge there, and SFP initialization should not abort. The probe writes are safe with respect to SFP EEPROM integrity: only modules explicitly listed in the quirk table enter this path, and the RollBall password unlock write to 0x51 was already issued by i2c_mii_init_rollball() before the probe for all such modules. Any module without a device at 0x51 NACKs the transfer and is treated as -ENODEV. Add "OEM"/"SFP-10G-T-I" to the quirk table so RTL8261BE modules enter the probe path; genuine RollBall modules continue to work as before. Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260527053909.2118-1-petr.wozniak@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-27 07:39:09 +02:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
net: sfp: convert sfp quirks to modify struct sfp_module_support In order to provide extensible module support properties, arrange for the SFP quirks to modify any member of the sfp_module_support struct, rather than just the ethtool link modes and interfaces. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/E1uydVe-000000061WK-3KwI@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-16 22:46:46 +01:00
net: sfp: add quirk for OEM 2.5G optical modules Some OEM-branded SFP modules are incorrectly detected as 1000Base-X and fail to establish link on 2.5G-capable ports. These modules do not properly advertise 2500Base-X capability in their EEPROM and require forcing the correct SerDes mode. Add sfp_quirk_2500basex for: - OEM SFP-2.5G-LH03-B - OEM SFP-2.5G-LH20-A Both modules report: Vendor name: OEM Vendor PN: SFP-2.5G-LH03-B / SFP-2.5G-LH20-A Tested on OpenWrt with successful 2.5G link establishment. Signed-off-by: Wei Qisen <weixiansen574@163.com> Link: https://patch.msgid.link/20260526055206.1750-1-weixiansen574@163.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-26 13:52:06 +08:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
net: sfp: add quirk for another multigig RollBall transceiver Add quirk for another RollBall copper transceiver: Turris RTSFP-2.5G, containing 2.5g capable RTL8221B PHY. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Eric Woudstra <ericwouds@gmail.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2024-04-09 09:30:16 +02:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
net: sfp: add quirk for ZOERAX SFP-2.5G-T This is a 2.5G copper module which appears to be based on a Motorcomm YT8821 PHY. There doesn't seem to be a usable way to to access the PHY (I2C address 0x56 provides only read-only C22 access, and Rollball is also not working). The module does not report the correct extended compliance code for 2.5GBase-T, and instead claims to support SONET OC-48 and Fibre Channel: Identifier : 0x03 (SFP) Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID) Connector : 0x07 (LC) Transceiver codes : 0x00 0x01 0x00 0x00 0x40 0x40 0x04 0x00 0x00 Transceiver type : FC: Multimode, 50um (M5) Encoding : 0x05 (SONET Scrambled) BR Nominal : 2500MBd Despite this, the kernel still enables the correct 2500Base-X interface mode. However, for the module to actually work, it is also necessary to disable inband auto-negotiation. Enable the existing "sfp_quirk_oem_2_5g" for this module, which handles that and also sets the bit for 2500Base-T link mode. Signed-off-by: Jan Hoffmann <jan@3e8.eu> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://patch.msgid.link/20260329191304.720160-1-jan@3e8.eu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-29 21:11:11 +02:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: add support for HALNy GPON SFP Add a quirk for the HALNy HL-GSFP module, which appears to have an inverted RX_LOS signal, and maybe uses TX_FAULT as a serial port transmit pin. Rather than use these hardware signals, switch to using software polling for these status signals. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:48 +01:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: add support for HALNy GPON SFP Add a quirk for the HALNy HL-GSFP module, which appears to have an inverted RX_LOS signal, and maybe uses TX_FAULT as a serial port transmit pin. Rather than use these hardware signals, switch to using software polling for these status signals. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:48 +01:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: Cosmetic fixes to phylink/sfp/sfp-bus.c Perform a number of stylistic changes to phylink.c, sfp.c and sfp-bus.c: - align with netdev-style comments - align function arguments to the opening parenthesis - remove blank lines - fixup a few lines over 80 columns Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-30 21:42:57 -07:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: sfp: read eeprom in maximum 16 byte increments Some SFP modules do not like reads longer than 16 bytes, so read the EEPROM in chunks of 16 bytes at a time. This behaviour is not specified in the SFP MSAs, which specifies: "The serial interface uses the 2-wire serial CMOS E2PROM protocol defined for the ATMEL AT24C01A/02/04 family of components." and "As long as the SFP+ receives an acknowledge, it shall serially clock out sequential data words. The sequence is terminated when the host responds with a NACK and a STOP instead of an acknowledge." We must avoid breaking a read across a 16-bit quantity in the diagnostic page, thankfully all 16-bit quantities in that page are naturally aligned. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-02 15:13:00 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: read eeprom in maximum 16 byte increments Some SFP modules do not like reads longer than 16 bytes, so read the EEPROM in chunks of 16 bytes at a time. This behaviour is not specified in the SFP MSAs, which specifies: "The serial interface uses the 2-wire serial CMOS E2PROM protocol defined for the ATMEL AT24C01A/02/04 family of components." and "As long as the SFP+ receives an acknowledge, it shall serially clock out sequential data words. The sequence is terminated when the host responds with a NACK and a STOP instead of an acknowledge." We must avoid breaking a read across a 16-bit quantity in the diagnostic page, thankfully all 16-bit quantities in that page are naturally aligned. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-02 15:13:00 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: read eeprom in maximum 16 byte increments Some SFP modules do not like reads longer than 16 bytes, so read the EEPROM in chunks of 16 bytes at a time. This behaviour is not specified in the SFP MSAs, which specifies: "The serial interface uses the 2-wire serial CMOS E2PROM protocol defined for the ATMEL AT24C01A/02/04 family of components." and "As long as the SFP+ receives an acknowledge, it shall serially clock out sequential data words. The sequence is terminated when the host responds with a NACK and a STOP instead of an acknowledge." We must avoid breaking a read across a 16-bit quantity in the diagnostic page, thankfully all 16-bit quantities in that page are naturally aligned. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-02 15:13:00 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sfp: Add support for SMBus module access The SFP module's eeprom and internals are accessible through an i2c bus. It is possible that the SFP might be connected to an SMBus-only controller, such as the one found in some PHY devices in the VSC85xx family. Introduce a set of sfp read/write ops that are going to be used if the i2c bus is only capable of doing smbus byte accesses. As Single-byte SMBus transaction go against SFF-8472 and breaks the atomicity for diagnostics data access, hwmon is disabled in the case of SMBus access. Moreover, as this may cause other instabilities, print a warning at probe time to indicate that the setup may be unreliable because of the hardware design. As hwmon may be disabled for both broken EEPROM and smbus, the warnings are udpated accordingly. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250322075745.120831-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-22 08:57:44 +01:00
net: sfp: return the number of written bytes for smbus single byte access We expect the SFP write accessors to return the number of written bytes. We fail to do so for single-byte smbus accesses, which may cause errors when setting a module's high-power state and for some cotsworks modules. Let's return the amount of written bytes, as expected. Fixes: 7662abf4db94 ("net: phy: sfp: Add support for SMBus module access") Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260105151840.144552-1-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-05 16:18:39 +01:00
net: phy: sfp: Add support for SMBus module access The SFP module's eeprom and internals are accessible through an i2c bus. It is possible that the SFP might be connected to an SMBus-only controller, such as the one found in some PHY devices in the VSC85xx family. Introduce a set of sfp read/write ops that are going to be used if the i2c bus is only capable of doing smbus byte accesses. As Single-byte SMBus transaction go against SFF-8472 and breaks the atomicity for diagnostics data access, hwmon is disabled in the case of SMBus access. Moreover, as this may cause other instabilities, print a warning at probe time to indicate that the setup may be unreliable because of the hardware design. As hwmon may be disabled for both broken EEPROM and smbus, the warnings are udpated accordingly. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250322075745.120831-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-22 08:57:44 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sfp: Add support for SMBus module access The SFP module's eeprom and internals are accessible through an i2c bus. It is possible that the SFP might be connected to an SMBus-only controller, such as the one found in some PHY devices in the VSC85xx family. Introduce a set of sfp read/write ops that are going to be used if the i2c bus is only capable of doing smbus byte accesses. As Single-byte SMBus transaction go against SFF-8472 and breaks the atomicity for diagnostics data access, hwmon is disabled in the case of SMBus access. Moreover, as this may cause other instabilities, print a warning at probe time to indicate that the setup may be unreliable because of the hardware design. As hwmon may be disabled for both broken EEPROM and smbus, the warnings are udpated accordingly. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250322075745.120831-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-22 08:57:44 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: initialize i2c_block_size at adapter configure time sfp->i2c_block_size is only assigned in sfp_sm_mod_probe(), which runs from the state machine timer after SFP_F_PRESENT has been set. Between those two points, sfp_module_eeprom() (the ethtool -m callback) gates only on SFP_F_PRESENT and can be entered with i2c_block_size still at its kzalloc'd value of 0. On a pure-I2C adapter, sfp_i2c_read() then issues an i2c_transfer() with msgs[1].len = 0 inside a loop that subtracts this_len from len each iteration; on adapters that succeed a zero-length read the loop never advances, spinning while holding rtnl_lock. This was previously addressed by initializing i2c_block_size in sfp_alloc() (commit 813c2dd78618), but the initialization was dropped when i2c_block_size was split from i2c_max_block_size. Initialize sfp->i2c_block_size from sfp->i2c_max_block_size in sfp_i2c_configure(), so the field is valid as soon as the adapter is known. sfp_sm_mod_probe() still reassigns it on each module insertion to recover from a per-module clamp to 1 (sfp_id_needs_byte_io). Fixes: 7662abf4db94 ("net: phy: sfp: Add support for SMBus module access") Cc: stable@vger.kernel.org Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com> Link: https://patch.msgid.link/20260528205242.971410-2-jelonek.jonas@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-28 20:52:40 +00:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: phy: mdio-i2c: support I2C MDIO protocol for RollBall SFP modules Some multigig SFPs from RollBall and Hilink do not expose functional MDIO access to the internal PHY of the SFP via I2C address 0x56 (although there seems to be read-only clause 22 access on this address). Instead these SFPs PHY can be accessed via I2C via the SFP Enhanced Digital Diagnostic Interface - I2C address 0x51. The SFP_PAGE has to be selected to 3 and the password must be filled with 0xff bytes for this PHY communication to work. This extends the mdio-i2c driver to support this protocol by adding a special parameter to mdio_i2c_alloc function via which this RollBall protocol can be selected. Signed-off-by: Marek Behún <kabel@kernel.org> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:09 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: add sfp_modify_u8() helper Add a helper to modify bits in a single byte in memory space, and use it when updating the soft tx-disable flag in the module. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:10:04 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: report error on failure to read sfp soft status Report a rate-limited error if we fail to read the SFP soft status, and preserve the current status in that case. This avoids I2C bus errors from triggering a link flap. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-17 13:50:29 +00:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: report error on failure to read sfp soft status Report a rate-limited error if we fail to read the SFP soft status, and preserve the current status in that case. This avoids I2C bus errors from triggering a link flap. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-17 13:50:29 +00:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: report error on failure to read sfp soft status Report a rate-limited error if we fail to read the SFP soft status, and preserve the current status in that case. This avoids I2C bus errors from triggering a link flap. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-17 13:50:29 +00:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: report error on failure to read sfp soft status Report a rate-limited error if we fail to read the SFP soft status, and preserve the current status in that case. This avoids I2C bus errors from triggering a link flap. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-17 13:50:29 +00:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: add sfp_modify_u8() helper Add a helper to modify bits in a single byte in memory space, and use it when updating the soft tx-disable flag in the module. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:10:04 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: add sfp_modify_u8() helper Add a helper to modify bits in a single byte in memory space, and use it when updating the soft tx-disable flag in the module. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:10:04 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: add sfp_modify_u8() helper Add a helper to modify bits in a single byte in memory space, and use it when updating the soft tx-disable flag in the module. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:10:04 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: re-implement ignoring the hardware TX_FAULT signal Re-implement how we ignore the hardware TX_FAULT signal. Rather than having a separate boolean for this, use a bitmask of the hardware signals that we wish to ignore. This gives more flexibility in the future to ignore other signals such as RX_LOS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/E1qnfXc-008UDY-91@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-03 14:34:24 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: improve poll interval handling The poll interval is a fixed value, so we don't need a static variable for it. The change also allows to use standard macro module_platform_driver, avoiding some boilerplate code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/b8079f96-6865-431c-a908-a0b9e9bd5379@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-27 22:23:19 +02:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: add helper to modify signal states There are a couple of locations in the code where we modify sfp->state, and then call sfp_set_state(, sfp->state) to update the outputs/soft state to control the module. Provide a helper which takes a mask and new state so that this is encapsulated in one location. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:37:47 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: add helper to modify signal states There are a couple of locations in the code where we modify sfp->state, and then call sfp_set_state(, sfp->state) to update the outputs/soft state to control the module. Provide a helper which takes a mask and new state so that this is encapsulated in one location. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:37:47 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: add helper to modify signal states There are a couple of locations in the code where we modify sfp->state, and then call sfp_set_state(, sfp->state) to update the outputs/soft state to control the module. Provide a helper which takes a mask and new state so that this is encapsulated in one location. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:37:47 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: phy: sfp: Handle unimplemented hwmon limits and alarms Not all SFPs implement the registers containing sensor limits and alarms. Luckily, there is a bit indicating if they are implemented or not. Add checking for this bit, when deciding if the hwmon attributes should be visible. Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-04 04:23:56 +02:00
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23 17:36:59 -05:00
net: phy: sfp: Handle unimplemented hwmon limits and alarms Not all SFPs implement the registers containing sensor limits and alarms. Luckily, there is a bit indicating if they are implemented or not. Add checking for this bit, when deciding if the hwmon attributes should be visible. Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-04 04:23:56 +02:00
net: phy: sfp: Add labels to hwmon sensors SFPs can report two different power values, the transmit power and the receive power. Add labels to make it clear which is which. Also add labels to the other sensors, VCC power supply, bias and module temperature. sensors(1) now shows: sff2-isa-0000 Adapter: ISA adapter VCC: +3.23 V temperature: +33.4 C TX_power: 276.00 uW RX_power: 20.00 uW bias: +0.01 A Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-25 01:04:17 +02:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: phy: sfp: Handle unimplemented hwmon limits and alarms Not all SFPs implement the registers containing sensor limits and alarms. Luckily, there is a bit indicating if they are implemented or not. Add checking for this bit, when deciding if the hwmon attributes should be visible. Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-04 04:23:56 +02:00
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23 17:36:59 -05:00
net: phy: sfp: Handle unimplemented hwmon limits and alarms Not all SFPs implement the registers containing sensor limits and alarms. Luckily, there is a bit indicating if they are implemented or not. Add checking for this bit, when deciding if the hwmon attributes should be visible. Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-04 04:23:56 +02:00
net: phy: sfp: Add labels to hwmon sensors SFPs can report two different power values, the transmit power and the receive power. Add labels to make it clear which is which. Also add labels to the other sensors, VCC power supply, bias and module temperature. sensors(1) now shows: sff2-isa-0000 Adapter: ISA adapter VCC: +3.23 V temperature: +33.4 C TX_power: 276.00 uW RX_power: 20.00 uW bias: +0.01 A Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-25 01:04:17 +02:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: phy: sfp: Handle unimplemented hwmon limits and alarms Not all SFPs implement the registers containing sensor limits and alarms. Luckily, there is a bit indicating if they are implemented or not. Add checking for this bit, when deciding if the hwmon attributes should be visible. Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-04 04:23:56 +02:00
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23 17:36:59 -05:00
net: phy: sfp: Handle unimplemented hwmon limits and alarms Not all SFPs implement the registers containing sensor limits and alarms. Luckily, there is a bit indicating if they are implemented or not. Add checking for this bit, when deciding if the hwmon attributes should be visible. Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-04 04:23:56 +02:00
net: phy: sfp: Add labels to hwmon sensors SFPs can report two different power values, the transmit power and the receive power. Add labels to make it clear which is which. Also add labels to the other sensors, VCC power supply, bias and module temperature. sensors(1) now shows: sff2-isa-0000 Adapter: ISA adapter VCC: +3.23 V temperature: +33.4 C TX_power: 276.00 uW RX_power: 20.00 uW bias: +0.01 A Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-25 01:04:17 +02:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: phy: sfp: Handle unimplemented hwmon limits and alarms Not all SFPs implement the registers containing sensor limits and alarms. Luckily, there is a bit indicating if they are implemented or not. Add checking for this bit, when deciding if the hwmon attributes should be visible. Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-04 04:23:56 +02:00
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23 17:36:59 -05:00
net: phy: sfp: Handle unimplemented hwmon limits and alarms Not all SFPs implement the registers containing sensor limits and alarms. Luckily, there is a bit indicating if they are implemented or not. Add checking for this bit, when deciding if the hwmon attributes should be visible. Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-04 04:23:56 +02:00
net: phy: sfp: Add labels to hwmon sensors SFPs can report two different power values, the transmit power and the receive power. Add labels to make it clear which is which. Also add labels to the other sensors, VCC power supply, bias and module temperature. sensors(1) now shows: sff2-isa-0000 Adapter: ISA adapter VCC: +3.23 V temperature: +33.4 C TX_power: 276.00 uW RX_power: 20.00 uW bias: +0.01 A Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-25 01:04:17 +02:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: phy: sfp: hwmon: Fix scaling of RX power The RX power read from the SFP uses units of 0.1uW. This must be scaled to units of uW for HWMON. This requires a divide by 10, not the current 100. With this change in place, sensors(1) and ethtool -m agree: sff2-isa-0000 Adapter: ISA adapter in0: +3.23 V temp1: +33.1 C power1: 270.00 uW power2: 200.00 uW curr1: +0.01 A Laser output power : 0.2743 mW / -5.62 dBm Receiver signal average optical power : 0.2014 mW / -6.96 dBm Reported-by: chris.healy@zii.aero Signed-off-by: Andrew Lunn <andrew@lunn.ch> Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: David S. Miller <davem@davemloft.net>
2019-07-21 18:50:08 +02:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: phy: sfp: Add labels to hwmon sensors SFPs can report two different power values, the transmit power and the receive power. Add labels to make it clear which is which. Also add labels to the other sensors, VCC power supply, bias and module temperature. sensors(1) now shows: sff2-isa-0000 Adapter: ISA adapter VCC: +3.23 V temperature: +33.4 C TX_power: 276.00 uW RX_power: 20.00 uW bias: +0.01 A Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-25 01:04:17 +02:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: phy: sfp: Add labels to hwmon sensors SFPs can report two different power values, the transmit power and the receive power. Add labels to make it clear which is which. Also add labels to the other sensors, VCC power supply, bias and module temperature. sensors(1) now shows: sff2-isa-0000 Adapter: ISA adapter VCC: +3.23 V temperature: +33.4 C TX_power: 276.00 uW RX_power: 20.00 uW bias: +0.01 A Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-08-25 01:04:17 +02:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: phy: sfp: constify pointers to hwmon_channel_info Statically allocated array of pointed to hwmon_channel_info can be made const for safety. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230407145911.79642-8-krzysztof.kozlowski@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-07 16:59:11 +02:00
net: sfp: use simplified HWMON_CHANNEL_INFO macro This makes the code look cleaner and easier to read. Signed-off-by: Beniamin Sandu <beniaminsandu@gmail.com> Link: https://lore.kernel.org/r/20220813204658.848372-1-beniaminsandu@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-08-13 23:46:58 +03:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: sfp: use hwmon_sanitize_name() Instead of open-coding the bad characters replacement in the hwmon name, use the new hwmon_sanitize_name(). Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-22 14:35:42 +02:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: phy: sfp: Add support for SMBus module access The SFP module's eeprom and internals are accessible through an i2c bus. It is possible that the SFP might be connected to an SMBus-only controller, such as the one found in some PHY devices in the VSC85xx family. Introduce a set of sfp read/write ops that are going to be used if the i2c bus is only capable of doing smbus byte accesses. As Single-byte SMBus transaction go against SFF-8472 and breaks the atomicity for diagnostics data access, hwmon is disabled in the case of SMBus access. Moreover, as this may cause other instabilities, print a warning at probe time to indicate that the setup may be unreliable because of the hardware design. As hwmon may be disabled for both broken EEPROM and smbus, the warnings are udpated accordingly. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250322075745.120831-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-22 08:57:44 +01:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: replace use of system_wq with system_percpu_wq Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. system_unbound_wq should be the default workqueue so as not to enforce locality constraints for random work whenever it's not required. Adding system_dfl_wq to encourage its use when unbound work should be used. The old system_unbound_wq will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20250918142427.309519-3-marco.crivellari@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-18 16:24:26 +02:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: sfp: use hwmon_sanitize_name() Instead of open-coding the bad characters replacement in the hwmon name, use the new hwmon_sanitize_name(). Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-06-22 14:35:42 +02:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: sfp: add A2h presence flag The hwmon code wants to know when it is safe to access the A2h data stored in a separate address. We indicate that this is present when we have SFF-8472 compliance and the lack of an address-change sequence., The same conditions are also true if we want to access other controls and status in the A2h address. So let's make a flag to indicate whether we can access it, instead of repeating the conditions throughout the code. For now, only convert the hwmon code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-09 15:57:11 +00:00
net: replace use of system_wq with system_percpu_wq Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. system_unbound_wq should be the default workqueue so as not to enforce locality constraints for random work whenever it's not required. Adding system_dfl_wq to encourage its use when unbound work should be used. The old system_unbound_wq will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20250918142427.309519-3-marco.crivellari@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-18 16:24:26 +02:00
net: sfp: add A2h presence flag The hwmon code wants to know when it is safe to access the A2h data stored in a separate address. We indicate that this is present when we have SFF-8472 compliance and the lack of an address-change sequence., The same conditions are also true if we want to access other controls and status in the A2h address. So let's make a flag to indicate whether we can access it, instead of repeating the conditions throughout the code. For now, only convert the hwmon code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-09 15:57:11 +00:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: phy: sfp: Fix unregistering of HWMON SFP device A HWMON device is only registered is the SFP module supports the diagnostic page and is complient to SFF8472. Don't unconditionally unregister the hwmon device when the SFP module is remove, otherwise we access data structures which don't exist. Reported-by: Florian Fainelli <f.fainelli@gmail.com> Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-09-25 01:50:00 +02:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add helper to modify signal states There are a couple of locations in the code where we modify sfp->state, and then call sfp_set_state(, sfp->state) to update the outputs/soft state to control the module. Provide a helper which takes a mask and new state so that this is encapsulated in one location. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:37:47 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add helper to modify signal states There are a couple of locations in the code where we modify sfp->state, and then call sfp_set_state(, sfp->state) to update the outputs/soft state to control the module. Provide a helper which takes a mask and new state so that this is encapsulated in one location. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:37:47 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add debugfs support Add debugfs support to SFP so that the internal state of the SFP state machines and hardware signal state can be viewed from userspace, rather than having to compile a debug kernel to view state transitions in the kernel log. The 'state' output looks like: Module state: empty Module probe attempts: 0 0 Device state: up Main state: down Fault recovery remaining retries: 5 PHY probe remaining retries: 12 moddef0: 0 rx_los: 1 tx_fault: 1 tx_disable: 1 Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1kyYRe-0004kN-3F@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:59:38 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: add debugfs support Add debugfs support to SFP so that the internal state of the SFP state machines and hardware signal state can be viewed from userspace, rather than having to compile a debug kernel to view state transitions in the kernel log. The 'state' output looks like: Module state: empty Module probe attempts: 0 0 Device state: up Main state: down Fault recovery remaining retries: 5 PHY probe remaining retries: 12 moddef0: 0 rx_los: 1 tx_fault: 1 tx_disable: 1 Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1kyYRe-0004kN-3F@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:59:38 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: add debugfs support Add debugfs support to SFP so that the internal state of the SFP state machines and hardware signal state can be viewed from userspace, rather than having to compile a debug kernel to view state transitions in the kernel log. The 'state' output looks like: Module state: empty Module probe attempts: 0 0 Device state: up Main state: down Fault recovery remaining retries: 5 PHY probe remaining retries: 12 moddef0: 0 rx_los: 1 tx_fault: 1 tx_disable: 1 Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1kyYRe-0004kN-3F@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:59:38 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: rename sfp_sm_ins_next() as sfp_sm_mod_next() sfp_sm_ins_next() modifies the module state machine. Change it's name to reflect this. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:23 +00:00
net: phy: Cosmetic fixes to phylink/sfp/sfp-bus.c Perform a number of stylistic changes to phylink.c, sfp.c and sfp-bus.c: - align with netdev-style comments - align function arguments to the opening parenthesis - remove blank lines - fixup a few lines over 80 columns Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-30 21:42:57 -07:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
sfp: fix non-detection of PHY The detection of a PHY changed in commit e98a3aabf85f ("mdio_bus: don't return NULL from mdiobus_scan()") which now causes sfp to print an error message. Update for this change. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-15 16:09:36 +00:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: error handling for phy probe Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:05 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: move marking PHY on SFP module into SFP code Move marking the PHY as being on a SFP module into the SFP code between getting the PHY device (and thus initialising the phy_device structure) and registering the discovered device. This means that PHY drivers can use phy_on_sfp() in their match and get_features methods. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1qRaga-001vKt-8X@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-03 16:56:24 +01:00
net: sfp: add support for Clause 45 PHYs Some SFP+ modules have a Clause 45 PHY onboard, which is accessible via the normal I2C address. Detect 10G BASE-T PHYs which may have an accessible PHY and probe for it. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:57:01 +00:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: error handling for phy probe Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:05 +00:00
net: sfp: add support for Clause 45 PHYs Some SFP+ modules have a Clause 45 PHY onboard, which is accessible via the normal I2C address. Detect 10G BASE-T PHYs which may have an accessible PHY and probe for it. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:57:01 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: error handling for phy probe Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:05 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: error handling for phy probe Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:05 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: cope with SFPs that set both LOS normal and LOS inverted The SFP MSA defines two option bits in byte 65 to indicate how the Rx_LOS signal on SFP pin 8 behaves: bit 2 - Loss of Signal implemented, signal inverted from standard definition in SFP MSA (often called "Signal Detect"). bit 1 - Loss of Signal implemented, signal as defined in SFP MSA (often called "Rx_LOS"). Clearly, setting both bits results in a meaningless situation: it would mean that LOS is implemented in both the normal sense (1 = signal loss) and inverted sense (0 = signal loss). Unfortunately, there are modules out there which set both bits, which will be initially interpret as "inverted" sense, and then, if the LOS signal changes state, we will toggle between LINK_UP and WAIT_LOS states. Change our LOS handling to give well defined behaviour: only interpret these bits as meaningful if exactly one is set, otherwise treat it as if LOS is not implemented. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1kyYQa-0004iR-CU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:58:32 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: improve RX_LOS handling There are two bits in the option word for the RX_LOS signal. One reports that the RX_LOS signal is active high, the other reports that it is active low. When both or neither are set, the result is not well defined in the specification. Rather than assuming that neither set means normal RX_LOS, take this as meaning no RX_LOS signal available, thereby ignoring the signal. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-30 13:59:16 +00:00
net: sfp: cope with SFPs that set both LOS normal and LOS inverted The SFP MSA defines two option bits in byte 65 to indicate how the Rx_LOS signal on SFP pin 8 behaves: bit 2 - Loss of Signal implemented, signal inverted from standard definition in SFP MSA (often called "Signal Detect"). bit 1 - Loss of Signal implemented, signal as defined in SFP MSA (often called "Rx_LOS"). Clearly, setting both bits results in a meaningless situation: it would mean that LOS is implemented in both the normal sense (1 = signal loss) and inverted sense (0 = signal loss). Unfortunately, there are modules out there which set both bits, which will be initially interpret as "inverted" sense, and then, if the LOS signal changes state, we will toggle between LINK_UP and WAIT_LOS states. Change our LOS handling to give well defined behaviour: only interpret these bits as meaningful if exactly one is set, otherwise treat it as if LOS is not implemented. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1kyYQa-0004iR-CU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:58:32 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: cope with SFPs that set both LOS normal and LOS inverted The SFP MSA defines two option bits in byte 65 to indicate how the Rx_LOS signal on SFP pin 8 behaves: bit 2 - Loss of Signal implemented, signal inverted from standard definition in SFP MSA (often called "Signal Detect"). bit 1 - Loss of Signal implemented, signal as defined in SFP MSA (often called "Rx_LOS"). Clearly, setting both bits results in a meaningless situation: it would mean that LOS is implemented in both the normal sense (1 = signal loss) and inverted sense (0 = signal loss). Unfortunately, there are modules out there which set both bits, which will be initially interpret as "inverted" sense, and then, if the LOS signal changes state, we will toggle between LINK_UP and WAIT_LOS states. Change our LOS handling to give well defined behaviour: only interpret these bits as meaningful if exactly one is set, otherwise treat it as if LOS is not implemented. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1kyYQa-0004iR-CU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:58:32 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: improve RX_LOS handling There are two bits in the option word for the RX_LOS signal. One reports that the RX_LOS signal is active high, the other reports that it is active low. When both or neither are set, the result is not well defined in the specification. Rather than assuming that neither set means normal RX_LOS, take this as meaning no RX_LOS signal available, thereby ignoring the signal. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-30 13:59:16 +00:00
net: sfp: cope with SFPs that set both LOS normal and LOS inverted The SFP MSA defines two option bits in byte 65 to indicate how the Rx_LOS signal on SFP pin 8 behaves: bit 2 - Loss of Signal implemented, signal inverted from standard definition in SFP MSA (often called "Signal Detect"). bit 1 - Loss of Signal implemented, signal as defined in SFP MSA (often called "Rx_LOS"). Clearly, setting both bits results in a meaningless situation: it would mean that LOS is implemented in both the normal sense (1 = signal loss) and inverted sense (0 = signal loss). Unfortunately, there are modules out there which set both bits, which will be initially interpret as "inverted" sense, and then, if the LOS signal changes state, we will toggle between LINK_UP and WAIT_LOS states. Change our LOS handling to give well defined behaviour: only interpret these bits as meaningful if exactly one is set, otherwise treat it as if LOS is not implemented. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1kyYQa-0004iR-CU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:58:32 +00:00
sfp: improve RX_LOS handling There are two bits in the option word for the RX_LOS signal. One reports that the RX_LOS signal is active high, the other reports that it is active low. When both or neither are set, the result is not well defined in the specification. Rather than assuming that neither set means normal RX_LOS, take this as meaning no RX_LOS signal available, thereby ignoring the signal. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-30 13:59:16 +00:00
net: sfp: cope with SFPs that set both LOS normal and LOS inverted The SFP MSA defines two option bits in byte 65 to indicate how the Rx_LOS signal on SFP pin 8 behaves: bit 2 - Loss of Signal implemented, signal inverted from standard definition in SFP MSA (often called "Signal Detect"). bit 1 - Loss of Signal implemented, signal as defined in SFP MSA (often called "Rx_LOS"). Clearly, setting both bits results in a meaningless situation: it would mean that LOS is implemented in both the normal sense (1 = signal loss) and inverted sense (0 = signal loss). Unfortunately, there are modules out there which set both bits, which will be initially interpret as "inverted" sense, and then, if the LOS signal changes state, we will toggle between LINK_UP and WAIT_LOS states. Change our LOS handling to give well defined behaviour: only interpret these bits as meaningful if exactly one is set, otherwise treat it as if LOS is not implemented. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1kyYQa-0004iR-CU@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:58:32 +00:00
sfp: improve RX_LOS handling There are two bits in the option word for the RX_LOS signal. One reports that the RX_LOS signal is active high, the other reports that it is active low. When both or neither are set, the result is not well defined in the specification. Rather than assuming that neither set means normal RX_LOS, take this as meaning no RX_LOS signal available, thereby ignoring the signal. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-30 13:59:16 +00:00
net: sfp: allow fault processing to transition to other states Add the next state to sfp_sm_fault() so that it can branch to other states. This will be necessary to improve the initialisation path. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:04 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: rename sm_retries Rename sm_retries as sm_fault_retries, as this is what this member is tracking. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:00 +00:00
net: phy: Cosmetic fixes to phylink/sfp/sfp-bus.c Perform a number of stylistic changes to phylink.c, sfp.c and sfp-bus.c: - align with netdev-style comments - align function arguments to the opening parenthesis - remove blank lines - fixup a few lines over 80 columns Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-30 21:42:57 -07:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow fault processing to transition to other states Add the next state to sfp_sm_fault() so that it can branch to other states. This will be necessary to improve the initialisation path. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:04 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c The "OEM"/"SFP-10G-T" quirk entry in sfp_fixup_rollball_cc() unconditionally forces MDIO_I2C_ROLLBALL for all modules matching that vendor/part-number combination. This works for modules that genuinely implement a RollBall I2C-to-MDIO bridge, but silently breaks modules that share the same EEPROM strings without having such a bridge. The Realtek RTL8261BE-CG is one such module: a pure copper 10G SFP+ media converter with no I2C-to-MDIO bridge. Its EEPROM reports vendor="OEM", part="SFP-10G-T-I", and -- critically -- Vendor OUI 00:00:00, making OUI-based differentiation impossible. With MDIO_I2C_ROLLBALL forced, the module silently ACKs the unlock password write, the MDIO bus is created, but no PHY responds; the SFP state machine cycles through the RollBall PHY-probe retry window before reporting no PHY. Move the probe into i2c_mii_init_rollball() in mdio-i2c.c, where the RollBall protocol constants are already defined. After sending the unlock password, issue a CMD_READ and poll for CMD_DONE up to 200 ms (10 x 20 ms, matching the existing rollball poll tolerance). A genuine RollBall bridge asserts CMD_DONE within that window; modules without a bridge never do, so i2c_mii_init_rollball() returns -ENODEV. mdio_i2c_alloc() propagates -ENODEV to the caller to signal that no bridge is present and PHY probing should be skipped. sfp_sm_add_mdio_bus() catches -ENODEV and transitions sfp->mdio_protocol to MDIO_I2C_NONE so the rest of the state machine skips PHY probing for this module. Any I2C-level error (NACK, timeout) during the probe is also treated as -ENODEV: if the module does not respond at I2C address 0x51 at all, there is certainly no RollBall bridge there, and SFP initialization should not abort. The probe writes are safe with respect to SFP EEPROM integrity: only modules explicitly listed in the quirk table enter this path, and the RollBall password unlock write to 0x51 was already issued by i2c_mii_init_rollball() before the probe for all such modules. Any module without a device at 0x51 NACKs the transfer and is treated as -ENODEV. Add "OEM"/"SFP-10G-T-I" to the quirk table so RTL8261BE modules enter the probe path; genuine RollBall modules continue to work as before. Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260527053909.2118-1-petr.wozniak@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-27 07:39:09 +02:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: phy: sfp: probe for RollBall I2C-to-MDIO bridge in mdio-i2c The "OEM"/"SFP-10G-T" quirk entry in sfp_fixup_rollball_cc() unconditionally forces MDIO_I2C_ROLLBALL for all modules matching that vendor/part-number combination. This works for modules that genuinely implement a RollBall I2C-to-MDIO bridge, but silently breaks modules that share the same EEPROM strings without having such a bridge. The Realtek RTL8261BE-CG is one such module: a pure copper 10G SFP+ media converter with no I2C-to-MDIO bridge. Its EEPROM reports vendor="OEM", part="SFP-10G-T-I", and -- critically -- Vendor OUI 00:00:00, making OUI-based differentiation impossible. With MDIO_I2C_ROLLBALL forced, the module silently ACKs the unlock password write, the MDIO bus is created, but no PHY responds; the SFP state machine cycles through the RollBall PHY-probe retry window before reporting no PHY. Move the probe into i2c_mii_init_rollball() in mdio-i2c.c, where the RollBall protocol constants are already defined. After sending the unlock password, issue a CMD_READ and poll for CMD_DONE up to 200 ms (10 x 20 ms, matching the existing rollball poll tolerance). A genuine RollBall bridge asserts CMD_DONE within that window; modules without a bridge never do, so i2c_mii_init_rollball() returns -ENODEV. mdio_i2c_alloc() propagates -ENODEV to the caller to signal that no bridge is present and PHY probing should be skipped. sfp_sm_add_mdio_bus() catches -ENODEV and transitions sfp->mdio_protocol to MDIO_I2C_NONE so the rest of the state machine skips PHY probing for this module. Any I2C-level error (NACK, timeout) during the probe is also treated as -ENODEV: if the module does not respond at I2C address 0x51 at all, there is certainly no RollBall bridge there, and SFP initialization should not abort. The probe writes are safe with respect to SFP EEPROM integrity: only modules explicitly listed in the quirk table enter this path, and the RollBall password unlock write to 0x51 was already issued by i2c_mii_init_rollball() before the probe for all such modules. Any module without a device at 0x51 NACKs the transfer and is treated as -ENODEV. Add "OEM"/"SFP-10G-T-I" to the quirk table so RTL8261BE modules enter the probe path; genuine RollBall modules continue to work as before. Signed-off-by: Petr Wozniak <petr.wozniak@gmail.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260527053909.2118-1-petr.wozniak@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-27 07:39:09 +02:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: sfp: add support for Clause 45 PHYs Some SFP+ modules have a Clause 45 PHY onboard, which is accessible via the normal I2C address. Detect 10G BASE-T PHYs which may have an accessible PHY and probe for it. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:57:01 +00:00
net: sfp: error handling for phy probe Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:05 +00:00
net: sfp: split the PHY probe from sfp_sm_mod_init() Move the PHY probe into a separate function, splitting it from sfp_sm_mod_init(). This will allow us to eliminate the 50ms mdelay() inside the state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:54 +00:00
net: sfp: error handling for phy probe Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:05 +00:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: sfp: add support for Clause 45 PHYs Some SFP+ modules have a Clause 45 PHY onboard, which is accessible via the normal I2C address. Detect 10G BASE-T PHYs which may have an accessible PHY and probe for it. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:57:01 +00:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
net: sfp: add support for Clause 45 PHYs Some SFP+ modules have a Clause 45 PHY onboard, which is accessible via the normal I2C address. Detect 10G BASE-T PHYs which may have an accessible PHY and probe for it. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:57:01 +00:00
net: phy: mdio-i2c: support I2C MDIO protocol for RollBall SFP modules Some multigig SFPs from RollBall and Hilink do not expose functional MDIO access to the internal PHY of the SFP via I2C address 0x56 (although there seems to be read-only clause 22 access on this address). Instead these SFPs PHY can be accessed via I2C via the SFP Enhanced Digital Diagnostic Interface - I2C address 0x51. The SFP_PAGE has to be selected to 3 and the password must be filled with 0xff bytes for this PHY communication to work. This extends the mdio-i2c driver to support this protocol by adding a special parameter to mdio_i2c_alloc function via which this RollBall protocol can be selected. Signed-off-by: Marek Behún <kabel@kernel.org> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:09 +02:00
net: sfp: add support for multigig RollBall transceivers This adds support for multigig copper SFP modules from RollBall/Hilink. These modules have a specific way to access clause 45 registers of the internal PHY. We also need to wait at least 22 seconds after deasserting TX disable before accessing the PHY. The code waits for 25 seconds just to be sure. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:10 +02:00
net: phy: mdio-i2c: support I2C MDIO protocol for RollBall SFP modules Some multigig SFPs from RollBall and Hilink do not expose functional MDIO access to the internal PHY of the SFP via I2C address 0x56 (although there seems to be read-only clause 22 access on this address). Instead these SFPs PHY can be accessed via I2C via the SFP Enhanced Digital Diagnostic Interface - I2C address 0x51. The SFP_PAGE has to be selected to 3 and the password must be filled with 0xff bytes for this PHY communication to work. This extends the mdio-i2c driver to support this protocol by adding a special parameter to mdio_i2c_alloc function via which this RollBall protocol can be selected. Signed-off-by: Marek Behún <kabel@kernel.org> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:09 +02:00
net: sfp: add support for Clause 45 PHYs Some SFP+ modules have a Clause 45 PHY onboard, which is accessible via the normal I2C address. Detect 10G BASE-T PHYs which may have an accessible PHY and probe for it. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:57:01 +00:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: sfp: error handling for phy probe Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:05 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
net: sfp: fix high power modules without diagnostic monitoring Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") unintetionally changed the semantics for high power modules without the digital diagnostics monitoring. We repeatedly attempt to read the power status from the non-existing 0xa2 address in a futile hope this failure is temporary: [ 8.856051] sfp sfp-eth3: module NTT 0000000000000000 rev 0000 sn 0000000000000000 dc 160408 [ 8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode [ 8.873469] sfp sfp-eth3: Failed to read EEPROM: -5 [ 8.983251] sfp sfp-eth3: Failed to read EEPROM: -5 [ 9.103250] sfp sfp-eth3: Failed to read EEPROM: -5 We previosuly assumed such modules were powered up in the correct mode, continuing without further configuration as long as the required power class was supported by the host. Restore this behaviour, while preserving the intent of subsequent patches to avoid the "Address Change Sequence not supported" warning if we are not going to be accessing the DDM address. Fixes: 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") Reported-by: 照山周一郎 <teruyama@springboard-inc.jp> Tested-by: 照山周一郎 <teruyama@springboard-inc.jp> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-17 14:52:33 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: ignore power level 2 prior to SFF-8472 Rev 10.2 Power level 2 was introduced by SFF-8472 revision 10.2. Ignore the power declaration bit for modules that are not compliant with at least this revision. This should remove any spurious indication of 1.5W modules. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:09:49 +01:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
net: sfp: ignore power level 3 prior to SFF-8472 Rev 11.4 Power level 3 was included in SFF-8472 revision 11.9, but this does not have a compliance code. Use revision 11.4 as the minimum compliance level instead. This should avoid any spurious indication of 2W modules. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:09:54 +01:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: check firmware provided max power Check that the firmware provided maximum power is at least 1W, which is the minimum power level for any SFP module. Now that we enforce the minimum of 1W, we can exit early from sfp_module_parse_power() if the module power is 1W or less. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:09:43 +01:00
net: sfp: fix high power modules without diagnostic monitoring Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") unintetionally changed the semantics for high power modules without the digital diagnostics monitoring. We repeatedly attempt to read the power status from the non-existing 0xa2 address in a futile hope this failure is temporary: [ 8.856051] sfp sfp-eth3: module NTT 0000000000000000 rev 0000 sn 0000000000000000 dc 160408 [ 8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode [ 8.873469] sfp sfp-eth3: Failed to read EEPROM: -5 [ 8.983251] sfp sfp-eth3: Failed to read EEPROM: -5 [ 9.103250] sfp sfp-eth3: Failed to read EEPROM: -5 We previosuly assumed such modules were powered up in the correct mode, continuing without further configuration as long as the required power class was supported by the host. Restore this behaviour, while preserving the intent of subsequent patches to avoid the "Address Change Sequence not supported" warning if we are not going to be accessing the DDM address. Fixes: 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") Reported-by: 照山周一郎 <teruyama@springboard-inc.jp> Tested-by: 照山周一郎 <teruyama@springboard-inc.jp> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-17 14:52:33 +00:00
net: sfp: avoid power switch on address-change modules If the module indicates that it requires an address change sequence to switch between address 0x50 and 0x51, which we don't support, we can't write to the register that controls the power mode to switch to high power mode. Warn the user that the module may not be functional in this case, and don't try to change the power mode. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:44 +00:00
net: sfp: fix high power modules without diagnostic monitoring Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") unintetionally changed the semantics for high power modules without the digital diagnostics monitoring. We repeatedly attempt to read the power status from the non-existing 0xa2 address in a futile hope this failure is temporary: [ 8.856051] sfp sfp-eth3: module NTT 0000000000000000 rev 0000 sn 0000000000000000 dc 160408 [ 8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode [ 8.873469] sfp sfp-eth3: Failed to read EEPROM: -5 [ 8.983251] sfp sfp-eth3: Failed to read EEPROM: -5 [ 9.103250] sfp sfp-eth3: Failed to read EEPROM: -5 We previosuly assumed such modules were powered up in the correct mode, continuing without further configuration as long as the required power class was supported by the host. Restore this behaviour, while preserving the intent of subsequent patches to avoid the "Address Change Sequence not supported" warning if we are not going to be accessing the DDM address. Fixes: 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") Reported-by: 照山周一郎 <teruyama@springboard-inc.jp> Tested-by: 照山周一郎 <teruyama@springboard-inc.jp> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-17 14:52:33 +00:00
net: sfp: avoid power switch on address-change modules If the module indicates that it requires an address change sequence to switch between address 0x50 and 0x51, which we don't support, we can't write to the register that controls the power mode to switch to high power mode. Warn the user that the module may not be functional in this case, and don't try to change the power mode. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:44 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: avoid power switch on address-change modules If the module indicates that it requires an address change sequence to switch between address 0x50 and 0x51, which we don't support, we can't write to the register that controls the power mode to switch to high power mode. Warn the user that the module may not be functional in this case, and don't try to change the power mode. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:44 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: fix high power modules without diagnostic monitoring Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") unintetionally changed the semantics for high power modules without the digital diagnostics monitoring. We repeatedly attempt to read the power status from the non-existing 0xa2 address in a futile hope this failure is temporary: [ 8.856051] sfp sfp-eth3: module NTT 0000000000000000 rev 0000 sn 0000000000000000 dc 160408 [ 8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode [ 8.873469] sfp sfp-eth3: Failed to read EEPROM: -5 [ 8.983251] sfp sfp-eth3: Failed to read EEPROM: -5 [ 9.103250] sfp sfp-eth3: Failed to read EEPROM: -5 We previosuly assumed such modules were powered up in the correct mode, continuing without further configuration as long as the required power class was supported by the host. Restore this behaviour, while preserving the intent of subsequent patches to avoid the "Address Change Sequence not supported" warning if we are not going to be accessing the DDM address. Fixes: 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") Reported-by: 照山周一郎 <teruyama@springboard-inc.jp> Tested-by: 照山周一郎 <teruyama@springboard-inc.jp> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-17 14:52:33 +00:00
net: sfp: avoid power switch on address-change modules If the module indicates that it requires an address change sequence to switch between address 0x50 and 0x51, which we don't support, we can't write to the register that controls the power mode to switch to high power mode. Warn the user that the module may not be functional in this case, and don't try to change the power mode. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:44 +00:00
net: sfp: fix high power modules without diagnostic monitoring Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") unintetionally changed the semantics for high power modules without the digital diagnostics monitoring. We repeatedly attempt to read the power status from the non-existing 0xa2 address in a futile hope this failure is temporary: [ 8.856051] sfp sfp-eth3: module NTT 0000000000000000 rev 0000 sn 0000000000000000 dc 160408 [ 8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode [ 8.873469] sfp sfp-eth3: Failed to read EEPROM: -5 [ 8.983251] sfp sfp-eth3: Failed to read EEPROM: -5 [ 9.103250] sfp sfp-eth3: Failed to read EEPROM: -5 We previosuly assumed such modules were powered up in the correct mode, continuing without further configuration as long as the required power class was supported by the host. Restore this behaviour, while preserving the intent of subsequent patches to avoid the "Address Change Sequence not supported" warning if we are not going to be accessing the DDM address. Fixes: 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules") Reported-by: 照山周一郎 <teruyama@springboard-inc.jp> Tested-by: 照山周一郎 <teruyama@springboard-inc.jp> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-01-17 14:52:33 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: fix spelling mistake "requies" -> "requires" There is a spelling mistake in a dev_warn message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-13 09:55:48 +00:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
net: sfp: get rid of DM7052 hack when enabling high power Since we no longer mis-detect high-power mode with the DM7052 module, we no longer need the hack in sfp_module_enable_high_power(), and can now switch this to use sfp_modify_u8(). Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:10:09 +01:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
net: phy: sfp: Cotsworks SFF module EEPROM fixup Some Cotsworks SFF have invalid data in the first few bytes of the module EEPROM. This results in these modules not being detected as valid modules. Address this by poking the correct EEPROM values into the module EEPROM when the model/PN match and the existing module EEPROM contents are not correct. Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-14 10:59:10 -07:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: phy: sfp: Cotsworks SFF module EEPROM fixup Some Cotsworks SFF have invalid data in the first few bytes of the module EEPROM. This results in these modules not being detected as valid modules. Address this by poking the correct EEPROM values into the module EEPROM when the model/PN match and the existing module EEPROM contents are not correct. Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-14 10:59:10 -07:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: phy: sfp: Cotsworks SFF module EEPROM fixup Some Cotsworks SFF have invalid data in the first few bytes of the module EEPROM. This results in these modules not being detected as valid modules. Address this by poking the correct EEPROM values into the module EEPROM when the model/PN match and the existing module EEPROM contents are not correct. Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-14 10:59:10 -07:00
net: sfp: add A2h presence flag The hwmon code wants to know when it is safe to access the A2h data stored in a separate address. We indicate that this is present when we have SFF-8472 compliance and the lack of an address-change sequence., The same conditions are also true if we want to access other controls and status in the A2h address. So let's make a flag to indicate whether we can access it, instead of repeating the conditions throughout the code. For now, only convert the hwmon code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-09 15:57:11 +00:00
net: sfp: allow sfp to probe slow to initialise GPON modules Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:30 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sfp: Cotsworks SFF module EEPROM fixup Some Cotsworks SFF have invalid data in the first few bytes of the module EEPROM. This results in these modules not being detected as valid modules. Address this by poking the correct EEPROM values into the module EEPROM when the model/PN match and the existing module EEPROM contents are not correct. Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-14 10:59:10 -07:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
sfp: allow cotsworks modules Cotsworks modules fail the checksums - it appears that Cotsworks reprograms the EEPROM at the end of production with the final product information (serial, date code, and exact part number for module options) and fails to update the checksum. Work around this by detecting the Cotsworks name in the manufacturer field, and reducing the checksum failures to warnings rather than a hard error. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-28 11:18:25 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sfp: Add support for SMBus module access The SFP module's eeprom and internals are accessible through an i2c bus. It is possible that the SFP might be connected to an SMBus-only controller, such as the one found in some PHY devices in the VSC85xx family. Introduce a set of sfp read/write ops that are going to be used if the i2c bus is only capable of doing smbus byte accesses. As Single-byte SMBus transaction go against SFF-8472 and breaks the atomicity for diagnostics data access, hwmon is disabled in the case of SMBus access. Moreover, as this may cause other instabilities, print a warning at probe time to indicate that the setup may be unreliable because of the hardware design. As hwmon may be disabled for both broken EEPROM and smbus, the warnings are udpated accordingly. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250322075745.120831-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-22 08:57:44 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: allow sfp to probe slow to initialise GPON modules Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:30 +00:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips The workaround for VSOL V2801F brand based GPON SFP modules added in commit 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") works only for IDs added explicitly to the list. Since there are rebranded modules where OEM vendors put different strings into the vendor name field, we cannot base workaround on IDs only. Moreover the issue which the above mentioned commit tried to work around is generic not only to VSOL based modules, but rather to all GPON modules based on Realtek RTL8672 and RTL9601C chips. These include at least the following GPON modules: * V-SOL V2801F * C-Data FD511GX-RM0 * OPTON GP801R * BAUDCOM BD-1234-SFM * CPGOS03-0490 v2.0 * Ubiquiti U-Fiber Instant * EXOT EGS1 These Realtek chips have broken EEPROM emulator which for N-byte read operation returns just the first byte of EEPROM data, followed by N-1 zeros. Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM reading operation. Function sfp_i2c_read() now always uses single byte reading when it is required and when function sfp_hwmon_probe() detects single byte access, it disables registration of hwmon device, because in this case we cannot reliably and atomically read 2 bytes as is required by the standard for retrieving values from diagnostic area. (These Realtek chips are broken in a way that violates SFP standards for diagnostic interface. Kernel in this case simply cannot do anything less of skipping registration of the hwmon interface.) This patch fixes reading of EEPROM content from SFP modules based on Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays broken and cannot be fixed. Fixes: 0d035bed2a4a ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround") Co-developed-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-25 16:02:27 +01:00
sfp: allow cotsworks modules Cotsworks modules fail the checksums - it appears that Cotsworks reprograms the EEPROM at the end of production with the final product information (serial, date code, and exact part number for module options) and fails to update the checksum. Work around this by detecting the Cotsworks name in the manufacturer field, and reducing the checksum failures to warnings rather than a hard error. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-28 11:18:25 +01:00
net: phy: sfp: Cotsworks SFF module EEPROM fixup Some Cotsworks SFF have invalid data in the first few bytes of the module EEPROM. This results in these modules not being detected as valid modules. Address this by poking the correct EEPROM values into the module EEPROM when the model/PN match and the existing module EEPROM contents are not correct. Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-14 10:59:10 -07:00
sfp: allow cotsworks modules Cotsworks modules fail the checksums - it appears that Cotsworks reprograms the EEPROM at the end of production with the final product information (serial, date code, and exact part number for module options) and fails to update the checksum. Work around this by detecting the Cotsworks name in the manufacturer field, and reducing the checksum failures to warnings rather than a hard error. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-28 11:18:25 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: allow cotsworks modules Cotsworks modules fail the checksums - it appears that Cotsworks reprograms the EEPROM at the end of production with the final product information (serial, date code, and exact part number for module options) and fails to update the checksum. Work around this by detecting the Cotsworks name in the manufacturer field, and reducing the checksum failures to warnings rather than a hard error. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-28 11:18:25 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround Add a workaround for the detection of VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 GPON module which CarlitoxxPro states needs single byte I2C reads to the EEPROM. Pali Rohár reports that he also has a CarlitoxxPro-based V2801F module, which reports a manufacturer of "OEM". This manufacturer can't be matched as it appears in many different modules, so also match the part number too. Reported-by: Thomas Schreiber <tschreibe@gmail.com> Reported-by: Pali Rohár <pali@kernel.org> Tested-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-09 11:22:49 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: allow cotsworks modules Cotsworks modules fail the checksums - it appears that Cotsworks reprograms the EEPROM at the end of production with the final product information (serial, date code, and exact part number for module options) and fails to update the checksum. Work around this by detecting the Cotsworks name in the manufacturer field, and reducing the checksum failures to warnings rather than a hard error. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-03-28 11:18:25 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: use precision to print non-null terminated strings Rather than memcpy()'ing the strings and null terminate them, printf allows non-NULL terminated strings provided the precision is not more than the size of the buffer. Use this form to print the basic module information rather than copying and terminating the strings. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-29 12:15:12 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add A2h presence flag The hwmon code wants to know when it is safe to access the A2h data stored in a separate address. We indicate that this is present when we have SFF-8472 compliance and the lack of an address-change sequence., The same conditions are also true if we want to access other controls and status in the A2h address. So let's make a flag to indicate whether we can access it, instead of repeating the conditions throughout the code. For now, only convert the hwmon code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-09 15:57:11 +00:00
sfp: warn about modules requiring address change sequence We do not support SFP modules which require the address change sequence as detailed by SFF 8472 revision 1.22 section 8.9. Warn when these modules are inserted, and treat them as SFF8079 modules for ethtool. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-30 13:59:21 +00:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: move Alcatel Lucent 3FE46541AA fixup Add a new fixup mechanism to the SFP quirks, and use it for this module. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:37 +01:00
net: sfp: fix PHY discovery for FS SFP-10G-T module Commit 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") changed the long wait before accessing RollBall / FS modules into probing for PHY every 1 second, and trying 25 times. Wei Lei reports that this does not work correctly on FS modules: when initializing, they may report values different from 0xffff in PHY ID registers for some MMDs, causing get_phy_c45_ids() to find some bogus MMD. Fix this by adding the module_t_wait member back, and setting it to 4 seconds for FS modules. Fixes: 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") Reported-by: Wei Lei <quic_leiwei@quicinc.com> Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Lei Wei <quic_leiwei@quicinc.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-19 17:24:15 +01:00
net: sfp: rework the RollBall PHY waiting code RollBall SFP modules allow the access to PHY registers only after a certain time has passed. Until then, the registers read 0xffff. Currently we have quirks for modules where we need to wait either 25 seconds or 4 seconds, but recently I got hands on another module where the wait is even shorter. Instead of hardcoding different wait times, lets rework the code: - increase the PHY retry count to 25 - when RollBall module is detected, increase the PHY retry time from 50ms to 1s Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-11-21 18:20:24 +01:00
net: sfp: avoid tx-fault with Nokia GPON module The Nokia GPON module can hold tx-fault active while it is initialising which can take up to 60s. Avoid this causing the module to be declared faulty after the SFP MSA defined non-cooled module timeout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 13:40:23 +00:00
net: sfp: re-implement ignoring the hardware TX_FAULT signal Re-implement how we ignore the hardware TX_FAULT signal. Rather than having a separate boolean for this, use a bitmask of the hardware signals that we wish to ignore. This gives more flexibility in the future to ignore other signals such as RX_LOS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/E1qnfXc-008UDY-91@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-03 14:34:24 +01:00
net: sfp: Add tx-fault workaround for Huawei MA5671A SFP ONT As noted elsewhere, various GPON SFP modules exhibit non-standard TX-fault behaviour. In the tested case, the Huawei MA5671A, when used in combination with a Marvell mv88e6085 switch, was found to persistently assert TX-fault, resulting in the module being disabled. This patch adds a quirk to ignore the SFP_F_TX_FAULT state, allowing the module to function. Change from v1: removal of erroneous return statment (Andrew Lunn) Signed-off-by: Matthew Hagan <mnhagan88@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20220502223315.1973376-1-mnhagan88@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-05-02 23:33:15 +01:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: move Alcatel Lucent 3FE46541AA fixup Add a new fixup mechanism to the SFP quirks, and use it for this module. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:37 +01:00
net: sfp: re-implement ignoring the hardware TX_FAULT signal Re-implement how we ignore the hardware TX_FAULT signal. Rather than having a separate boolean for this, use a bitmask of the hardware signals that we wish to ignore. This gives more flexibility in the future to ignore other signals such as RX_LOS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/E1qnfXc-008UDY-91@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-03 14:34:24 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sfp: Add HWMON support for module sensors 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.000 In 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 <andrew@lunn.ch> Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-07-17 21:48:13 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: parse SFP power requirement earlier Parse the SFP power requirement earlier, in preparation for moving the power level setup code. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:39 +00:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: add A2h presence flag The hwmon code wants to know when it is safe to access the A2h data stored in a separate address. We indicate that this is present when we have SFF-8472 compliance and the lack of an address-change sequence., The same conditions are also true if we want to access other controls and status in the A2h address. So let's make a flag to indicate whether we can access it, instead of repeating the conditions throughout the code. For now, only convert the hwmon code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-09 15:57:11 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: rename T_PROBE_WAIT to T_SERIAL SFF-8472 rev 12.2 defines the time for the serial bus to become ready using t_serial. Use this as our identifier for this timeout to make it clear what we are referring to. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:33 +00:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
net: sfp: Always call `sfp_sm_mod_remove()` on remove If the module is in SFP_MOD_ERROR, `sfp_sm_mod_remove()` will not be run. As a consequence, `sfp_hwmon_remove()` is not getting run either, leaving a stale `hwmon` device behind. `sfp_sm_mod_remove()` itself checks `sfp->sm_mod_state` anyways, so this check was not really needed in the first place. Fixes: d2e816c0293f ("net: sfp: handle module remove outside state machine") Signed-off-by: "Csókás, Bence" <csokas.bence@prolan.hu> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240605084251.63502-1-csokas.bence@prolan.hu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-06-05 10:42:51 +02:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
net: sfp: handle module remove outside state machine Removing a module resets the module state machine back to its initial state. Rather than explicitly handling this in every state, handle it early on outside of the state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:28 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow sfp to probe slow to initialise GPON modules Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:30 +00:00
net: sfp: rename T_PROBE_WAIT to T_SERIAL SFF-8472 rev 12.2 defines the time for the serial bus to become ready using t_serial. Use this as our identifier for this timeout to make it clear what we are referring to. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:33 +00:00
net: sfp: allow sfp to probe slow to initialise GPON modules Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:30 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow sfp to probe slow to initialise GPON modules Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:30 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
net: sfp: allow sfp to probe slow to initialise GPON modules Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:30 +00:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
net: sfp: fix state loss when updating state_hw_mask Andrew reports that the SFF modules on one of the ZII platforms do not indicate link up due to the SFP code believing that LOS indicating that there is no signal being received from the remote end, but in fact the LOS signal is showing that there is signal. What makes SFF modules different from SFPs is they typically have an inverted LOS, which uncovered this issue. When we read the hardware state, we mask it with state_hw_mask so we ignore anything we're not interested in. However, we don't re-read when state_hw_mask changes, leading to sfp->state being stale. Arrange for a software poll of the module state after we have parsed the EEPROM in sfp_sm_mod_probe() and updated state_*_mask. This will generate any necessary events for signal changes for the state machine as well as updating sfp->state. Reported-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Andrew Lunn <andrew@lunn.ch> Fixes: 8475c4b70b04 ("net: sfp: re-implement soft state polling setup") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-03-17 07:28:00 +00:00
net: replace use of system_wq with system_percpu_wq Currently if a user enqueue a work item using schedule_delayed_work() the used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to schedule_work() that is using system_wq and queue_work(), that makes use again of WORK_CPU_UNBOUND. This lack of consistentcy cannot be addressed without refactoring the API. system_unbound_wq should be the default workqueue so as not to enforce locality constraints for random work whenever it's not required. Adding system_dfl_wq to encourage its use when unbound work should be used. The old system_unbound_wq will be kept for a few release cycles. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Link: https://patch.msgid.link/20250918142427.309519-3-marco.crivellari@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-18 16:24:26 +02:00
net: sfp: fix state loss when updating state_hw_mask Andrew reports that the SFF modules on one of the ZII platforms do not indicate link up due to the SFP code believing that LOS indicating that there is no signal being received from the remote end, but in fact the LOS signal is showing that there is signal. What makes SFF modules different from SFPs is they typically have an inverted LOS, which uncovered this issue. When we read the hardware state, we mask it with state_hw_mask so we ignore anything we're not interested in. However, we don't re-read when state_hw_mask changes, leading to sfp->state being stale. Arrange for a software poll of the module state after we have parsed the EEPROM in sfp_sm_mod_probe() and updated state_*_mask. This will generate any necessary events for signal changes for the state machine as well as updating sfp->state. Reported-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Andrew Lunn <andrew@lunn.ch> Fixes: 8475c4b70b04 ("net: sfp: re-implement soft state polling setup") Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-03-17 07:28:00 +00:00
net: sfp: fix hwmon The referenced commit below allowed more than one hwmon device to be created per SFP, which is definitely not what we want. Avoid this by only creating the hwmon device just as we transition to WAITDEV state. Fixes: 139d3a212a1f ("net: sfp: allow modules with slow diagnostics to probe") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-03 23:51:28 +00:00
net: sfp: use %pe for printing errors Convert sfp to use %pe for printing error codes, which can print them as errno symbols rather than numbers. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1nOyEN-00BuuE-OB@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-03-01 08:51:39 +00:00
net: sfp: fix hwmon The referenced commit below allowed more than one hwmon device to be created per SFP, which is definitely not what we want. Avoid this by only creating the hwmon device just as we transition to WAITDEV state. Fixes: 139d3a212a1f ("net: sfp: allow modules with slow diagnostics to probe") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-03 23:51:28 +00:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23 17:36:59 -05:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
net: sfp: move quirk handling into sfp.c We need to handle more quirks than just those which affect the link modes of the module. Move the quirk lookup into sfp.c, and pass the quirk to sfp-bus.c Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:32 +01:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-23 17:36:59 -05:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
net: sfp: allow sfp to probe slow to initialise GPON modules Some GPON modules (e.g. Huawei MA5671A) take a significant amount of time to start responding on the I2C bus, contary to the SFF specifications. Work around this by implementing a two-level timeout strategy, where we initially quickly retry for the module, and then use a slower retry after we exceed a maximum number of quick attempts. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:30 +00:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
net: sfp: split power mode switching from probe Switch the power mode switching from the probe, so that we don't repeatedly re-probe the SFP device if there is a problem accessing the registers at I2C address 0x51. In splitting this out, we can also fix a bug where we leave the module in high-power mode when the upstream device is detached but the module is still inserted. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:20 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add module start/stop upstream notifications 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 <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-11 10:56:09 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: sfp: move tx disable on device down to main state machine Move the tx disable assertion on device down to the main state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:18 +00:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
net: sfp: split the PHY probe from sfp_sm_mod_init() Move the PHY probe into a separate function, splitting it from sfp_sm_mod_init(). This will allow us to eliminate the 50ms mdelay() inside the state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:54 +00:00
net: sfp: only use soft polling if we have A2h access The soft state bits are stored in the A2h memory space, and require SFF-8472 compliance. This is what our have_a2 flag tells us, so use this to indicate whether we should attempt to use the soft signals. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-03-09 15:57:16 +00:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
net: sfp: rename sm_retries Rename sm_retries as sm_fault_retries, as this is what this member is tracking. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:00 +00:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
net: sfp: fix PHY discovery for FS SFP-10G-T module Commit 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") changed the long wait before accessing RollBall / FS modules into probing for PHY every 1 second, and trying 25 times. Wei Lei reports that this does not work correctly on FS modules: when initializing, they may report values different from 0xffff in PHY ID registers for some MMDs, causing get_phy_c45_ids() to find some bogus MMD. Fix this by adding the module_t_wait member back, and setting it to 4 seconds for FS modules. Fixes: 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") Reported-by: Wei Lei <quic_leiwei@quicinc.com> Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Lei Wei <quic_leiwei@quicinc.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-19 17:24:15 +01:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
net: sfp: fix PHY discovery for FS SFP-10G-T module Commit 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") changed the long wait before accessing RollBall / FS modules into probing for PHY every 1 second, and trying 25 times. Wei Lei reports that this does not work correctly on FS modules: when initializing, they may report values different from 0xffff in PHY ID registers for some MMDs, causing get_phy_c45_ids() to find some bogus MMD. Fix this by adding the module_t_wait member back, and setting it to 4 seconds for FS modules. Fixes: 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") Reported-by: Wei Lei <quic_leiwei@quicinc.com> Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Lei Wei <quic_leiwei@quicinc.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-19 17:24:15 +01:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
net: sfp: avoid tx-fault with Nokia GPON module The Nokia GPON module can hold tx-fault active while it is initialising which can take up to 60s. Avoid this causing the module to be declared faulty after the SFP MSA defined non-cooled module timeout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 13:40:23 +00:00
net: sfp: split the PHY probe from sfp_sm_mod_init() Move the PHY probe into a separate function, splitting it from sfp_sm_mod_init(). This will allow us to eliminate the 50ms mdelay() inside the state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:54 +00:00
net: sfp: avoid tx-fault with Nokia GPON module The Nokia GPON module can hold tx-fault active while it is initialising which can take up to 60s. Avoid this causing the module to be declared faulty after the SFP MSA defined non-cooled module timeout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 13:40:23 +00:00
net: sfp: fix PHY discovery for FS SFP-10G-T module Commit 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") changed the long wait before accessing RollBall / FS modules into probing for PHY every 1 second, and trying 25 times. Wei Lei reports that this does not work correctly on FS modules: when initializing, they may report values different from 0xffff in PHY ID registers for some MMDs, causing get_phy_c45_ids() to find some bogus MMD. Fix this by adding the module_t_wait member back, and setting it to 4 seconds for FS modules. Fixes: 2f3ce7a56c6e ("net: sfp: rework the RollBall PHY waiting code") Reported-by: Wei Lei <quic_leiwei@quicinc.com> Signed-off-by: Marek Behún <kabel@kernel.org> Tested-by: Lei Wei <quic_leiwei@quicinc.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-12-19 17:24:15 +01:00
net: sfp: eliminate mdelay() from PHY probe Rather than using mdelay() to wait before probing the PHY (which holds several locks, including the rtnl lock), add an extra wait state to the state machine to introduce the 50ms delay without holding any locks. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:59 +00:00
net: sfp: split the PHY probe from sfp_sm_mod_init() Move the PHY probe into a separate function, splitting it from sfp_sm_mod_init(). This will allow us to eliminate the 50ms mdelay() inside the state machine. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:54 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: ensure TX_FAULT has deasserted before probing the PHY TX_FAULT should be deasserted to indicate that the module has completed its initialisation. This may include the on-board PHY, so wait until the module has deasserted TX_FAULT before probing the PHY. This means that we need an extra state to handle a TX_FAULT that remains set for longer than t_init, since using the existing handling state would bypass the PHY probe. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:09 +00:00
net: phy: delete repeated words of comments There are some repeated words in some comments, they should be deleted. Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com> Signed-off-by: Weihang Li <liweihang@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-16 18:01:21 +08:00
net: sfp: avoid tx-fault with Nokia GPON module The Nokia GPON module can hold tx-fault active while it is initialising which can take up to 60s. Avoid this causing the module to be declared faulty after the SFP MSA defined non-cooled module timeout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 13:40:23 +00:00
net: sfp: ensure TX_FAULT has deasserted before probing the PHY TX_FAULT should be deasserted to indicate that the module has completed its initialisation. This may include the on-board PHY, so wait until the module has deasserted TX_FAULT before probing the PHY. This means that we need an extra state to handle a TX_FAULT that remains set for longer than t_init, since using the existing handling state would bypass the PHY probe. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:09 +00:00
net: sfp: rename sm_retries Rename sm_retries as sm_fault_retries, as this is what this member is tracking. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:00 +00:00
net: sfp: ensure TX_FAULT has deasserted before probing the PHY TX_FAULT should be deasserted to indicate that the module has completed its initialisation. This may include the on-board PHY, so wait until the module has deasserted TX_FAULT before probing the PHY. This means that we need an extra state to handle a TX_FAULT that remains set for longer than t_init, since using the existing handling state would bypass the PHY probe. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:09 +00:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
net: sfp: create/destroy I2C mdiobus before PHY probe/after PHY release Instead of configuring the I2C mdiobus when SFP driver is probed, create/destroy the mdiobus before the PHY is probed for/after it is released. This way we can tell the mdio-i2c code which protocol to use for each SFP transceiver. Move the code that determines MDIO I2C protocol from sfp_sm_probe_for_phy() to sfp_sm_mod_probe(), where most of the SFP ID parsing is done. Don't allocate I2C bus if no PHY is expected. Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-09-30 16:21:08 +02:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
net: sfp: ensure TX_FAULT has deasserted before probing the PHY TX_FAULT should be deasserted to indicate that the module has completed its initialisation. This may include the on-board PHY, so wait until the module has deasserted TX_FAULT before probing the PHY. This means that we need an extra state to handle a TX_FAULT that remains set for longer than t_init, since using the existing handling state would bypass the PHY probe. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:09 +00:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
net: sfp: rework the RollBall PHY waiting code RollBall SFP modules allow the access to PHY registers only after a certain time has passed. Until then, the registers read 0xffff. Currently we have quirks for modules where we need to wait either 25 seconds or 4 seconds, but recently I got hands on another module where the wait is even shorter. Instead of hardcoding different wait times, lets rework the code: - increase the PHY retry count to 25 - when RollBall module is detected, increase the PHY retry time from 50ms to 1s Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-11-21 18:20:24 +01:00
net: sfp: re-attempt probing for phy Some 1000BASE-T PHY modules take a while for the PHY to wake up. Retry the probe a number of times before deciding that the module has no PHY. Tested with: Sourcephotonics SPGBTXCNFC - PHY takes less than 50ms to respond. Champion One 1000SFPT - PHY takes about 200ms to respond. Mikrotik S-RJ01 - no PHY Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 14:16:11 +00:00
net: sfp: ensure TX_FAULT has deasserted before probing the PHY TX_FAULT should be deasserted to indicate that the module has completed its initialisation. This may include the on-board PHY, so wait until the module has deasserted TX_FAULT before probing the PHY. This means that we need an extra state to handle a TX_FAULT that remains set for longer than t_init, since using the existing handling state would bypass the PHY probe. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:09 +00:00
net: sfp: avoid tx-fault with Nokia GPON module The Nokia GPON module can hold tx-fault active while it is initialising which can take up to 60s. Avoid this causing the module to be declared faulty after the SFP MSA defined non-cooled module timeout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 13:40:23 +00:00
net: sfp: ensure TX_FAULT has deasserted before probing the PHY TX_FAULT should be deasserted to indicate that the module has completed its initialisation. This may include the on-board PHY, so wait until the module has deasserted TX_FAULT before probing the PHY. This means that we need an extra state to handle a TX_FAULT that remains set for longer than t_init, since using the existing handling state would bypass the PHY probe. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:09 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow fault processing to transition to other states Add the next state to sfp_sm_fault() so that it can branch to other states. This will be necessary to improve the initialisation path. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:04 +00:00
sfp: improve RX_LOS handling There are two bits in the option word for the RX_LOS signal. One reports that the RX_LOS signal is active high, the other reports that it is active low. When both or neither are set, the result is not well defined in the specification. Rather than assuming that neither set means normal RX_LOS, take this as meaning no RX_LOS signal available, thereby ignoring the signal. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-30 13:59:16 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow fault processing to transition to other states Add the next state to sfp_sm_fault() so that it can branch to other states. This will be necessary to improve the initialisation path. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:04 +00:00
sfp: improve RX_LOS handling There are two bits in the option word for the RX_LOS signal. One reports that the RX_LOS signal is active high, the other reports that it is active low. When both or neither are set, the result is not well defined in the specification. Rather than assuming that neither set means normal RX_LOS, take this as meaning no RX_LOS signal available, thereby ignoring the signal. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-30 13:59:16 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: avoid tx-fault with Nokia GPON module The Nokia GPON module can hold tx-fault active while it is initialising which can take up to 60s. Avoid this causing the module to be declared faulty after the SFP MSA defined non-cooled module timeout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-09 13:40:23 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow fault processing to transition to other states Add the next state to sfp_sm_fault() so that it can branch to other states. This will be necessary to improve the initialisation path. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:04 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
net: sfp: move sm_mutex into sfp_check_state() Provide an unlocked version of sfp_sm_event() which can be used by sfp_check_state() to avoid having to keep re-taking the lock if several signals have changed state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:02 +01:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
net: sfp: move sfp sub-state machines into separate functions Move the SFP sub-state machines out of the main state machine function, in preparation for it doing a bit more with the device state. By doing so, we ensure that our debug after the main state machine is always printed. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:06:13 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sftp: print debug message with text, not numbers Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-08-08 20:54:12 +02:00
net: sfp: move sm_mutex into sfp_check_state() Provide an unlocked version of sfp_sm_event() which can be used by sfp_check_state() to avoid having to keep re-taking the lock if several signals have changed state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:02 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sm_mutex into sfp_check_state() Provide an unlocked version of sfp_sm_event() which can be used by sfp_check_state() to avoid having to keep re-taking the lock if several signals have changed state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:02 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: do not probe SFP module before we're attached When we probe a SFP module, we expect to be able to call the upstream device's module_insert() function so that the upstream link can be configured. However, when the upstream device is delayed, we currently may end up probing the module before the upstream device is available, and lose the module_insert() call. Avoid this by holding off probing the module until the SFP bus is properly connected to both the SFP socket driver and the upstream driver. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-06 10:52:30 +00:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
net: sfp: do not probe SFP module before we're attached When we probe a SFP module, we expect to be able to call the upstream device's module_insert() function so that the upstream link can be configured. However, when the upstream device is delayed, we currently may end up probing the module before the upstream device is available, and lose the module_insert() call. Avoid this by holding off probing the module until the SFP bus is properly connected to both the SFP socket driver and the upstream driver. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-06 10:52:30 +00:00
net: sfp: track upstream's attachment state in state machine Track the upstream's attachment state in the state machine rather than maintaining a boolean, which ensures that we have a strict order of ATTACH followed by an UP event - we can never believe that a newly attached upstream will be anything but down. Rearrange the order of state machines so we run the module state machine after the upstream device's state machine, so the module state machine can check the current state of the device and take action to e.g. reset back to empty state when the upstream is detached. This is to allow the module detection to run independently of the network device becoming available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:14 +00:00
net: sfp: do not probe SFP module before we're attached When we probe a SFP module, we expect to be able to call the upstream device's module_insert() function so that the upstream link can be configured. However, when the upstream device is delayed, we currently may end up probing the module before the upstream device is available, and lose the module_insert() call. Avoid this by holding off probing the module until the SFP bus is properly connected to both the SFP socket driver and the upstream driver. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-06 10:52:30 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for setting signalling rate Add support to the SFP layer to allow phylink to set the signalling rate for a SFP module. The rate given will be in units of kilo-baud (1000 baud). Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:12 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: add support for setting signalling rate Add support to the SFP layer to allow phylink to set the signalling rate for a SFP module. The rate given will be in units of kilo-baud (1000 baud). Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:12 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: warn about modules requiring address change sequence We do not support SFP modules which require the address change sequence as detailed by SFF 8472 revision 1.22 section 8.9. Warn when these modules are inserted, and treat them as SFF8079 modules for ethtool. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-11-30 13:59:21 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: Cosmetic fixes to phylink/sfp/sfp-bus.c Perform a number of stylistic changes to phylink.c, sfp.c and sfp-bus.c: - align with netdev-style comments - align function arguments to the opening parenthesis - remove blank lines - fixup a few lines over 80 columns Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-10-30 21:42:57 -07:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: avoid EEPROM read of absent SFP module If SFP module is not present, it is sensible to fail sfp_module_eeprom() and sfp_module_eeprom_by_page() early to avoid excessive I2C transfers which are garanteed to fail. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ivan Bornyakov <i.bornyakov@metrotek.ru> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-04-06 16:08:33 +03:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: fix EEPROM reading in the case of non-SFF8472 SFPs The EEPROM reading was trying to read from the second EEPROM address if we requested the last byte from the SFF8079 EEPROM, which caused a failure when the second EEPROM is not present. Discovered with a S-RJ01 SFP module. Fix this. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-15 16:09:41 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: fix EEPROM reading in the case of non-SFF8472 SFPs The EEPROM reading was trying to read from the second EEPROM address if we requested the last byte from the SFF8079 EEPROM, which caused a failure when the second EEPROM is not present. Discovered with a S-RJ01 SFP module. Fix this. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-15 16:09:41 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: fix EEPROM reading in the case of non-SFF8472 SFPs The EEPROM reading was trying to read from the second EEPROM address if we requested the last byte from the SFF8079 EEPROM, which caused a failure when the second EEPROM is not present. Discovered with a S-RJ01 SFP module. Fix this. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-15 16:09:41 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
phy: sfp: add netlink SFP support to generic SFP code The new netlink API for reading SFP data requires a new op to be implemented. The idea of the new netlink SFP code is that userspace is responsible to parsing the EEPROM data and requesting pages, rather than have the kernel decide what pages are interesting and returning them. This allows greater flexibility for newer formats. Currently the generic SFP code only supports simple SFPs. Allow i2c address 0x50 and 0x51 to be accessed with page and bank must always be 0. This interface will later be extended when for example QSFP support is added. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Vladyslav Tarasiuk <vladyslavt@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-09 11:06:40 +03:00
net: sfp: avoid EEPROM read of absent SFP module If SFP module is not present, it is sensible to fail sfp_module_eeprom() and sfp_module_eeprom_by_page() early to avoid excessive I2C transfers which are garanteed to fail. Suggested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ivan Bornyakov <i.bornyakov@metrotek.ru> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-04-06 16:08:33 +03:00
phy: sfp: add netlink SFP support to generic SFP code The new netlink API for reading SFP data requires a new op to be implemented. The idea of the new netlink SFP code is that userspace is responsible to parsing the EEPROM data and requesting pages, rather than have the kernel decide what pages are interesting and returning them. This allows greater flexibility for newer formats. Currently the generic SFP code only supports simple SFPs. Allow i2c address 0x50 and 0x51 to be accessed with page and bank must always be 0. This interface will later be extended when for example QSFP support is added. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Vladyslav Tarasiuk <vladyslavt@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-09 11:06:40 +03:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: do not probe SFP module before we're attached When we probe a SFP module, we expect to be able to call the upstream device's module_insert() function so that the upstream link can be configured. However, when the upstream device is delayed, we currently may end up probing the module before the upstream device is available, and lose the module_insert() call. Avoid this by holding off probing the module until the SFP bus is properly connected to both the SFP socket driver and the upstream driver. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-06 10:52:30 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for setting signalling rate Add support to the SFP layer to allow phylink to set the signalling rate for a SFP module. The rate given will be in units of kilo-baud (1000 baud). Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:12 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
phy: sfp: add netlink SFP support to generic SFP code The new netlink API for reading SFP data requires a new op to be implemented. The idea of the new netlink SFP code is that userspace is responsible to parsing the EEPROM data and requesting pages, rather than have the kernel decide what pages are interesting and returning them. This allows greater flexibility for newer formats. Currently the generic SFP code only supports simple SFPs. Allow i2c address 0x50 and 0x51 to be accessed with page and bank must always be 0. This interface will later be extended when for example QSFP support is added. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Vladyslav Tarasiuk <vladyslavt@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-09 11:06:40 +03:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move rtnl lock to cover reading state As preparation to moving st_mutex inside rtnl_lock, we need to first move the rtnl lock to cover reading the state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:37:52 +01:00
net: sfp: swap order of rtnl and st_mutex locks Swap the order of the rtnl and st_mutex locks - st_mutex is now nested beneath rtnl lock instead of rtnl being beneath st_mutex. This will allow us to hold st_mutex only while manipulating the module's hardware or software control state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:37:57 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: re-implement ignoring the hardware TX_FAULT signal Re-implement how we ignore the hardware TX_FAULT signal. Rather than having a separate boolean for this, use a bitmask of the hardware signals that we wish to ignore. This gives more flexibility in the future to ignore other signals such as RX_LOS. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Tested-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/E1qnfXc-008UDY-91@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-03 14:34:24 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: rename gpio_of_names[] There's nothing DT specific about the gpio_of_names array, let's drop the _of infix. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-18 10:21:08 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sm_mutex into sfp_check_state() Provide an unlocked version of sfp_sm_event() which can be used by sfp_check_state() to avoid having to keep re-taking the lock if several signals have changed state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:02 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sm_mutex into sfp_check_state() Provide an unlocked version of sfp_sm_event() which can be used by sfp_check_state() to avoid having to keep re-taking the lock if several signals have changed state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:02 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sm_mutex into sfp_check_state() Provide an unlocked version of sfp_sm_event() which can be used by sfp_check_state() to avoid having to keep re-taking the lock if several signals have changed state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:02 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move sm_mutex into sfp_check_state() Provide an unlocked version of sfp_sm_event() which can be used by sfp_check_state() to avoid having to keep re-taking the lock if several signals have changed state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:02 +01:00
net: sfp: swap order of rtnl and st_mutex locks Swap the order of the rtnl and st_mutex locks - st_mutex is now nested beneath rtnl lock instead of rtnl being beneath st_mutex. This will allow us to hold st_mutex only while manipulating the module's hardware or software control state. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:37:57 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: change st_mutex locking Change st_mutex's use within SFP such that it only protects the various state members, as it was originally supposed to, and isn't held while making various calls outside the driver. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:07 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: improve poll interval handling The poll interval is a fixed value, so we don't need a static variable for it. The change also allows to use standard macro module_platform_driver, avoiding some boilerplate code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/b8079f96-6865-431c-a908-a0b9e9bd5379@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-27 22:23:19 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21 16:37:42 -08:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add mutex to prevent concurrent state checks sfp_check_state can potentially be called by both a threaded IRQ handler and delayed work. If it is concurrently called, it could result in incorrect state management. Add a st_mutex to protect the state - this lock gets taken outside of code that checks and handle state changes, and the existing sm_mutex nests inside of it. Suggested-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:36 -06:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: allow modules with slow diagnostics to probe When a module is inserted, we attempt to read read the ID from address 0x50. Once we are able to read the ID, we immediately attempt to initialise the hwmon support by reading from address 0x51. If this fails, then we fall into error state, and assume that the module is not usable. Modules such as the ALCATELLUCENT 3FE46541AA use a real EEPROM for I2C address 0x50, which responds immediately. However, address 0x51 is an emulated, which only becomes available once the on-board firmware has booted. This prompts us to fall into the error state. Since the module may be usable without diagnostics, arrange for the hwmon probe independent of the rest of the SFP itself, retrying every 5s for up to about 60s for the monitoring to become available, and print an error message if it doesn't become available. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:35 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: clean up i2c-bus property parsing We currently have some complicated code in sfp_probe() which gets the I2C bus depending on whether the sfp node is DT or ACPI, and we use completely separate lookup functions. This could do with being in a separate function to make the code more readable, so move it to a new function, sfp_i2c_get(). We can also use fwnode_find_reference() to lookup the I2C bus fwnode before then decending into fwnode-type specific parsing. A future cleanup would be to move the fwnode-type specific parsing into the i2c layer, which is where it really should be. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1p1WGJ-0098wS-4w@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-03 17:25:15 +00:00
net: sfp: use i2c_get_adapter_by_fwnode() Use the newly introduced i2c_get_adapter_by_fwnode() API, so that we can retrieve the I2C adapter in a firmware independent manner once we have the fwnode handle for the adapter. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-18 10:20:58 +00:00
net: sfp: clean up i2c-bus property parsing We currently have some complicated code in sfp_probe() which gets the I2C bus depending on whether the sfp node is DT or ACPI, and we use completely separate lookup functions. This could do with being in a separate function to make the code more readable, so move it to a new function, sfp_i2c_get(). We can also use fwnode_find_reference() to lookup the I2C bus fwnode before then decending into fwnode-type specific parsing. A future cleanup would be to move the fwnode-type specific parsing into the i2c layer, which is where it really should be. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1p1WGJ-0098wS-4w@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-03 17:25:15 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
net: sfp: Unique GPIO interrupt names Dynamically generate a unique GPIO interrupt name, based on the device name and the GPIO name. For example: 103: 0 sx1503q 12 Edge sff2-los 104: 0 sx1503q 13 Edge sff2-tx-fault The sffX indicates the SFP the los and tx-fault are associated with. v3: - reverse Christmas tree new variable - fix spaces vs tabs v2: - added net-next to PATCH part of subject line - switched to devm_kasprintf() Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-06 18:27:07 -07:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: Stop SFP polling and interrupt handling during shutdown SFP device polling can cause problems during the shutdown process if the parent devices of the network controller have been shut down already. This problem was seen on the iMX6 platform with PCIe devices, where accessing the device after the bus is shut down causes a hang. Free any acquired GPIO interrupts and stop all delayed work in the SFP driver during the shutdown process, so that we ensure that no pending operations are still occurring after the SFP shutdown completes. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:35 -06:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: fix memory leak in sfp_probe() sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When devm_add_action() fails, sfp is not freed, which leads to a memory leak. We should use devm_add_action_or_reset() instead of devm_add_action(). Signed-off-by: Jianglei Nie <niejianglei2021@163.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20220629075550.2152003-1-niejianglei2021@163.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-06-29 15:55:50 +08:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: use device_get_match_data() Rather than using of_match_node() to get the matching of_device_id to then retrieve the match data, use device_get_match_data() instead to avoid firmware specific functions, and free the driver from having firmware specific code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-18 10:21:03 +00:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
net: sfp: use device_get_match_data() Rather than using of_match_node() to get the matching of_device_id to then retrieve the match data, use device_get_match_data() instead to avoid firmware specific functions, and free the driver from having firmware specific code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-18 10:21:03 +00:00
net: phy: sfp: enable i2c-bus detection on ACPI based systems Lookup I2C adapter using the "i2c-bus" device property on ACPI based systems similar to how it's done with DT. An example DSD describing an SFP on an ACPI based system: Device (SFP0) { Name (_HID, "PRP0001") Name (_CRS, ResourceTemplate() { GpioIo(Exclusive, PullDefault, 0, 0, IoRestrictionNone, "\\_SB.PCI0.RP01.GPIO", 0, ResourceConsumer) { 0, 1, 2, 3, 4 } }) Name (_DSD, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "compatible", "sff,sfp" }, Package () { "i2c-bus", \_SB.PCI0.RP01.I2C.MUX.CH0 }, Package () { "maximum-power-milliwatt", 1000 }, Package () { "tx-disable-gpios", Package () { ^SFP0, 0, 0, 1} }, Package () { "reset-gpio", Package () { ^SFP0, 0, 1, 1} }, Package () { "mod-def0-gpios", Package () { ^SFP0, 0, 2, 1} }, Package () { "tx-fault-gpios", Package () { ^SFP0, 0, 3, 0} }, Package () { "los-gpios", Package () { ^SFP0, 0, 4, 1} }, }, }) } Device (PHY0) { Name (_HID, "PRP0001") Name (_DSD, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "compatible", "ethernet-phy-ieee802.3-c45" }, Package () { "sfp", \_SB.PCI0.RP01.SFP0 }, Package () { "managed", "in-band-status" }, Package () { "phy-mode", "sgmii" }, }, }) } Signed-off-by: Ruslan Babayev <ruslan@babayev.com> Cc: xe-linux-external@cisco.com Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-28 16:02:33 -07:00
net: sfp: clean up i2c-bus property parsing We currently have some complicated code in sfp_probe() which gets the I2C bus depending on whether the sfp node is DT or ACPI, and we use completely separate lookup functions. This could do with being in a separate function to make the code more readable, so move it to a new function, sfp_i2c_get(). We can also use fwnode_find_reference() to lookup the I2C bus fwnode before then decending into fwnode-type specific parsing. A future cleanup would be to move the fwnode-type specific parsing into the i2c layer, which is where it really should be. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1p1WGJ-0098wS-4w@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-12-03 17:25:15 +00:00
net: phy: sfp: enable i2c-bus detection on ACPI based systems Lookup I2C adapter using the "i2c-bus" device property on ACPI based systems similar to how it's done with DT. An example DSD describing an SFP on an ACPI based system: Device (SFP0) { Name (_HID, "PRP0001") Name (_CRS, ResourceTemplate() { GpioIo(Exclusive, PullDefault, 0, 0, IoRestrictionNone, "\\_SB.PCI0.RP01.GPIO", 0, ResourceConsumer) { 0, 1, 2, 3, 4 } }) Name (_DSD, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "compatible", "sff,sfp" }, Package () { "i2c-bus", \_SB.PCI0.RP01.I2C.MUX.CH0 }, Package () { "maximum-power-milliwatt", 1000 }, Package () { "tx-disable-gpios", Package () { ^SFP0, 0, 0, 1} }, Package () { "reset-gpio", Package () { ^SFP0, 0, 1, 1} }, Package () { "mod-def0-gpios", Package () { ^SFP0, 0, 2, 1} }, Package () { "tx-fault-gpios", Package () { ^SFP0, 0, 3, 0} }, Package () { "los-gpios", Package () { ^SFP0, 0, 4, 1} }, }, }) } Device (PHY0) { Name (_HID, "PRP0001") Name (_DSD, Package () { ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package () { "compatible", "ethernet-phy-ieee802.3-c45" }, Package () { "sfp", \_SB.PCI0.RP01.SFP0 }, Package () { "managed", "in-band-status" }, Package () { "phy-mode", "sgmii" }, }, }) } Signed-off-by: Ruslan Babayev <ruslan@babayev.com> Cc: xe-linux-external@cisco.com Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-05-28 16:02:33 -07:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: rename gpio_of_names[] There's nothing DT specific about the gpio_of_names array, let's drop the _of infix. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-18 10:21:08 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
net: sfp: re-implement soft state polling setup Re-implement the decision making for soft state polling. Instead of generating the soft state mask in sfp_soft_start_poll() by looking at which GPIOs are available, record their availability in sfp_sm_mod_probe() in sfp->state_hw_mask. This will then allow us to clear bits in sfp->state_hw_mask in module specific quirks when the hardware signals should not be used, thereby allowing us to switch to using the software state polling. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-13 20:06:27 +01:00
sfp: add sff module support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-12-14 10:27:47 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: check firmware provided max power Check that the firmware provided maximum power is at least 1W, which is the minimum power level for any SFP module. Now that we enforce the minimum of 1W, we can exit early from sfp_module_parse_power() if the module power is 1W or less. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:09:43 +01:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
net: sfp: check firmware provided max power Check that the firmware provided maximum power is at least 1W, which is the minimum power level for any SFP module. Now that we enforce the minimum of 1W, we can exit early from sfp_module_parse_power() if the module power is 1W or less. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-10-21 16:09:43 +01:00
sfp: add high power module support This patch is the result of work by both Jon Nettleton and Russell King. Jon wrote the original patch, adding support for SFP modules which require a power level greater than '1'. Russell's changes: - Fix the power levels for big-endian, and make the code flow better. - Convert to use device_property_read_u8() - Warn for power levels exceeding host level SFF-8431 says: "To avoid exceeding system power supply limits and cooling capacity, all modules at power up by default shall operate with up to 1.0 W. Hosts supporting Power Level II or III operation may enable a Power Level II or III module through the 2-wire interface. Power Level II or III modules shall assert the power level declaration bit of SFF-8472." Print a warning for modules that exceed the host power level, and leave them operating in power level 1. - Fix i2c write The first byte of any write after the bus address is always the device address. In order to write a value to device D, address I, value V, we need to generate on the bus: S DDDDDDDD A IIIIIIII A VVVVVVVV A P where S = start, R = restart, A = ack, P = stop. Splitting this as two: S DDDDDDDD A IIIIIIII A R DDDDDDDD A VVVVVVVV A P results in the device's address register being written first by I and then by V - the addressed register within the device is not written. - Avoid power mode switching if 0xa2 is not implemented Some modules indicate that they support power level II or power level III, but do not implement address 0xa2, meaning that the bit to set them to high power mode is not accessible. These modules appear to have the sff8472_compliance field set to zero, and also do not implement diagnostics. Detect this, but also ensure that the module does not require the address switching mode, which we do not implement. - Use mW for power level rather than power level number. - Fix high power mode transition We must not switch to SFP_MOD_PRESENT state until we have finished initialising, because the remaining state machines check for that state. Add SFP_MOD_HPOWER as an intermediate state. - Use definition for I2C register address rather than constant. Signed-off-by: Jon Nettleton <jon@solid-run.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-02-27 15:53:12 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add support for rate selection Add support for parsing the rate select thresholds and switching of the RS0 and RS1 signals to the transceiver. This is complicated by various revisions of SFF-8472 and interaction of SFF-8431, SFF-8079 and INF-8074. Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-05-17 11:38:17 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: move module insert reporting out of probe Move the module insertion reporting out of the probe handling, but after we have detected that the upstream has attached (since that is whom we are reporting insertion to.) Only report module removal if we had previously reported a module insertion. This gives cleaner semantics, and means we can probe the module before we have an upstream attached. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-10 14:07:25 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: Stop SFP polling and interrupt handling during shutdown SFP device polling can cause problems during the shutdown process if the parent devices of the network controller have been shut down already. This problem was seen on the iMX6 platform with PCIe devices, where accessing the device after the bus is shut down causes a hang. Free any acquired GPIO interrupts and stop all delayed work in the SFP driver during the shutdown process, so that we ensure that no pending operations are still occurring after the SFP shutdown completes. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:35 -06:00
sfp: Fix error handing in sfp_probe() gpiod_to_irq() never return 0, but returns negative in case of error, check it and set gpio_irq to 0. Fixes: 73970055450e ("sfp: add SFP module support") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201031031053.25264-1-yuehaibing@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-31 11:10:53 +08:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: Unique GPIO interrupt names Dynamically generate a unique GPIO interrupt name, based on the device name and the GPIO name. For example: 103: 0 sx1503q 12 Edge sff2-los 104: 0 sx1503q 13 Edge sff2-tx-fault The sffX indicates the SFP the los and tx-fault are associated with. v3: - reverse Christmas tree new variable - fix spaces vs tabs v2: - added net-next to PATCH part of subject line - switched to devm_kasprintf() Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-06 18:27:07 -07:00
net: sfp: rename gpio_of_names[] There's nothing DT specific about the gpio_of_names array, let's drop the _of infix. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-18 10:21:08 +00:00
net: sfp: Unique GPIO interrupt names Dynamically generate a unique GPIO interrupt name, based on the device name and the GPIO name. For example: 103: 0 sx1503q 12 Edge sff2-los 104: 0 sx1503q 13 Edge sff2-tx-fault The sffX indicates the SFP the los and tx-fault are associated with. v3: - reverse Christmas tree new variable - fix spaces vs tabs v2: - added net-next to PATCH part of subject line - switched to devm_kasprintf() Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-06 18:27:07 -07:00
net: sfp: add error checking with sfp_irq_name Add error checking with sfp_irq_name before use. Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-07 13:32:05 -07:00
net: sfp: Stop SFP polling and interrupt handling during shutdown SFP device polling can cause problems during the shutdown process if the parent devices of the network controller have been shut down already. This problem was seen on the iMX6 platform with PCIe devices, where accessing the device after the bus is shut down causes a hang. Free any acquired GPIO interrupts and stop all delayed work in the SFP driver during the shutdown process, so that we ensure that no pending operations are still occurring after the SFP shutdown completes. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:35 -06:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: Unique GPIO interrupt names Dynamically generate a unique GPIO interrupt name, based on the device name and the GPIO name. For example: 103: 0 sx1503q 12 Edge sff2-los 104: 0 sx1503q 13 Edge sff2-tx-fault The sffX indicates the SFP the los and tx-fault are associated with. v3: - reverse Christmas tree new variable - fix spaces vs tabs v2: - added net-next to PATCH part of subject line - switched to devm_kasprintf() Signed-off-by: Chris Healy <cphealy@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-06 18:27:07 -07:00
net: sfp: Stop SFP polling and interrupt handling during shutdown SFP device polling can cause problems during the shutdown process if the parent devices of the network controller have been shut down already. This problem was seen on the iMX6 platform with PCIe devices, where accessing the device after the bus is shut down causes a hang. Free any acquired GPIO interrupts and stop all delayed work in the SFP driver during the shutdown process, so that we ensure that no pending operations are still occurring after the SFP shutdown completes. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:35 -06:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: Stop SFP polling and interrupt handling during shutdown SFP device polling can cause problems during the shutdown process if the parent devices of the network controller have been shut down already. This problem was seen on the iMX6 platform with PCIe devices, where accessing the device after the bus is shut down causes a hang. Free any acquired GPIO interrupts and stop all delayed work in the SFP driver during the shutdown process, so that we ensure that no pending operations are still occurring after the SFP shutdown completes. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:35 -06:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: soft status and control support 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 <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-20 12:29:59 +00:00
net: sfp: improve poll interval handling The poll interval is a fixed value, so we don't need a static variable for it. The change also allows to use standard macro module_platform_driver, avoiding some boilerplate code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/b8079f96-6865-431c-a908-a0b9e9bd5379@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-27 22:23:19 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: sfp: warn the user when no tx_disable pin is available In case no Tx disable pin is available the SFP modules will always be emitting. This could be an issue when using modules using laser as their light source as we would have no way to disable it when the fiber is removed. This patch adds a warning when registering an SFP cage which do not have its tx_disable pin wired or available. Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2018-05-22 12:17:59 +02:00
net: sfp: do not probe SFP module before we're attached When we probe a SFP module, we expect to be able to call the upstream device's module_insert() function so that the upstream link can be configured. However, when the upstream device is delayed, we currently may end up probing the module before the upstream device is available, and lose the module_insert() call. Avoid this by holding off probing the module until the SFP bus is properly connected to both the SFP socket driver and the upstream driver. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-02-06 10:52:30 +00:00
net: phy: sfp: Add support for SMBus module access The SFP module's eeprom and internals are accessible through an i2c bus. It is possible that the SFP might be connected to an SMBus-only controller, such as the one found in some PHY devices in the VSC85xx family. Introduce a set of sfp read/write ops that are going to be used if the i2c bus is only capable of doing smbus byte accesses. As Single-byte SMBus transaction go against SFF-8472 and breaks the atomicity for diagnostics data access, hwmon is disabled in the case of SMBus access. Moreover, as this may cause other instabilities, print a warning at probe time to indicate that the setup may be unreliable because of the hardware design. As hwmon may be disabled for both broken EEPROM and smbus, the warnings are udpated accordingly. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20250322075745.120831-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-03-22 08:57:44 +01:00
net: sfp: add debugfs support Add debugfs support to SFP so that the internal state of the SFP state machines and hardware signal state can be viewed from userspace, rather than having to compile a debug kernel to view state transitions in the kernel log. The 'state' output looks like: Module state: empty Module probe attempts: 0 0 Device state: up Main state: down Fault recovery remaining retries: 5 PHY probe remaining retries: 12 moddef0: 0 rx_los: 1 tx_fault: 1 tx_disable: 1 Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1kyYRe-0004kN-3F@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:59:38 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: Convert to platform remove callback returning void The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Link: https://lore.kernel.org/r/20231117095922.876489-6-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/7c1d50d559c0e0e36a20eb3e410f6e9d3f884b6f.1701713943.git.u.kleine-koenig@pengutronix.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-12-04 19:30:44 +01:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: add debugfs support Add debugfs support to SFP so that the internal state of the SFP state machines and hardware signal state can be viewed from userspace, rather than having to compile a debug kernel to view state transitions in the kernel log. The 'state' output looks like: Module state: empty Module probe attempts: 0 0 Device state: up Main state: down Fault recovery remaining retries: 5 PHY probe remaining retries: 12 moddef0: 0 rx_los: 1 tx_fault: 1 tx_disable: 1 Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1kyYRe-0004kN-3F@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-01-10 10:59:38 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: fix unbind When unbinding, we don't correctly tear down the module state, leaving (for example) the hwmon registration behind. Ensure everything is properly removed by sending a remove event at unbind. Fixes: 6b0da5c9c1a3 ("net: sfp: track upstream's attachment state in state machine") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-12-03 23:51:22 +00:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: Stop SFP polling and interrupt handling during shutdown SFP device polling can cause problems during the shutdown process if the parent devices of the network controller have been shut down already. This problem was seen on the iMX6 platform with PCIe devices, where accessing the device after the bus is shut down causes a hang. Free any acquired GPIO interrupts and stop all delayed work in the SFP driver during the shutdown process, so that we ensure that no pending operations are still occurring after the SFP shutdown completes. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:35 -06:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: Switch back to struct platform_driver::remove() After commit 0edb555a65d1 ("platform: Make platform_driver::remove() return void") .remove() is (again) the right callback to implement for platform drivers. Convert all platform drivers below drivers/net after the previous conversion commits apart from the wireless drivers to use .remove(), with the eventual goal to drop struct platform_driver::remove_new(). As .remove() and .remove_new() have the same prototypes, conversion is done by just changing the structure member name in the driver initializer. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Sergey Ryazanov <ryazanov.s.a@gmail.com> Acked-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-10-03 12:01:06 +02:00
net: sfp: Stop SFP polling and interrupt handling during shutdown SFP device polling can cause problems during the shutdown process if the parent devices of the network controller have been shut down already. This problem was seen on the iMX6 platform with PCIe devices, where accessing the device after the bus is shut down causes a hang. Free any acquired GPIO interrupts and stop all delayed work in the SFP driver during the shutdown process, so that we ensure that no pending operations are still occurring after the SFP shutdown completes. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: David S. Miller <davem@davemloft.net>
2019-06-07 10:42:35 -06:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: sfp: improve poll interval handling The poll interval is a fixed value, so we don't need a static variable for it. The change also allows to use standard macro module_platform_driver, avoiding some boilerplate code. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://patch.msgid.link/b8079f96-6865-431c-a908-a0b9e9bd5379@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-09-27 22:23:19 +02:00
sfp: add SFP module support Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2017-07-25 15:03:39 +01:00
net: phy: fill in missing MODULE_DESCRIPTION()s W=1 builds now warn if a module is built without a MODULE_DESCRIPTION(). Fill them in based on the Kconfig text, or similar. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/20231028184458.99448-2-andrew@lunn.ch Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-10-28 20:44:57 +02:00