From: Steve Hodgson <shodgson@solarflare.com>
Commit 357d46a17e "sfc: QT202x: Remove
unreliable MMD check at initialisation" broke initialisation of the
SFE4002. efx_mdio_reset_mmd() returns a positive value rather than 0
on success. The above commit causes this value to be propagated up
by qt202x_reset_phy(), which is treated as a failure by its callers.
Change qt202x_reset_phy() to return 0 if successful.
The PCI layer treats >0 as "fail, but please call remove() anyway",
which means that unloading the driver would cause a crash. Add a
WARN_ON() on the failure path of efx_pci_probe() to provide early
warning if there are any other cases where we do this.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Checking the PHY XS MMD here is unnecessary and can give false negatives.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some cables have EEPROMs that conflict with the PHY's on-board EEPROM
so it cannot load firmware.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The PHY's firmware very occasionally appears to lock up very early, but
with the heartbeat update still running. Rebooting the microcontroller
core seems to be sufficient to recover.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The PHY boots in a mode which is not necessarily optimal. This change
switches it to self-configure mode (except when in loopback, which
won't work in that mode if an SFP+ module is not present) by rebooting
the PHY's microcontroller, and replicating the sequence of configuration
writes from the boot EEPROM with the appropriate changes.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If we see the PHY remaining stuck in a link-down state due to PCS being
down while PMA/PMD is up, we briefly switch to PMA/PMD loopback and back,
which usually unsticks it.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This prevents efx->link_advertising from being blatted during
a reset.
The phy_short_reach sysfs node is now destroyed later in the
port shutdown process, so check for STATE_RUNNING after
acquiring the rtnl_lock (just like in set_phy_flash_cfg).
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This driver has been mostly rewritten since Michael Brown's initial
work, so swap the order of the authors.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
New NICs have firmware managing the PHY, and we will discover the PHY
capabilities at run-time. Replace the static data with probe() and
test_name() operations.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
New NICs and PHYs support a wider variety of loopback modes.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Refactor PHY, MAC and NIC configuration operations so that the
existing link configuration can be re-pushed with:
efx->phy_op->reconfigure(efx);
efx->mac_op->reconfigure(efx);
and a new configuration with:
efx->nic_op->reconfigure_port(efx);
(plus locking and error-checking).
We have not held the link settings in software (aside from flow
control), and have relied on asking the hardware what they are. This
is a problem because in some cases the hardware may no longer be in a
state to tell us. In particular, if an entire multi-port board is
reset through one port, the driver bindings to other ports have no
chance to save settings before recovering.
We only actually need to keep track of the autonegotiation settings,
so add an ethtool advertising mask to struct efx_nic, initialise it
in PHY init and update it as necessary.
Remove now-unneeded uses of efx_phy_op::{get,set}_settings() and
struct ethtool_cmd.
Much of this was done by Steve Hodgson <shodgson@solarflare.com>.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reading standard registers on the QT2025C before its firmware has
booted may cause the boot process to fail. Therefore, follow the
recommended reset sequence before reading its id registers. Either
order works for the QT2022C2, so don't differentiate.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Falcon can generate events for LASI interrupts from the PHY, but in
practice we have never implemented this in reference designs. Instead
we have polled, inserted the appropriate events, and then handled the
events later. This is a waste of time and code.
Instead, make PHY poll functions update the link state synchronously
and report whether it changed. We can still make use of the LASI
registers as a shortcut on the SFT9001.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Put all static information in struct falcon_board_type and replace it
with a pointer in struct falcon_board. Simplify probing aocordingly.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Rename struct efx_board to struct falcon_board.
Introduce and use inline function to look up board info from struct
efx_nic, in preparation for moving it.
Move board init and fini calls into NIC probe and remove functions.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
efx_board::init_leds was introduced as a second stage of
initialisation because of the inter-dependency between the board and
PHY. We want to move board initialisation into NIC probing, which is
too early to use MDIO, so SFN4111T initialisation also needs to be
split.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Only some PHYs have firmware support for a LED blink mode, so we
currently blink the others in a timer function. Since all PHYs have
simple on and off modes, we don't gain anything by using multiple
blink implementations. Also, since we have a process context there
is no need to use a timer.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The 'XFP' driver is really a driver for the QT2022C2 and QT2025C PHYs,
covering both more and less than XFP. Rename its functions and
constants to reflect reality and to reduce namespace pollution when
sfc is a built-in driver.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
