2008-04-27 11:55:59 +00:00
|
|
|
/****************************************************************************
|
2013-08-29 22:32:48 +00:00
|
|
|
* Driver for Solarflare network controllers and boards
|
2011-02-25 00:01:34 +00:00
|
|
|
* Copyright 2007-2011 Solarflare Communications Inc.
|
2008-04-27 11:55:59 +00:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License version 2 as published
|
|
|
|
* by the Free Software Foundation, incorporated herein by reference.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/delay.h>
|
2009-01-19 05:50:16 +00:00
|
|
|
#include <linux/rtnetlink.h>
|
2008-04-27 11:55:59 +00:00
|
|
|
#include <linux/seq_file.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 08:04:11 +00:00
|
|
|
#include <linux/slab.h>
|
2008-04-27 11:55:59 +00:00
|
|
|
#include "efx.h"
|
|
|
|
#include "mdio_10g.h"
|
2009-11-29 15:12:08 +00:00
|
|
|
#include "nic.h"
|
2008-04-27 11:55:59 +00:00
|
|
|
#include "phy.h"
|
2008-12-13 06:00:17 +00:00
|
|
|
#include "workarounds.h"
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2010-09-22 10:00:11 +00:00
|
|
|
/* We expect these MMDs to be in the package. */
|
2009-04-29 08:05:08 +00:00
|
|
|
#define TENXPRESS_REQUIRED_DEVS (MDIO_DEVS_PMAPMD | \
|
|
|
|
MDIO_DEVS_PCS | \
|
|
|
|
MDIO_DEVS_PHYXS | \
|
|
|
|
MDIO_DEVS_AN)
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
#define SFX7101_LOOPBACKS ((1 << LOOPBACK_PHYXS) | \
|
|
|
|
(1 << LOOPBACK_PCS) | \
|
|
|
|
(1 << LOOPBACK_PMAPMD) | \
|
2009-11-29 15:08:41 +00:00
|
|
|
(1 << LOOPBACK_PHYXS_WS))
|
2008-12-13 06:00:17 +00:00
|
|
|
|
2008-04-27 11:55:59 +00:00
|
|
|
/* We complain if we fail to see the link partner as 10G capable this many
|
|
|
|
* times in a row (must be > 1 as sampling the autoneg. registers is racy)
|
|
|
|
*/
|
|
|
|
#define MAX_BAD_LP_TRIES (5)
|
|
|
|
|
|
|
|
/* Extended control register */
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PMA_PMD_XCONTROL_REG 49152
|
|
|
|
#define PMA_PMD_EXT_GMII_EN_LBN 1
|
|
|
|
#define PMA_PMD_EXT_GMII_EN_WIDTH 1
|
|
|
|
#define PMA_PMD_EXT_CLK_OUT_LBN 2
|
|
|
|
#define PMA_PMD_EXT_CLK_OUT_WIDTH 1
|
2010-09-22 10:00:11 +00:00
|
|
|
#define PMA_PMD_LNPGA_POWERDOWN_LBN 8
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PMA_PMD_LNPGA_POWERDOWN_WIDTH 1
|
|
|
|
#define PMA_PMD_EXT_CLK312_WIDTH 1
|
|
|
|
#define PMA_PMD_EXT_LPOWER_LBN 12
|
|
|
|
#define PMA_PMD_EXT_LPOWER_WIDTH 1
|
2009-01-29 17:48:10 +00:00
|
|
|
#define PMA_PMD_EXT_ROBUST_LBN 14
|
|
|
|
#define PMA_PMD_EXT_ROBUST_WIDTH 1
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PMA_PMD_EXT_SSR_LBN 15
|
|
|
|
#define PMA_PMD_EXT_SSR_WIDTH 1
|
2008-04-27 11:55:59 +00:00
|
|
|
|
|
|
|
/* extended status register */
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PMA_PMD_XSTATUS_REG 49153
|
2009-06-10 05:30:05 +00:00
|
|
|
#define PMA_PMD_XSTAT_MDIX_LBN 14
|
2008-04-27 11:55:59 +00:00
|
|
|
#define PMA_PMD_XSTAT_FLP_LBN (12)
|
|
|
|
|
|
|
|
/* LED control register */
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PMA_PMD_LED_CTRL_REG 49159
|
2008-04-27 11:55:59 +00:00
|
|
|
#define PMA_PMA_LED_ACTIVITY_LBN (3)
|
|
|
|
|
|
|
|
/* LED function override register */
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PMA_PMD_LED_OVERR_REG 49161
|
2008-04-27 11:55:59 +00:00
|
|
|
/* Bit positions for different LEDs (there are more but not wired on SFE4001)*/
|
|
|
|
#define PMA_PMD_LED_LINK_LBN (0)
|
|
|
|
#define PMA_PMD_LED_SPEED_LBN (2)
|
|
|
|
#define PMA_PMD_LED_TX_LBN (4)
|
|
|
|
#define PMA_PMD_LED_RX_LBN (6)
|
|
|
|
/* Override settings */
|
|
|
|
#define PMA_PMD_LED_AUTO (0) /* H/W control */
|
|
|
|
#define PMA_PMD_LED_ON (1)
|
|
|
|
#define PMA_PMD_LED_OFF (2)
|
|
|
|
#define PMA_PMD_LED_FLASH (3)
|
2008-12-13 05:50:46 +00:00
|
|
|
#define PMA_PMD_LED_MASK 3
|
2008-04-27 11:55:59 +00:00
|
|
|
/* All LEDs under hardware control */
|
|
|
|
/* Green and Amber under hardware control, Red off */
|
2009-11-23 16:02:49 +00:00
|
|
|
#define SFX7101_PMA_PMD_LED_DEFAULT (PMA_PMD_LED_OFF << PMA_PMD_LED_RX_LBN)
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PMA_PMD_SPEED_ENABLE_REG 49192
|
|
|
|
#define PMA_PMD_100TX_ADV_LBN 1
|
|
|
|
#define PMA_PMD_100TX_ADV_WIDTH 1
|
|
|
|
#define PMA_PMD_1000T_ADV_LBN 2
|
|
|
|
#define PMA_PMD_1000T_ADV_WIDTH 1
|
|
|
|
#define PMA_PMD_10000T_ADV_LBN 3
|
|
|
|
#define PMA_PMD_10000T_ADV_WIDTH 1
|
|
|
|
#define PMA_PMD_SPEED_LBN 4
|
|
|
|
#define PMA_PMD_SPEED_WIDTH 4
|
|
|
|
|
2010-09-22 10:00:11 +00:00
|
|
|
/* Misc register defines */
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PCS_CLOCK_CTRL_REG 55297
|
2008-04-27 11:55:59 +00:00
|
|
|
#define PLL312_RST_N_LBN 2
|
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PCS_SOFT_RST2_REG 55302
|
2008-04-27 11:55:59 +00:00
|
|
|
#define SERDES_RST_N_LBN 13
|
|
|
|
#define XGXS_RST_N_LBN 12
|
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PCS_TEST_SELECT_REG 55303 /* PRM 10.5.8 */
|
2008-04-27 11:55:59 +00:00
|
|
|
#define CLK312_EN_LBN 3
|
|
|
|
|
2008-05-07 12:36:19 +00:00
|
|
|
/* PHYXS registers */
|
2008-12-13 06:00:17 +00:00
|
|
|
#define PHYXS_XCONTROL_REG 49152
|
|
|
|
#define PHYXS_RESET_LBN 15
|
|
|
|
#define PHYXS_RESET_WIDTH 1
|
|
|
|
|
2008-05-07 12:36:19 +00:00
|
|
|
#define PHYXS_TEST1 (49162)
|
|
|
|
#define LOOPBACK_NEAR_LBN (8)
|
|
|
|
#define LOOPBACK_NEAR_WIDTH (1)
|
|
|
|
|
2008-04-27 11:55:59 +00:00
|
|
|
/* Boot status register */
|
2009-02-27 13:06:45 +00:00
|
|
|
#define PCS_BOOT_STATUS_REG 53248
|
|
|
|
#define PCS_BOOT_FATAL_ERROR_LBN 0
|
|
|
|
#define PCS_BOOT_PROGRESS_LBN 1
|
|
|
|
#define PCS_BOOT_PROGRESS_WIDTH 2
|
|
|
|
#define PCS_BOOT_PROGRESS_INIT 0
|
|
|
|
#define PCS_BOOT_PROGRESS_WAIT_MDIO 1
|
|
|
|
#define PCS_BOOT_PROGRESS_CHECKSUM 2
|
|
|
|
#define PCS_BOOT_PROGRESS_JUMP 3
|
|
|
|
#define PCS_BOOT_DOWNLOAD_WAIT_LBN 3
|
|
|
|
#define PCS_BOOT_CODE_STARTED_LBN 4
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
/* 100M/1G PHY registers */
|
|
|
|
#define GPHY_XCONTROL_REG 49152
|
|
|
|
#define GPHY_ISOLATE_LBN 10
|
|
|
|
#define GPHY_ISOLATE_WIDTH 1
|
2012-01-05 17:19:45 +00:00
|
|
|
#define GPHY_DUPLEX_LBN 8
|
2008-12-13 06:00:17 +00:00
|
|
|
#define GPHY_DUPLEX_WIDTH 1
|
|
|
|
#define GPHY_LOOPBACK_NEAR_LBN 14
|
|
|
|
#define GPHY_LOOPBACK_NEAR_WIDTH 1
|
|
|
|
|
|
|
|
#define C22EXT_STATUS_REG 49153
|
|
|
|
#define C22EXT_STATUS_LINK_LBN 2
|
|
|
|
#define C22EXT_STATUS_LINK_WIDTH 1
|
|
|
|
|
2009-01-29 17:59:37 +00:00
|
|
|
#define C22EXT_MSTSLV_CTRL 49161
|
|
|
|
#define C22EXT_MSTSLV_CTRL_ADV_1000_HD_LBN 8
|
|
|
|
#define C22EXT_MSTSLV_CTRL_ADV_1000_FD_LBN 9
|
|
|
|
|
|
|
|
#define C22EXT_MSTSLV_STATUS 49162
|
|
|
|
#define C22EXT_MSTSLV_STATUS_LP_1000_HD_LBN 10
|
|
|
|
#define C22EXT_MSTSLV_STATUS_LP_1000_FD_LBN 11
|
2008-12-13 06:00:17 +00:00
|
|
|
|
2008-04-27 11:55:59 +00:00
|
|
|
/* Time to wait between powering down the LNPGA and turning off the power
|
|
|
|
* rails */
|
|
|
|
#define LNPGA_PDOWN_WAIT (HZ / 5)
|
|
|
|
|
|
|
|
struct tenxpress_phy_data {
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
enum ef4_loopback_mode loopback_mode;
|
|
|
|
enum ef4_phy_mode phy_mode;
|
2008-04-27 11:55:59 +00:00
|
|
|
int bad_lp_tries;
|
|
|
|
};
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static int tenxpress_init(struct ef4_nic *efx)
|
2008-04-27 11:55:59 +00:00
|
|
|
{
|
2010-09-22 10:00:11 +00:00
|
|
|
/* Enable 312.5 MHz clock */
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_write(efx, MDIO_MMD_PCS, PCS_TEST_SELECT_REG,
|
2010-09-22 10:00:11 +00:00
|
|
|
1 << CLK312_EN_LBN);
|
2008-04-27 11:55:59 +00:00
|
|
|
|
|
|
|
/* Set the LEDs up as: Green = Link, Amber = Link/Act, Red = Off */
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_set_flag(efx, MDIO_MMD_PMAPMD, PMA_PMD_LED_CTRL_REG,
|
2010-09-22 10:00:11 +00:00
|
|
|
1 << PMA_PMA_LED_ACTIVITY_LBN, true);
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_write(efx, MDIO_MMD_PMAPMD, PMA_PMD_LED_OVERR_REG,
|
2010-09-22 10:00:11 +00:00
|
|
|
SFX7101_PMA_PMD_LED_DEFAULT);
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2009-02-27 13:06:45 +00:00
|
|
|
return 0;
|
2008-04-27 11:55:59 +00:00
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static int tenxpress_phy_probe(struct ef4_nic *efx)
|
2009-11-29 15:08:55 +00:00
|
|
|
{
|
2009-12-23 13:46:36 +00:00
|
|
|
struct tenxpress_phy_data *phy_data;
|
|
|
|
|
|
|
|
/* Allocate phy private storage */
|
|
|
|
phy_data = kzalloc(sizeof(*phy_data), GFP_KERNEL);
|
|
|
|
if (!phy_data)
|
|
|
|
return -ENOMEM;
|
|
|
|
efx->phy_data = phy_data;
|
|
|
|
phy_data->phy_mode = efx->phy_mode;
|
|
|
|
|
2010-09-22 10:00:11 +00:00
|
|
|
efx->mdio.mmds = TENXPRESS_REQUIRED_DEVS;
|
|
|
|
efx->mdio.mode_support = MDIO_SUPPORTS_C45;
|
2009-12-23 13:46:36 +00:00
|
|
|
|
2010-09-22 10:00:11 +00:00
|
|
|
efx->loopback_modes = SFX7101_LOOPBACKS | FALCON_XMAC_LOOPBACKS;
|
2009-12-23 13:46:36 +00:00
|
|
|
|
2010-09-22 10:00:11 +00:00
|
|
|
efx->link_advertising = (ADVERTISED_TP | ADVERTISED_Autoneg |
|
|
|
|
ADVERTISED_10000baseT_Full);
|
2009-11-29 15:08:55 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static int tenxpress_phy_init(struct ef4_nic *efx)
|
2008-04-27 11:55:59 +00:00
|
|
|
{
|
2009-12-23 13:46:36 +00:00
|
|
|
int rc;
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2009-11-25 16:09:41 +00:00
|
|
|
falcon_board(efx)->type->init_phy(efx);
|
2009-11-23 16:04:23 +00:00
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
if (!(efx->phy_mode & PHY_MODE_SPECIAL)) {
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
rc = ef4_mdio_wait_reset_mmds(efx, TENXPRESS_REQUIRED_DEVS);
|
2008-12-13 06:00:17 +00:00
|
|
|
if (rc < 0)
|
2009-12-23 13:46:36 +00:00
|
|
|
return rc;
|
2008-12-13 06:00:17 +00:00
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
rc = ef4_mdio_check_mmds(efx, TENXPRESS_REQUIRED_DEVS);
|
2008-12-13 06:00:17 +00:00
|
|
|
if (rc < 0)
|
2009-12-23 13:46:36 +00:00
|
|
|
return rc;
|
2008-12-13 06:00:17 +00:00
|
|
|
}
|
2008-04-27 11:55:59 +00:00
|
|
|
|
|
|
|
rc = tenxpress_init(efx);
|
|
|
|
if (rc < 0)
|
2009-12-23 13:46:36 +00:00
|
|
|
return rc;
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2009-12-23 13:46:36 +00:00
|
|
|
/* Reinitialise flow control settings */
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_link_set_wanted_fc(efx, efx->wanted_fc);
|
|
|
|
ef4_mdio_an_reconfigure(efx);
|
2009-10-12 09:27:07 +00:00
|
|
|
|
2008-04-27 11:55:59 +00:00
|
|
|
schedule_timeout_uninterruptible(HZ / 5); /* 200ms */
|
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
/* Let XGXS and SerDes out of reset */
|
2008-04-27 11:55:59 +00:00
|
|
|
falcon_reset_xaui(efx);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
/* Perform a "special software reset" on the PHY. The caller is
|
|
|
|
* responsible for saving and restoring the PHY hardware registers
|
|
|
|
* properly, and masking/unmasking LASI */
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static int tenxpress_special_reset(struct ef4_nic *efx)
|
2008-05-07 12:36:19 +00:00
|
|
|
{
|
|
|
|
int rc, reg;
|
|
|
|
|
2010-09-22 10:00:11 +00:00
|
|
|
/* The XGMAC clock is driven from the SFX7101 312MHz clock, so
|
2008-09-01 11:49:25 +00:00
|
|
|
* a special software reset can glitch the XGMAC sufficiently for stats
|
2009-01-29 18:00:07 +00:00
|
|
|
* requests to fail. */
|
2009-11-25 16:11:35 +00:00
|
|
|
falcon_stop_nic_stats(efx);
|
2008-05-07 12:36:19 +00:00
|
|
|
|
|
|
|
/* Initiate reset */
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
reg = ef4_mdio_read(efx, MDIO_MMD_PMAPMD, PMA_PMD_XCONTROL_REG);
|
2008-05-07 12:36:19 +00:00
|
|
|
reg |= (1 << PMA_PMD_EXT_SSR_LBN);
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_write(efx, MDIO_MMD_PMAPMD, PMA_PMD_XCONTROL_REG, reg);
|
2008-05-07 12:36:19 +00:00
|
|
|
|
2008-09-01 11:49:25 +00:00
|
|
|
mdelay(200);
|
2008-05-07 12:36:19 +00:00
|
|
|
|
|
|
|
/* Wait for the blocks to come out of reset */
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
rc = ef4_mdio_wait_reset_mmds(efx, TENXPRESS_REQUIRED_DEVS);
|
2008-05-07 12:36:19 +00:00
|
|
|
if (rc < 0)
|
2009-01-29 18:00:07 +00:00
|
|
|
goto out;
|
2008-05-07 12:36:19 +00:00
|
|
|
|
|
|
|
/* Try and reconfigure the device */
|
|
|
|
rc = tenxpress_init(efx);
|
|
|
|
if (rc < 0)
|
2009-01-29 18:00:07 +00:00
|
|
|
goto out;
|
2008-05-07 12:36:19 +00:00
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
/* Wait for the XGXS state machine to churn */
|
|
|
|
mdelay(10);
|
2009-01-29 18:00:07 +00:00
|
|
|
out:
|
2009-11-25 16:11:35 +00:00
|
|
|
falcon_start_nic_stats(efx);
|
2008-09-01 11:49:25 +00:00
|
|
|
return rc;
|
2008-05-07 12:36:19 +00:00
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static void sfx7101_check_bad_lp(struct ef4_nic *efx, bool link_ok)
|
2008-04-27 11:55:59 +00:00
|
|
|
{
|
|
|
|
struct tenxpress_phy_data *pd = efx->phy_data;
|
2008-12-13 05:50:46 +00:00
|
|
|
bool bad_lp;
|
2008-04-27 11:55:59 +00:00
|
|
|
int reg;
|
|
|
|
|
2008-12-13 05:50:46 +00:00
|
|
|
if (link_ok) {
|
|
|
|
bad_lp = false;
|
|
|
|
} else {
|
|
|
|
/* Check that AN has started but not completed. */
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
reg = ef4_mdio_read(efx, MDIO_MMD_AN, MDIO_STAT1);
|
2009-04-29 08:05:08 +00:00
|
|
|
if (!(reg & MDIO_AN_STAT1_LPABLE))
|
2008-12-13 05:50:46 +00:00
|
|
|
return; /* LP status is unknown */
|
2009-04-29 08:05:08 +00:00
|
|
|
bad_lp = !(reg & MDIO_AN_STAT1_COMPLETE);
|
2008-12-13 05:50:46 +00:00
|
|
|
if (bad_lp)
|
|
|
|
pd->bad_lp_tries++;
|
|
|
|
}
|
|
|
|
|
2008-04-27 11:55:59 +00:00
|
|
|
/* Nothing to do if all is well and was previously so. */
|
2008-12-13 05:50:46 +00:00
|
|
|
if (!pd->bad_lp_tries)
|
2008-04-27 11:55:59 +00:00
|
|
|
return;
|
|
|
|
|
2008-12-13 05:50:46 +00:00
|
|
|
/* Use the RX (red) LED as an error indicator once we've seen AN
|
|
|
|
* failure several times in a row, and also log a message. */
|
|
|
|
if (!bad_lp || pd->bad_lp_tries == MAX_BAD_LP_TRIES) {
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
reg = ef4_mdio_read(efx, MDIO_MMD_PMAPMD,
|
2009-04-29 08:05:08 +00:00
|
|
|
PMA_PMD_LED_OVERR_REG);
|
2008-12-13 05:50:46 +00:00
|
|
|
reg &= ~(PMA_PMD_LED_MASK << PMA_PMD_LED_RX_LBN);
|
|
|
|
if (!bad_lp) {
|
|
|
|
reg |= PMA_PMD_LED_OFF << PMA_PMD_LED_RX_LBN;
|
|
|
|
} else {
|
|
|
|
reg |= PMA_PMD_LED_FLASH << PMA_PMD_LED_RX_LBN;
|
2010-06-23 11:30:07 +00:00
|
|
|
netif_err(efx, link, efx->net_dev,
|
|
|
|
"appears to be plugged into a port"
|
|
|
|
" that is not 10GBASE-T capable. The PHY"
|
|
|
|
" supports 10GBASE-T ONLY, so no link can"
|
|
|
|
" be established\n");
|
2008-12-13 05:50:46 +00:00
|
|
|
}
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_write(efx, MDIO_MMD_PMAPMD,
|
2009-04-29 08:05:08 +00:00
|
|
|
PMA_PMD_LED_OVERR_REG, reg);
|
2008-12-13 05:50:46 +00:00
|
|
|
pd->bad_lp_tries = bad_lp;
|
2008-04-27 11:55:59 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static bool sfx7101_link_ok(struct ef4_nic *efx)
|
2008-04-27 11:55:59 +00:00
|
|
|
{
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
return ef4_mdio_links_ok(efx,
|
2009-04-29 08:05:08 +00:00
|
|
|
MDIO_DEVS_PMAPMD |
|
|
|
|
MDIO_DEVS_PCS |
|
|
|
|
MDIO_DEVS_PHYXS);
|
2008-12-13 06:00:17 +00:00
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static void tenxpress_ext_loopback(struct ef4_nic *efx)
|
2008-05-07 12:36:19 +00:00
|
|
|
{
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_set_flag(efx, MDIO_MMD_PHYXS, PHYXS_TEST1,
|
2009-04-29 08:05:08 +00:00
|
|
|
1 << LOOPBACK_NEAR_LBN,
|
|
|
|
efx->loopback_mode == LOOPBACK_PHYXS);
|
2008-12-13 06:00:17 +00:00
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static void tenxpress_low_power(struct ef4_nic *efx)
|
2008-12-13 06:00:17 +00:00
|
|
|
{
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_set_mmds_lpower(
|
2010-09-22 10:00:11 +00:00
|
|
|
efx, !!(efx->phy_mode & PHY_MODE_LOW_POWER),
|
|
|
|
TENXPRESS_REQUIRED_DEVS);
|
2008-05-07 12:36:19 +00:00
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static int tenxpress_phy_reconfigure(struct ef4_nic *efx)
|
2008-04-27 11:55:59 +00:00
|
|
|
{
|
2008-05-07 12:36:19 +00:00
|
|
|
struct tenxpress_phy_data *phy_data = efx->phy_data;
|
2009-01-29 17:49:09 +00:00
|
|
|
bool phy_mode_change, loop_reset;
|
2008-05-07 12:36:19 +00:00
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
if (efx->phy_mode & (PHY_MODE_OFF | PHY_MODE_SPECIAL)) {
|
2008-09-01 11:48:17 +00:00
|
|
|
phy_data->phy_mode = efx->phy_mode;
|
2009-11-29 03:42:41 +00:00
|
|
|
return 0;
|
2008-09-01 11:48:17 +00:00
|
|
|
}
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2008-12-13 06:00:17 +00:00
|
|
|
phy_mode_change = (efx->phy_mode == PHY_MODE_NORMAL &&
|
|
|
|
phy_data->phy_mode != PHY_MODE_NORMAL);
|
2009-11-29 15:08:55 +00:00
|
|
|
loop_reset = (LOOPBACK_OUT_OF(phy_data, efx, LOOPBACKS_EXTERNAL(efx)) ||
|
2008-12-13 06:00:17 +00:00
|
|
|
LOOPBACK_CHANGED(phy_data, efx, 1 << LOOPBACK_GPHY));
|
|
|
|
|
2009-01-29 17:49:09 +00:00
|
|
|
if (loop_reset || phy_mode_change) {
|
2009-11-29 03:42:41 +00:00
|
|
|
tenxpress_special_reset(efx);
|
2010-09-22 10:00:11 +00:00
|
|
|
falcon_reset_xaui(efx);
|
2008-05-07 12:36:19 +00:00
|
|
|
}
|
|
|
|
|
2009-11-29 03:42:41 +00:00
|
|
|
tenxpress_low_power(efx);
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_transmit_disable(efx);
|
|
|
|
ef4_mdio_phy_reconfigure(efx);
|
2008-12-13 06:00:17 +00:00
|
|
|
tenxpress_ext_loopback(efx);
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_an_reconfigure(efx);
|
2008-05-07 12:36:19 +00:00
|
|
|
|
|
|
|
phy_data->loopback_mode = efx->loopback_mode;
|
2008-09-01 11:48:17 +00:00
|
|
|
phy_data->phy_mode = efx->phy_mode;
|
2009-11-29 03:42:41 +00:00
|
|
|
|
|
|
|
return 0;
|
2008-04-27 11:55:59 +00:00
|
|
|
}
|
|
|
|
|
2009-11-28 05:34:05 +00:00
|
|
|
/* Poll for link state changes */
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static bool tenxpress_phy_poll(struct ef4_nic *efx)
|
2008-04-27 11:55:59 +00:00
|
|
|
{
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
struct ef4_link_state old_state = efx->link_state;
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2010-09-22 10:00:11 +00:00
|
|
|
efx->link_state.up = sfx7101_link_ok(efx);
|
|
|
|
efx->link_state.speed = 10000;
|
|
|
|
efx->link_state.fd = true;
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
efx->link_state.fc = ef4_mdio_get_pause(efx);
|
2008-04-27 11:55:59 +00:00
|
|
|
|
2010-09-22 10:00:11 +00:00
|
|
|
sfx7101_check_bad_lp(efx, efx->link_state.up);
|
2009-11-28 05:34:05 +00:00
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
return !ef4_link_state_equal(&efx->link_state, &old_state);
|
2008-04-27 11:55:59 +00:00
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static void sfx7101_phy_fini(struct ef4_nic *efx)
|
2008-04-27 11:55:59 +00:00
|
|
|
{
|
|
|
|
int reg;
|
|
|
|
|
2009-12-23 13:46:36 +00:00
|
|
|
/* Power down the LNPGA */
|
|
|
|
reg = (1 << PMA_PMD_LNPGA_POWERDOWN_LBN);
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_write(efx, MDIO_MMD_PMAPMD, PMA_PMD_XCONTROL_REG, reg);
|
2009-12-23 13:46:36 +00:00
|
|
|
|
|
|
|
/* Waiting here ensures that the board fini, which can turn
|
|
|
|
* off the power to the PHY, won't get run until the LNPGA
|
|
|
|
* powerdown has been given long enough to complete. */
|
|
|
|
schedule_timeout_uninterruptible(LNPGA_PDOWN_WAIT); /* 200 ms */
|
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static void tenxpress_phy_remove(struct ef4_nic *efx)
|
2009-12-23 13:46:36 +00:00
|
|
|
{
|
2008-04-27 11:55:59 +00:00
|
|
|
kfree(efx->phy_data);
|
|
|
|
efx->phy_data = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-11-23 16:03:45 +00:00
|
|
|
/* Override the RX, TX and link LEDs */
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
void tenxpress_set_id_led(struct ef4_nic *efx, enum ef4_led_mode mode)
|
2008-04-27 11:55:59 +00:00
|
|
|
{
|
|
|
|
int reg;
|
|
|
|
|
2009-11-23 16:03:45 +00:00
|
|
|
switch (mode) {
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
case EF4_LED_OFF:
|
2009-11-23 16:03:45 +00:00
|
|
|
reg = (PMA_PMD_LED_OFF << PMA_PMD_LED_TX_LBN) |
|
|
|
|
(PMA_PMD_LED_OFF << PMA_PMD_LED_RX_LBN) |
|
|
|
|
(PMA_PMD_LED_OFF << PMA_PMD_LED_LINK_LBN);
|
|
|
|
break;
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
case EF4_LED_ON:
|
2009-11-23 16:03:45 +00:00
|
|
|
reg = (PMA_PMD_LED_ON << PMA_PMD_LED_TX_LBN) |
|
|
|
|
(PMA_PMD_LED_ON << PMA_PMD_LED_RX_LBN) |
|
|
|
|
(PMA_PMD_LED_ON << PMA_PMD_LED_LINK_LBN);
|
|
|
|
break;
|
|
|
|
default:
|
2010-09-22 10:00:11 +00:00
|
|
|
reg = SFX7101_PMA_PMD_LED_DEFAULT;
|
2009-11-23 16:03:45 +00:00
|
|
|
break;
|
|
|
|
}
|
2008-04-27 11:55:59 +00:00
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_write(efx, MDIO_MMD_PMAPMD, PMA_PMD_LED_OVERR_REG, reg);
|
2008-04-27 11:55:59 +00:00
|
|
|
}
|
|
|
|
|
2008-12-26 21:48:00 +00:00
|
|
|
static const char *const sfx7101_test_names[] = {
|
2008-12-26 21:47:25 +00:00
|
|
|
"bist"
|
|
|
|
};
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static const char *sfx7101_test_name(struct ef4_nic *efx, unsigned int index)
|
2009-11-29 15:08:55 +00:00
|
|
|
{
|
|
|
|
if (index < ARRAY_SIZE(sfx7101_test_names))
|
|
|
|
return sfx7101_test_names[index];
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2008-12-26 21:47:25 +00:00
|
|
|
static int
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
sfx7101_run_tests(struct ef4_nic *efx, int *results, unsigned flags)
|
2008-09-01 11:49:02 +00:00
|
|
|
{
|
2008-12-26 21:47:25 +00:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (!(flags & ETH_TEST_FL_OFFLINE))
|
|
|
|
return 0;
|
|
|
|
|
2008-09-01 11:49:02 +00:00
|
|
|
/* BIST is automatically run after a special software reset */
|
2008-12-26 21:47:25 +00:00
|
|
|
rc = tenxpress_special_reset(efx);
|
|
|
|
results[0] = rc ? -1 : 1;
|
2009-11-29 03:42:41 +00:00
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_an_reconfigure(efx);
|
2009-11-29 03:42:41 +00:00
|
|
|
|
2008-12-26 21:47:25 +00:00
|
|
|
return rc;
|
2008-09-01 11:49:02 +00:00
|
|
|
}
|
|
|
|
|
2009-01-29 17:59:37 +00:00
|
|
|
static void
|
2017-01-01 18:02:46 +00:00
|
|
|
tenxpress_get_link_ksettings(struct ef4_nic *efx,
|
|
|
|
struct ethtool_link_ksettings *cmd)
|
2008-12-13 05:50:46 +00:00
|
|
|
{
|
2009-01-29 17:59:37 +00:00
|
|
|
u32 adv = 0, lpa = 0;
|
2008-12-13 05:50:46 +00:00
|
|
|
int reg;
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
reg = ef4_mdio_read(efx, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL);
|
2009-04-29 08:05:08 +00:00
|
|
|
if (reg & MDIO_AN_10GBT_CTRL_ADV10G)
|
2009-01-29 17:59:37 +00:00
|
|
|
adv |= ADVERTISED_10000baseT_Full;
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
reg = ef4_mdio_read(efx, MDIO_MMD_AN, MDIO_AN_10GBT_STAT);
|
2009-04-29 08:05:08 +00:00
|
|
|
if (reg & MDIO_AN_10GBT_STAT_LP10G)
|
2008-12-13 05:50:46 +00:00
|
|
|
lpa |= ADVERTISED_10000baseT_Full;
|
|
|
|
|
2017-01-01 18:02:46 +00:00
|
|
|
mdio45_ethtool_ksettings_get_npage(&efx->mdio, cmd, adv, lpa);
|
2008-12-13 06:00:17 +00:00
|
|
|
|
2009-01-29 17:49:09 +00:00
|
|
|
/* In loopback, the PHY automatically brings up the correct interface,
|
|
|
|
* but doesn't advertise the correct speed. So override it */
|
2010-09-22 10:00:11 +00:00
|
|
|
if (LOOPBACK_EXTERNAL(efx))
|
2017-01-01 18:02:46 +00:00
|
|
|
cmd->base.speed = SPEED_10000;
|
2008-12-13 05:50:46 +00:00
|
|
|
}
|
|
|
|
|
2017-01-01 18:02:46 +00:00
|
|
|
static int
|
|
|
|
tenxpress_set_link_ksettings(struct ef4_nic *efx,
|
|
|
|
const struct ethtool_link_ksettings *cmd)
|
2008-12-13 06:00:17 +00:00
|
|
|
{
|
2017-01-01 18:02:46 +00:00
|
|
|
if (!cmd->base.autoneg)
|
2009-01-29 17:59:37 +00:00
|
|
|
return -EINVAL;
|
2008-12-13 06:00:17 +00:00
|
|
|
|
2017-01-01 18:02:46 +00:00
|
|
|
return ef4_mdio_set_link_ksettings(efx, cmd);
|
2008-12-13 06:00:17 +00:00
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
static void sfx7101_set_npage_adv(struct ef4_nic *efx, u32 advertising)
|
2008-12-13 06:00:17 +00:00
|
|
|
{
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
ef4_mdio_set_flag(efx, MDIO_MMD_AN, MDIO_AN_10GBT_CTRL,
|
2009-04-29 08:05:08 +00:00
|
|
|
MDIO_AN_10GBT_CTRL_ADV10G,
|
|
|
|
advertising & ADVERTISED_10000baseT_Full);
|
2008-12-13 06:00:17 +00:00
|
|
|
}
|
|
|
|
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
const struct ef4_phy_operations falcon_sfx7101_phy_ops = {
|
2009-12-23 13:46:36 +00:00
|
|
|
.probe = tenxpress_phy_probe,
|
2008-04-27 11:55:59 +00:00
|
|
|
.init = tenxpress_phy_init,
|
|
|
|
.reconfigure = tenxpress_phy_reconfigure,
|
2008-12-13 05:59:24 +00:00
|
|
|
.poll = tenxpress_phy_poll,
|
2009-12-23 13:46:36 +00:00
|
|
|
.fini = sfx7101_phy_fini,
|
|
|
|
.remove = tenxpress_phy_remove,
|
2017-01-01 18:02:46 +00:00
|
|
|
.get_link_ksettings = tenxpress_get_link_ksettings,
|
|
|
|
.set_link_ksettings = tenxpress_set_link_ksettings,
|
2009-01-29 17:59:37 +00:00
|
|
|
.set_npage_adv = sfx7101_set_npage_adv,
|
sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver
Rationale: The differences between Falcon and Siena are in many ways larger
than those between Siena and EF10 (despite Siena being nominally "Falcon-
architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
Removing Falcon support from the sfc driver should simplify the latter,
and avoid the possibility of Falcon support being broken by changes to sfc
(which are rarely if ever tested on Falcon, it being end-of-lifed hardware).
The sfc-falcon driver created in this changeset is essentially a copy of the
sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
series") to avoid collisions when both drivers are built-in.
This changeset removes Falcon from the sfc driver's PCI ID table; then in
sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
that referenced them.
Also, increment minor version of both drivers (to 4.1).
For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
doesn't cause Falcon support to disappear; but that should be undone at
some point in the future.
Signed-off-by: Edward Cree <ecree@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-11-28 18:55:34 +00:00
|
|
|
.test_alive = ef4_mdio_test_alive,
|
2009-11-29 15:08:55 +00:00
|
|
|
.test_name = sfx7101_test_name,
|
2008-12-26 21:48:00 +00:00
|
|
|
.run_tests = sfx7101_run_tests,
|
2008-12-13 06:00:17 +00:00
|
|
|
};
|