2018-03-20 21:58:06 +07:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
|
/* Copyright (c) 2018, Intel Corporation. */
|
|
|
|
|
|
|
|
|
|
#ifndef _ICE_STATUS_H_
|
|
|
|
|
#define _ICE_STATUS_H_
|
|
|
|
|
|
|
|
|
|
/* Error Codes */
|
|
|
|
|
enum ice_status {
|
|
|
|
|
ICE_ERR_PARAM = -1,
|
ice: Add support for switch filter programming
A VSI needs traffic directed towards it. This is done by programming
filter rules on the switch (embedded vSwitch) element in the hardware,
which connects the VSI to the ingress/egress port.
This patch introduces data structures and functions necessary to add
remove or update switch rules on the switch element. This is a pretty low
level function that is generic enough to add a whole range of filters.
This patch also introduces two top level functions ice_add_mac and
ice_remove mac which through a series of intermediate helper functions
eventually call ice_aq_sw_rules to add/delete simple MAC based filters.
It's worth noting that one invocation of ice_add_mac/ice_remove_mac
is capable of adding/deleting multiple MAC filters.
Also worth noting is the fact that the driver maintains a list of currently
active filters, so every filter addition/removal causes an update to this
list. This is done for a couple of reasons:
1) If two VSIs try to add the same filters, we need to detect it and do
things a little differently (i.e. use VSI lists, described below) as
the same filter can't be added more than once.
2) In the event of a hardware reset we can simply walk through this list
and restore the filters.
VSI Lists:
In a multi-VSI situation, it's possible that multiple VSIs want to add the
same filter rule. For example, two VSIs that want to receive broadcast
traffic would both add a filter for destination MAC ff:ff:ff:ff:ff:ff.
This can become cumbersome to maintain and so this is handled using a
VSI list.
A VSI list is resource that can be allocated in the hardware using the
ice_aq_alloc_free_res admin queue command. Simply put, a VSI list can
be thought of as a subscription list containing a set of VSIs to which
the packet should be forwarded, should the filter match.
For example, if VSI-0 has already added a broadcast filter, and VSI-1
wants to do the same thing, the filter creation flow will detect this,
allocate a VSI list and update the switch rule so that broadcast traffic
will now be forwarded to the VSI list which contains VSI-0 and VSI-1.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 21:58:12 +07:00
|
|
|
ICE_ERR_NOT_IMPL = -2,
|
2018-03-20 21:58:06 +07:00
|
|
|
ICE_ERR_NOT_READY = -3,
|
2018-03-20 21:58:13 +07:00
|
|
|
ICE_ERR_BAD_PTR = -5,
|
2018-03-20 21:58:06 +07:00
|
|
|
ICE_ERR_INVAL_SIZE = -6,
|
2018-03-20 21:58:07 +07:00
|
|
|
ICE_ERR_DEVICE_NOT_SUPPORTED = -8,
|
|
|
|
|
ICE_ERR_RESET_FAILED = -9,
|
2018-03-20 21:58:06 +07:00
|
|
|
ICE_ERR_FW_API_VER = -10,
|
|
|
|
|
ICE_ERR_NO_MEMORY = -11,
|
|
|
|
|
ICE_ERR_CFG = -12,
|
2018-03-20 21:58:07 +07:00
|
|
|
ICE_ERR_OUT_OF_RANGE = -13,
|
ice: Add support for switch filter programming
A VSI needs traffic directed towards it. This is done by programming
filter rules on the switch (embedded vSwitch) element in the hardware,
which connects the VSI to the ingress/egress port.
This patch introduces data structures and functions necessary to add
remove or update switch rules on the switch element. This is a pretty low
level function that is generic enough to add a whole range of filters.
This patch also introduces two top level functions ice_add_mac and
ice_remove mac which through a series of intermediate helper functions
eventually call ice_aq_sw_rules to add/delete simple MAC based filters.
It's worth noting that one invocation of ice_add_mac/ice_remove_mac
is capable of adding/deleting multiple MAC filters.
Also worth noting is the fact that the driver maintains a list of currently
active filters, so every filter addition/removal causes an update to this
list. This is done for a couple of reasons:
1) If two VSIs try to add the same filters, we need to detect it and do
things a little differently (i.e. use VSI lists, described below) as
the same filter can't be added more than once.
2) In the event of a hardware reset we can simply walk through this list
and restore the filters.
VSI Lists:
In a multi-VSI situation, it's possible that multiple VSIs want to add the
same filter rule. For example, two VSIs that want to receive broadcast
traffic would both add a filter for destination MAC ff:ff:ff:ff:ff:ff.
This can become cumbersome to maintain and so this is handled using a
VSI list.
A VSI list is resource that can be allocated in the hardware using the
ice_aq_alloc_free_res admin queue command. Simply put, a VSI list can
be thought of as a subscription list containing a set of VSIs to which
the packet should be forwarded, should the filter match.
For example, if VSI-0 has already added a broadcast filter, and VSI-1
wants to do the same thing, the filter creation flow will detect this,
allocate a VSI list and update the switch rule so that broadcast traffic
will now be forwarded to the VSI list which contains VSI-0 and VSI-1.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 21:58:12 +07:00
|
|
|
ICE_ERR_ALREADY_EXISTS = -14,
|
|
|
|
|
ICE_ERR_DOES_NOT_EXIST = -15,
|
2018-03-20 21:58:13 +07:00
|
|
|
ICE_ERR_MAX_LIMIT = -17,
|
2018-08-09 20:29:47 +07:00
|
|
|
ICE_ERR_RESET_ONGOING = -18,
|
2018-03-20 21:58:09 +07:00
|
|
|
ICE_ERR_BUF_TOO_SHORT = -52,
|
2018-03-20 21:58:07 +07:00
|
|
|
ICE_ERR_NVM_BLANK_MODE = -53,
|
2018-03-20 21:58:06 +07:00
|
|
|
ICE_ERR_AQ_ERROR = -100,
|
|
|
|
|
ICE_ERR_AQ_TIMEOUT = -101,
|
|
|
|
|
ICE_ERR_AQ_FULL = -102,
|
2018-03-20 21:58:07 +07:00
|
|
|
ICE_ERR_AQ_NO_WORK = -103,
|
2018-03-20 21:58:06 +07:00
|
|
|
ICE_ERR_AQ_EMPTY = -104,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif /* _ICE_STATUS_H_ */
|