BMC/Intel-BMC/linux.git/drivers/net/phy/sfp.c, branch dev-5.2

net: phy: sfp: hwmon: Fix scaling of RX power

2019-07-28T06:27:14+00:00

[ Upstream commit 0cea0e1148fe134a4a3aaf0b1496f09241fb943a ] 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 Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: sfp: add mutex to prevent concurrent state checks

2019-07-26T07:10:23+00:00

[ Upstream commit 2158e856f56bb762ef90f3ec244d41a519826f75 ] 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 Signed-off-by: Robert Hancock Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: sfp: read eeprom in maximum 16 byte increments

2019-06-03T22:16:37+00:00

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 Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2019-02-15T20:38:38+00:00

The netfilter conflicts were rather simple overlapping changes. However, the cls_tcindex.c stuff was a bit more complex. On the 'net' side, Cong is fixing several races and memory leaks. Whilst on the 'net-next' side we have Vlad adding the rtnl-ness support. What I've decided to do, in order to resolve this, is revert the conversion over to using a workqueue that Cong did, bringing us back to pure RCU. I did it this way because I believe that either Cong's races don't apply with have Vlad did things, or Cong will have to implement the race fix slightly differently. Signed-off-by: David S. Miller

net: sfp: do not probe SFP module before we're attached

2019-02-08T23:11:25+00:00

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 Signed-off-by: David S. Miller

net: phy: Convert some PHY and MDIO driver files to SPDX headers

2019-01-23T04:53:08+00:00

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 Signed-off-by: David S. Miller

net: phy: sfp: remove sfp_mutex's definition

2018-10-11T19:10:06+00:00

The sfp_mutex variable is defined but never used in this file. Not even in the commit that introduced that variable. Remove sfp_mutex, it has no purpose. Cc: Andrew Lunn Cc: Florian Fainelli Cc: "David S. Miller" Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller

net: phy: sfp: Fix unregistering of HWMON SFP device

2018-09-27T03:23:31+00:00

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 Fixes: 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") Signed-off-by: Andrew Lunn Tested-by: Florian Fainelli Signed-off-by: David S. Miller

net: phy: sfp: Handle unimplemented hwmon limits and alarms

2018-09-04T19:22:41+00:00

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 Signed-off-by: David S. Miller

net: phy: sftp: print debug message with text, not numbers

2018-08-09T21:19:20+00:00

Convert the state numbers, device state, etc from numbers to strings when printing debug messages. Signed-off-by: Andrew Lunn Acked-by: Florian Fainelli Signed-off-by: David S. Miller