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 i

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>

show more ...

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
th

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>

show more ...

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 st

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>

show more ...

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

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>

show more ...

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 initialis

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>

show more ...

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

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>

show more ...

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()

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>

show more ...

net: sfp: control TX_DISABLE and phy only from main state machine

We initialise TX_DISABLE when the sfp cage is probed, and then
maintain its state in the main state machine. However, t

net: sfp: control TX_DISABLE and phy only from main state machine

We initialise TX_DISABLE when the sfp cage is probed, and then
maintain its state in the main state machine. However, the module
state machine:
- negates it when detecting a newly inserted module when it's already
guaranteed to be negated.
- negates it when the module is removed, but the main state machine
will do this anyway.

Make TX_DISABLE entirely controlled by the main state machine.

The main state machine also probes the module for a PHY, and removes
the PHY when the the module is removed. Hence, removing the PHY in
sfp_sm_module_remove() is also redundant, and is a left-over from
when we tried to probe for the PHY from the module 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>

show more ...

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

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>

show more ...

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+ker

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>

show more ...

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
i

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>

show more ...

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, ha

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>

show more ...

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+

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>

show more ...

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@ar

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>

show more ...

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 devi

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>

show more ...

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

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>

show more ...

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

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>

show more ...

net: phy: sfp: clean up a condition

The acpi_node_get_property_reference() doesn't return ACPI error codes,
it just returns regular negative kernel error codes. This patch doesn't
a

net: phy: sfp: clean up a condition

The acpi_node_get_property_reference() doesn't return ACPI error codes,
it just returns regular negative kernel error codes. This patch doesn't
affect run time, it's just a clean up.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Ruslan Babayev <ruslan@babayev.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

show more ...

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 r

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>

show more ...

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 b

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>

show more ...

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

Some ISDN files that got removed in net-next had some changes
done in mainline, take the removals.

Signed-off-by: D

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

Some ISDN files that got removed in net-next had some changes
done in mainline, take the removals.

Signed-off-by: David S. Miller <davem@davemloft.net>

show more ...

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 sp

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>

show more ...

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 e

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>

show more ...

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

The netfilter conflicts were rather simple overlapping
changes.

However, the cls_tcindex.c stuff was a bit more com

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

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 <davem@davemloft.net>

show more ...

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

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>

show more ...