2008-04-27 18:55:59 +07:00
|
|
|
/****************************************************************************
|
2013-08-30 05:32:48 +07:00
|
|
|
* Driver for Solarflare network controllers and boards
|
|
|
|
* Copyright 2007-2013 Solarflare Communications Inc.
|
2008-04-27 18:55:59 +07: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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef EFX_ENUM_H
|
|
|
|
#define EFX_ENUM_H
|
|
|
|
|
2008-05-07 19:36:19 +07:00
|
|
|
/**
|
|
|
|
* enum efx_loopback_mode - loopback modes
|
|
|
|
* @LOOPBACK_NONE: no loopback
|
2009-11-29 22:08:41 +07:00
|
|
|
* @LOOPBACK_DATA: data path loopback
|
|
|
|
* @LOOPBACK_GMAC: loopback within GMAC
|
|
|
|
* @LOOPBACK_XGMII: loopback after XMAC
|
|
|
|
* @LOOPBACK_XGXS: loopback within BPX after XGXS
|
|
|
|
* @LOOPBACK_XAUI: loopback within BPX before XAUI serdes
|
|
|
|
* @LOOPBACK_GMII: loopback within BPX after GMAC
|
|
|
|
* @LOOPBACK_SGMII: loopback within BPX within SGMII
|
|
|
|
* @LOOPBACK_XGBR: loopback within BPX within XGBR
|
|
|
|
* @LOOPBACK_XFI: loopback within BPX before XFI serdes
|
|
|
|
* @LOOPBACK_XAUI_FAR: loopback within BPX after XAUI serdes
|
|
|
|
* @LOOPBACK_GMII_FAR: loopback within BPX before SGMII
|
|
|
|
* @LOOPBACK_SGMII_FAR: loopback within BPX after SGMII
|
|
|
|
* @LOOPBACK_XFI_FAR: loopback after XFI serdes
|
2008-12-13 12:50:08 +07:00
|
|
|
* @LOOPBACK_GPHY: loopback within 1G PHY at unspecified level
|
|
|
|
* @LOOPBACK_PHYXS: loopback within 10G PHY at PHYXS level
|
|
|
|
* @LOOPBACK_PCS: loopback within 10G PHY at PCS level
|
|
|
|
* @LOOPBACK_PMAPMD: loopback within 10G PHY at PMAPMD level
|
2009-11-29 22:08:41 +07:00
|
|
|
* @LOOPBACK_XPORT: cross port loopback
|
|
|
|
* @LOOPBACK_XGMII_WS: wireside loopback excluding XMAC
|
|
|
|
* @LOOPBACK_XAUI_WS: wireside loopback within BPX within XAUI serdes
|
|
|
|
* @LOOPBACK_XAUI_WS_FAR: wireside loopback within BPX including XAUI serdes
|
|
|
|
* @LOOPBACK_XAUI_WS_NEAR: wireside loopback within BPX excluding XAUI serdes
|
|
|
|
* @LOOPBACK_GMII_WS: wireside loopback excluding GMAC
|
|
|
|
* @LOOPBACK_XFI_WS: wireside loopback excluding XFI serdes
|
|
|
|
* @LOOPBACK_XFI_WS_FAR: wireside loopback including XFI serdes
|
|
|
|
* @LOOPBACK_PHYXS_WS: wireside loopback within 10G PHY at PHYXS level
|
2008-05-07 19:36:19 +07:00
|
|
|
*/
|
2009-11-29 22:08:41 +07:00
|
|
|
/* Please keep up-to-date w.r.t the following two #defines */
|
2008-05-07 19:36:19 +07:00
|
|
|
enum efx_loopback_mode {
|
|
|
|
LOOPBACK_NONE = 0,
|
2009-11-29 22:08:41 +07:00
|
|
|
LOOPBACK_DATA = 1,
|
|
|
|
LOOPBACK_GMAC = 2,
|
|
|
|
LOOPBACK_XGMII = 3,
|
|
|
|
LOOPBACK_XGXS = 4,
|
|
|
|
LOOPBACK_XAUI = 5,
|
|
|
|
LOOPBACK_GMII = 6,
|
|
|
|
LOOPBACK_SGMII = 7,
|
|
|
|
LOOPBACK_XGBR = 8,
|
|
|
|
LOOPBACK_XFI = 9,
|
|
|
|
LOOPBACK_XAUI_FAR = 10,
|
|
|
|
LOOPBACK_GMII_FAR = 11,
|
|
|
|
LOOPBACK_SGMII_FAR = 12,
|
|
|
|
LOOPBACK_XFI_FAR = 13,
|
|
|
|
LOOPBACK_GPHY = 14,
|
|
|
|
LOOPBACK_PHYXS = 15,
|
|
|
|
LOOPBACK_PCS = 16,
|
|
|
|
LOOPBACK_PMAPMD = 17,
|
|
|
|
LOOPBACK_XPORT = 18,
|
|
|
|
LOOPBACK_XGMII_WS = 19,
|
|
|
|
LOOPBACK_XAUI_WS = 20,
|
|
|
|
LOOPBACK_XAUI_WS_FAR = 21,
|
|
|
|
LOOPBACK_XAUI_WS_NEAR = 22,
|
|
|
|
LOOPBACK_GMII_WS = 23,
|
|
|
|
LOOPBACK_XFI_WS = 24,
|
|
|
|
LOOPBACK_XFI_WS_FAR = 25,
|
|
|
|
LOOPBACK_PHYXS_WS = 26,
|
2008-05-07 19:36:19 +07:00
|
|
|
LOOPBACK_MAX
|
|
|
|
};
|
|
|
|
#define LOOPBACK_TEST_MAX LOOPBACK_PMAPMD
|
|
|
|
|
|
|
|
/* These loopbacks occur within the controller */
|
2009-11-29 22:08:41 +07:00
|
|
|
#define LOOPBACKS_INTERNAL ((1 << LOOPBACK_DATA) | \
|
|
|
|
(1 << LOOPBACK_GMAC) | \
|
|
|
|
(1 << LOOPBACK_XGMII)| \
|
|
|
|
(1 << LOOPBACK_XGXS) | \
|
|
|
|
(1 << LOOPBACK_XAUI) | \
|
|
|
|
(1 << LOOPBACK_GMII) | \
|
|
|
|
(1 << LOOPBACK_SGMII) | \
|
|
|
|
(1 << LOOPBACK_SGMII) | \
|
|
|
|
(1 << LOOPBACK_XGBR) | \
|
|
|
|
(1 << LOOPBACK_XFI) | \
|
|
|
|
(1 << LOOPBACK_XAUI_FAR) | \
|
|
|
|
(1 << LOOPBACK_GMII_FAR) | \
|
|
|
|
(1 << LOOPBACK_SGMII_FAR) | \
|
|
|
|
(1 << LOOPBACK_XFI_FAR) | \
|
|
|
|
(1 << LOOPBACK_XGMII_WS) | \
|
|
|
|
(1 << LOOPBACK_XAUI_WS) | \
|
|
|
|
(1 << LOOPBACK_XAUI_WS_FAR) | \
|
|
|
|
(1 << LOOPBACK_XAUI_WS_NEAR) | \
|
|
|
|
(1 << LOOPBACK_GMII_WS) | \
|
|
|
|
(1 << LOOPBACK_XFI_WS) | \
|
|
|
|
(1 << LOOPBACK_XFI_WS_FAR))
|
|
|
|
|
|
|
|
#define LOOPBACKS_WS ((1 << LOOPBACK_XGMII_WS) | \
|
|
|
|
(1 << LOOPBACK_XAUI_WS) | \
|
|
|
|
(1 << LOOPBACK_XAUI_WS_FAR) | \
|
|
|
|
(1 << LOOPBACK_XAUI_WS_NEAR) | \
|
|
|
|
(1 << LOOPBACK_GMII_WS) | \
|
|
|
|
(1 << LOOPBACK_XFI_WS) | \
|
|
|
|
(1 << LOOPBACK_XFI_WS_FAR) | \
|
|
|
|
(1 << LOOPBACK_PHYXS_WS))
|
|
|
|
|
|
|
|
#define LOOPBACKS_EXTERNAL(_efx) \
|
|
|
|
((_efx)->loopback_modes & ~LOOPBACKS_INTERNAL & \
|
|
|
|
~(1 << LOOPBACK_NONE))
|
2008-05-07 19:36:19 +07:00
|
|
|
|
|
|
|
#define LOOPBACK_MASK(_efx) \
|
|
|
|
(1 << (_efx)->loopback_mode)
|
|
|
|
|
2008-09-01 18:46:50 +07:00
|
|
|
#define LOOPBACK_INTERNAL(_efx) \
|
2008-12-13 12:50:08 +07:00
|
|
|
(!!(LOOPBACKS_INTERNAL & LOOPBACK_MASK(_efx)))
|
2008-05-07 19:36:19 +07:00
|
|
|
|
2009-11-29 22:08:41 +07:00
|
|
|
#define LOOPBACK_EXTERNAL(_efx) \
|
|
|
|
(!!(LOOPBACK_MASK(_efx) & LOOPBACKS_EXTERNAL(_efx)))
|
|
|
|
|
2008-12-13 13:00:17 +07:00
|
|
|
#define LOOPBACK_CHANGED(_from, _to, _mask) \
|
|
|
|
(!!((LOOPBACK_MASK(_from) ^ LOOPBACK_MASK(_to)) & (_mask)))
|
|
|
|
|
2008-09-01 18:46:50 +07:00
|
|
|
#define LOOPBACK_OUT_OF(_from, _to, _mask) \
|
|
|
|
((LOOPBACK_MASK(_from) & (_mask)) && !(LOOPBACK_MASK(_to) & (_mask)))
|
2008-05-07 19:36:19 +07:00
|
|
|
|
2008-04-27 18:55:59 +07:00
|
|
|
/*****************************************************************************/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* enum reset_type - reset types
|
|
|
|
*
|
|
|
|
* %RESET_TYPE_INVSIBLE, %RESET_TYPE_ALL, %RESET_TYPE_WORLD and
|
|
|
|
* %RESET_TYPE_DISABLE specify the method/scope of the reset. The
|
|
|
|
* other valuesspecify reasons, which efx_schedule_reset() will choose
|
|
|
|
* a method for.
|
|
|
|
*
|
2011-06-25 02:46:31 +07:00
|
|
|
* Reset methods are numbered in order of increasing scope.
|
|
|
|
*
|
2012-07-05 23:31:04 +07:00
|
|
|
* @RESET_TYPE_INVISIBLE: Reset datapath and MAC (Falcon only)
|
2013-01-15 00:20:22 +07:00
|
|
|
* @RESET_TYPE_RECOVER_OR_ALL: Try to recover. Apply RESET_TYPE_ALL
|
|
|
|
* if unsuccessful.
|
2012-07-05 23:31:04 +07:00
|
|
|
* @RESET_TYPE_ALL: Reset datapath, MAC and PHY
|
|
|
|
* @RESET_TYPE_WORLD: Reset as much as possible
|
2013-01-15 00:20:22 +07:00
|
|
|
* @RESET_TYPE_RECOVER_OR_DISABLE: Try to recover. Apply RESET_TYPE_DISABLE if
|
|
|
|
* unsuccessful.
|
2015-05-20 17:11:35 +07:00
|
|
|
* @RESET_TYPE_DATAPATH: Reset datapath only.
|
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)
When an MCDI command times out (whether or not we find it
completed when we poll), call efx_mcdi_abandon(), which tells
all subsequent MCDI calls to fail-fast, and queues up an FLR.
Because an FLR doesn't lead to receiving any reboot even from
the MC (unlike most other types of reset), we have to call
efx_ef10_reset_mc_allocations.
In efx_start_all(), if a reset (of any kind) is pending, we
bail out.
Without this, attempts to reconfigure (e.g. change mtu) can
cause driver/mc state inconsistency if the first MCDI call
triggers an FLR.
For similar reasons, on EF10, in
efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
of active queues to zero before calling efx_stop_all().
And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
set active_queues and flushes pending & outstanding to zero.
efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
mode. Instead, this is done by efx_mcdi_reset() after the FLR
completes.
The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
fit into the hierarchy of reset 'scopes' whereby efx_reset()
decides some resets subsume others. Thus, it uses separate logic.
Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
which was in the wrong place in that hierarchy.
Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-17 01:27:48 +07:00
|
|
|
* @RESET_TYPE_MC_BIST: MC entering BIST mode.
|
2012-07-05 23:31:04 +07:00
|
|
|
* @RESET_TYPE_DISABLE: Reset datapath, MAC and PHY; leave NIC disabled
|
2008-11-05 03:35:36 +07:00
|
|
|
* @RESET_TYPE_TX_WATCHDOG: reset due to TX watchdog
|
2008-04-27 18:55:59 +07:00
|
|
|
* @RESET_TYPE_INT_ERROR: reset due to internal error
|
|
|
|
* @RESET_TYPE_RX_RECOVERY: reset to recover from RX datapath errors
|
2013-06-13 17:36:15 +07:00
|
|
|
* @RESET_TYPE_DMA_ERROR: DMA error
|
2008-04-27 18:55:59 +07:00
|
|
|
* @RESET_TYPE_TX_SKIP: hardware completed empty tx descriptors
|
2009-11-29 22:15:41 +07:00
|
|
|
* @RESET_TYPE_MC_FAILURE: MC reboot/assertion
|
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)
When an MCDI command times out (whether or not we find it
completed when we poll), call efx_mcdi_abandon(), which tells
all subsequent MCDI calls to fail-fast, and queues up an FLR.
Because an FLR doesn't lead to receiving any reboot even from
the MC (unlike most other types of reset), we have to call
efx_ef10_reset_mc_allocations.
In efx_start_all(), if a reset (of any kind) is pending, we
bail out.
Without this, attempts to reconfigure (e.g. change mtu) can
cause driver/mc state inconsistency if the first MCDI call
triggers an FLR.
For similar reasons, on EF10, in
efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
of active queues to zero before calling efx_stop_all().
And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
set active_queues and flushes pending & outstanding to zero.
efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
mode. Instead, this is done by efx_mcdi_reset() after the FLR
completes.
The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
fit into the hierarchy of reset 'scopes' whereby efx_reset()
decides some resets subsume others. Thus, it uses separate logic.
Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
which was in the wrong place in that hierarchy.
Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-17 01:27:48 +07:00
|
|
|
* @RESET_TYPE_MCDI_TIMEOUT: MCDI timeout.
|
2008-04-27 18:55:59 +07:00
|
|
|
*/
|
|
|
|
enum reset_type {
|
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)
When an MCDI command times out (whether or not we find it
completed when we poll), call efx_mcdi_abandon(), which tells
all subsequent MCDI calls to fail-fast, and queues up an FLR.
Because an FLR doesn't lead to receiving any reboot even from
the MC (unlike most other types of reset), we have to call
efx_ef10_reset_mc_allocations.
In efx_start_all(), if a reset (of any kind) is pending, we
bail out.
Without this, attempts to reconfigure (e.g. change mtu) can
cause driver/mc state inconsistency if the first MCDI call
triggers an FLR.
For similar reasons, on EF10, in
efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
of active queues to zero before calling efx_stop_all().
And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
set active_queues and flushes pending & outstanding to zero.
efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
mode. Instead, this is done by efx_mcdi_reset() after the FLR
completes.
The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
fit into the hierarchy of reset 'scopes' whereby efx_reset()
decides some resets subsume others. Thus, it uses separate logic.
Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
which was in the wrong place in that hierarchy.
Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-17 01:27:48 +07:00
|
|
|
RESET_TYPE_INVISIBLE,
|
|
|
|
RESET_TYPE_RECOVER_OR_ALL,
|
|
|
|
RESET_TYPE_ALL,
|
|
|
|
RESET_TYPE_WORLD,
|
|
|
|
RESET_TYPE_RECOVER_OR_DISABLE,
|
2015-05-20 17:11:35 +07:00
|
|
|
RESET_TYPE_DATAPATH,
|
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)
When an MCDI command times out (whether or not we find it
completed when we poll), call efx_mcdi_abandon(), which tells
all subsequent MCDI calls to fail-fast, and queues up an FLR.
Because an FLR doesn't lead to receiving any reboot even from
the MC (unlike most other types of reset), we have to call
efx_ef10_reset_mc_allocations.
In efx_start_all(), if a reset (of any kind) is pending, we
bail out.
Without this, attempts to reconfigure (e.g. change mtu) can
cause driver/mc state inconsistency if the first MCDI call
triggers an FLR.
For similar reasons, on EF10, in
efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
of active queues to zero before calling efx_stop_all().
And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
set active_queues and flushes pending & outstanding to zero.
efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
mode. Instead, this is done by efx_mcdi_reset() after the FLR
completes.
The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
fit into the hierarchy of reset 'scopes' whereby efx_reset()
decides some resets subsume others. Thus, it uses separate logic.
Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
which was in the wrong place in that hierarchy.
Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-17 01:27:48 +07:00
|
|
|
RESET_TYPE_MC_BIST,
|
|
|
|
RESET_TYPE_DISABLE,
|
2008-04-27 18:55:59 +07:00
|
|
|
RESET_TYPE_MAX_METHOD,
|
2008-11-05 03:35:36 +07:00
|
|
|
RESET_TYPE_TX_WATCHDOG,
|
2008-04-27 18:55:59 +07:00
|
|
|
RESET_TYPE_INT_ERROR,
|
|
|
|
RESET_TYPE_RX_RECOVERY,
|
2013-06-13 17:36:15 +07:00
|
|
|
RESET_TYPE_DMA_ERROR,
|
2008-04-27 18:55:59 +07:00
|
|
|
RESET_TYPE_TX_SKIP,
|
2009-11-29 22:15:41 +07:00
|
|
|
RESET_TYPE_MC_FAILURE,
|
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)
When an MCDI command times out (whether or not we find it
completed when we poll), call efx_mcdi_abandon(), which tells
all subsequent MCDI calls to fail-fast, and queues up an FLR.
Because an FLR doesn't lead to receiving any reboot even from
the MC (unlike most other types of reset), we have to call
efx_ef10_reset_mc_allocations.
In efx_start_all(), if a reset (of any kind) is pending, we
bail out.
Without this, attempts to reconfigure (e.g. change mtu) can
cause driver/mc state inconsistency if the first MCDI call
triggers an FLR.
For similar reasons, on EF10, in
efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
of active queues to zero before calling efx_stop_all().
And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
set active_queues and flushes pending & outstanding to zero.
efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
mode. Instead, this is done by efx_mcdi_reset() after the FLR
completes.
The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
fit into the hierarchy of reset 'scopes' whereby efx_reset()
decides some resets subsume others. Thus, it uses separate logic.
Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
which was in the wrong place in that hierarchy.
Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-17 01:27:48 +07:00
|
|
|
/* RESET_TYPE_MCDI_TIMEOUT is actually a method, not just a reason, but
|
|
|
|
* it doesn't fit the scope hierarchy (not well-ordered by inclusion).
|
|
|
|
* We encode this by having its enum value be greater than
|
|
|
|
* RESET_TYPE_MAX_METHOD. This also prevents issuing it with
|
|
|
|
* efx_ioctl_reset.
|
|
|
|
*/
|
|
|
|
RESET_TYPE_MCDI_TIMEOUT,
|
2008-04-27 18:55:59 +07:00
|
|
|
RESET_TYPE_MAX,
|
|
|
|
};
|
|
|
|
|
|
|
|
#endif /* EFX_ENUM_H */
|