2018-03-20 22:58:06 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
|
/* Copyright (c) 2018, Intel Corporation. */
|
|
|
|
|
|
|
|
|
|
#ifndef _ICE_ADMINQ_CMD_H_
|
|
|
|
|
#define _ICE_ADMINQ_CMD_H_
|
|
|
|
|
|
|
|
|
|
/* This header file defines the Admin Queue commands, error codes and
|
|
|
|
|
* descriptor format. It is shared between Firmware and Software.
|
|
|
|
|
*/
|
|
|
|
|
|
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 22:58:12 +08:00
|
|
|
#define ICE_MAX_VSI 768
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
#define ICE_AQC_TOPO_MAX_LEVEL_NUM 0x9
|
2018-03-20 22:58:11 +08:00
|
|
|
#define ICE_AQ_SET_MAC_FRAME_SIZE_MAX 9728
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
|
2018-03-20 22:58:06 +08:00
|
|
|
struct ice_aqc_generic {
|
|
|
|
|
__le32 param0;
|
|
|
|
|
__le32 param1;
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Get version (direct 0x0001) */
|
|
|
|
|
struct ice_aqc_get_ver {
|
|
|
|
|
__le32 rom_ver;
|
|
|
|
|
__le32 fw_build;
|
|
|
|
|
u8 fw_branch;
|
|
|
|
|
u8 fw_major;
|
|
|
|
|
u8 fw_minor;
|
|
|
|
|
u8 fw_patch;
|
|
|
|
|
u8 api_branch;
|
|
|
|
|
u8 api_major;
|
|
|
|
|
u8 api_minor;
|
|
|
|
|
u8 api_patch;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Queue Shutdown (direct 0x0003) */
|
|
|
|
|
struct ice_aqc_q_shutdown {
|
|
|
|
|
#define ICE_AQC_DRIVER_UNLOADING BIT(0)
|
|
|
|
|
__le32 driver_unloading;
|
|
|
|
|
u8 reserved[12];
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-20 22:58:07 +08:00
|
|
|
/* Request resource ownership (direct 0x0008)
|
|
|
|
|
* Release resource ownership (direct 0x0009)
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_req_res {
|
|
|
|
|
__le16 res_id;
|
|
|
|
|
#define ICE_AQC_RES_ID_NVM 1
|
|
|
|
|
#define ICE_AQC_RES_ID_SDP 2
|
|
|
|
|
#define ICE_AQC_RES_ID_CHNG_LOCK 3
|
|
|
|
|
#define ICE_AQC_RES_ID_GLBL_LOCK 4
|
|
|
|
|
__le16 access_type;
|
|
|
|
|
#define ICE_AQC_RES_ACCESS_READ 1
|
|
|
|
|
#define ICE_AQC_RES_ACCESS_WRITE 2
|
|
|
|
|
|
|
|
|
|
/* Upon successful completion, FW writes this value and driver is
|
|
|
|
|
* expected to release resource before timeout. This value is provided
|
|
|
|
|
* in milliseconds.
|
|
|
|
|
*/
|
|
|
|
|
__le32 timeout;
|
|
|
|
|
#define ICE_AQ_RES_NVM_READ_DFLT_TIMEOUT_MS 3000
|
|
|
|
|
#define ICE_AQ_RES_NVM_WRITE_DFLT_TIMEOUT_MS 180000
|
|
|
|
|
#define ICE_AQ_RES_CHNG_LOCK_DFLT_TIMEOUT_MS 1000
|
|
|
|
|
#define ICE_AQ_RES_GLBL_LOCK_DFLT_TIMEOUT_MS 3000
|
|
|
|
|
/* For SDP: pin id of the SDP */
|
|
|
|
|
__le32 res_number;
|
|
|
|
|
/* Status is only used for ICE_AQC_RES_ID_GLBL_LOCK */
|
|
|
|
|
__le16 status;
|
|
|
|
|
#define ICE_AQ_RES_GLBL_SUCCESS 0
|
|
|
|
|
#define ICE_AQ_RES_GLBL_IN_PROG 1
|
|
|
|
|
#define ICE_AQ_RES_GLBL_DONE 2
|
|
|
|
|
u8 reserved[2];
|
|
|
|
|
};
|
|
|
|
|
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
/* Get function capabilities (indirect 0x000A)
|
|
|
|
|
* Get device capabilities (indirect 0x000B)
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_list_caps {
|
|
|
|
|
u8 cmd_flags;
|
|
|
|
|
u8 pf_index;
|
|
|
|
|
u8 reserved[2];
|
|
|
|
|
__le32 count;
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Device/Function buffer entry, repeated per reported capability */
|
|
|
|
|
struct ice_aqc_list_caps_elem {
|
|
|
|
|
__le16 cap;
|
|
|
|
|
#define ICE_AQC_CAPS_VSI 0x0017
|
|
|
|
|
#define ICE_AQC_CAPS_RSS 0x0040
|
|
|
|
|
#define ICE_AQC_CAPS_RXQS 0x0041
|
|
|
|
|
#define ICE_AQC_CAPS_TXQS 0x0042
|
|
|
|
|
#define ICE_AQC_CAPS_MSIX 0x0043
|
|
|
|
|
#define ICE_AQC_CAPS_MAX_MTU 0x0047
|
|
|
|
|
|
|
|
|
|
u8 major_ver;
|
|
|
|
|
u8 minor_ver;
|
|
|
|
|
/* Number of resources described by this capability */
|
|
|
|
|
__le32 number;
|
|
|
|
|
/* Only meaningful for some types of resources */
|
|
|
|
|
__le32 logical_id;
|
|
|
|
|
/* Only meaningful for some types of resources */
|
|
|
|
|
__le32 phys_id;
|
|
|
|
|
__le64 rsvd1;
|
|
|
|
|
__le64 rsvd2;
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-20 22:58:09 +08:00
|
|
|
/* Manage MAC address, read command - indirect (0x0107)
|
|
|
|
|
* This struct is also used for the response
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_manage_mac_read {
|
|
|
|
|
__le16 flags; /* Zeroed by device driver */
|
|
|
|
|
#define ICE_AQC_MAN_MAC_LAN_ADDR_VALID BIT(4)
|
|
|
|
|
#define ICE_AQC_MAN_MAC_SAN_ADDR_VALID BIT(5)
|
|
|
|
|
#define ICE_AQC_MAN_MAC_PORT_ADDR_VALID BIT(6)
|
|
|
|
|
#define ICE_AQC_MAN_MAC_WOL_ADDR_VALID BIT(7)
|
|
|
|
|
#define ICE_AQC_MAN_MAC_READ_S 4
|
|
|
|
|
#define ICE_AQC_MAN_MAC_READ_M (0xF << ICE_AQC_MAN_MAC_READ_S)
|
|
|
|
|
u8 lport_num;
|
|
|
|
|
u8 lport_num_valid;
|
|
|
|
|
#define ICE_AQC_MAN_MAC_PORT_NUM_IS_VALID BIT(0)
|
|
|
|
|
u8 num_addr; /* Used in response */
|
|
|
|
|
u8 reserved[3];
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Response buffer format for manage MAC read command */
|
|
|
|
|
struct ice_aqc_manage_mac_read_resp {
|
|
|
|
|
u8 lport_num;
|
|
|
|
|
u8 addr_type;
|
|
|
|
|
#define ICE_AQC_MAN_MAC_ADDR_TYPE_LAN 0
|
|
|
|
|
#define ICE_AQC_MAN_MAC_ADDR_TYPE_WOL 1
|
|
|
|
|
u8 mac_addr[ETH_ALEN];
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-20 22:58:07 +08:00
|
|
|
/* Clear PXE Command and response (direct 0x0110) */
|
|
|
|
|
struct ice_aqc_clear_pxe {
|
|
|
|
|
u8 rx_cnt;
|
|
|
|
|
#define ICE_AQC_CLEAR_PXE_RX_CNT 0x2
|
|
|
|
|
u8 reserved[15];
|
|
|
|
|
};
|
|
|
|
|
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
/* Get switch configuration (0x0200) */
|
|
|
|
|
struct ice_aqc_get_sw_cfg {
|
|
|
|
|
/* Reserved for command and copy of request flags for response */
|
|
|
|
|
__le16 flags;
|
|
|
|
|
/* First desc in case of command and next_elem in case of response
|
|
|
|
|
* In case of response, if it is not zero, means all the configuration
|
|
|
|
|
* was not returned and new command shall be sent with this value in
|
|
|
|
|
* the 'first desc' field
|
|
|
|
|
*/
|
|
|
|
|
__le16 element;
|
|
|
|
|
/* Reserved for command, only used for response */
|
|
|
|
|
__le16 num_elems;
|
|
|
|
|
__le16 rsvd;
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Each entry in the response buffer is of the following type: */
|
|
|
|
|
struct ice_aqc_get_sw_cfg_resp_elem {
|
|
|
|
|
/* VSI/Port Number */
|
|
|
|
|
__le16 vsi_port_num;
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_VSI_PORT_NUM_S 0
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_VSI_PORT_NUM_M \
|
|
|
|
|
(0x3FF << ICE_AQC_GET_SW_CONF_RESP_VSI_PORT_NUM_S)
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_TYPE_S 14
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_TYPE_M (0x3 << ICE_AQC_GET_SW_CONF_RESP_TYPE_S)
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_PHYS_PORT 0
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_VIRT_PORT 1
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_VSI 2
|
|
|
|
|
|
|
|
|
|
/* SWID VSI/Port belongs to */
|
|
|
|
|
__le16 swid;
|
|
|
|
|
|
|
|
|
|
/* Bit 14..0 : PF/VF number VSI belongs to
|
|
|
|
|
* Bit 15 : VF indication bit
|
|
|
|
|
*/
|
|
|
|
|
__le16 pf_vf_num;
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_FUNC_NUM_S 0
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_FUNC_NUM_M \
|
|
|
|
|
(0x7FFF << ICE_AQC_GET_SW_CONF_RESP_FUNC_NUM_S)
|
|
|
|
|
#define ICE_AQC_GET_SW_CONF_RESP_IS_VF BIT(15)
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* The response buffer is as follows. Note that the length of the
|
|
|
|
|
* elements array varies with the length of the command response.
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_get_sw_cfg_resp {
|
|
|
|
|
struct ice_aqc_get_sw_cfg_resp_elem elements[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 22:58:12 +08:00
|
|
|
/* These resource type defines are used for all switch resource
|
|
|
|
|
* commands where a resource type is required, such as:
|
|
|
|
|
* Get Resource Allocation command (indirect 0x0204)
|
|
|
|
|
* Allocate Resources command (indirect 0x0208)
|
|
|
|
|
* Free Resources command (indirect 0x0209)
|
|
|
|
|
* Get Allocated Resource Descriptors Command (indirect 0x020A)
|
|
|
|
|
*/
|
|
|
|
|
#define ICE_AQC_RES_TYPE_VSI_LIST_REP 0x03
|
|
|
|
|
#define ICE_AQC_RES_TYPE_VSI_LIST_PRUNE 0x04
|
|
|
|
|
|
|
|
|
|
/* Allocate Resources command (indirect 0x0208)
|
|
|
|
|
* Free Resources command (indirect 0x0209)
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_alloc_free_res_cmd {
|
|
|
|
|
__le16 num_entries; /* Number of Resource entries */
|
|
|
|
|
u8 reserved[6];
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Resource descriptor */
|
|
|
|
|
struct ice_aqc_res_elem {
|
|
|
|
|
union {
|
|
|
|
|
__le16 sw_resp;
|
|
|
|
|
__le16 flu_resp;
|
|
|
|
|
} e;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Buffer for Allocate/Free Resources commands */
|
|
|
|
|
struct ice_aqc_alloc_free_res_elem {
|
|
|
|
|
__le16 res_type; /* Types defined above cmd 0x0204 */
|
|
|
|
|
#define ICE_AQC_RES_TYPE_SHARED_S 7
|
|
|
|
|
#define ICE_AQC_RES_TYPE_SHARED_M (0x1 << ICE_AQC_RES_TYPE_SHARED_S)
|
|
|
|
|
#define ICE_AQC_RES_TYPE_VSI_PRUNE_LIST_S 8
|
|
|
|
|
#define ICE_AQC_RES_TYPE_VSI_PRUNE_LIST_M \
|
|
|
|
|
(0xF << ICE_AQC_RES_TYPE_VSI_PRUNE_LIST_S)
|
|
|
|
|
__le16 num_elems;
|
|
|
|
|
struct ice_aqc_res_elem elem[1];
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-20 22:58:11 +08:00
|
|
|
/* Add VSI (indirect 0x0210)
|
|
|
|
|
* Update VSI (indirect 0x0211)
|
|
|
|
|
* Get VSI (indirect 0x0212)
|
|
|
|
|
* Free VSI (indirect 0x0213)
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_add_get_update_free_vsi {
|
|
|
|
|
__le16 vsi_num;
|
|
|
|
|
#define ICE_AQ_VSI_NUM_S 0
|
|
|
|
|
#define ICE_AQ_VSI_NUM_M (0x03FF << ICE_AQ_VSI_NUM_S)
|
|
|
|
|
#define ICE_AQ_VSI_IS_VALID BIT(15)
|
|
|
|
|
__le16 cmd_flags;
|
|
|
|
|
#define ICE_AQ_VSI_KEEP_ALLOC 0x1
|
|
|
|
|
u8 vf_id;
|
|
|
|
|
u8 reserved;
|
|
|
|
|
__le16 vsi_flags;
|
|
|
|
|
#define ICE_AQ_VSI_TYPE_S 0
|
|
|
|
|
#define ICE_AQ_VSI_TYPE_M (0x3 << ICE_AQ_VSI_TYPE_S)
|
|
|
|
|
#define ICE_AQ_VSI_TYPE_VF 0x0
|
|
|
|
|
#define ICE_AQ_VSI_TYPE_VMDQ2 0x1
|
|
|
|
|
#define ICE_AQ_VSI_TYPE_PF 0x2
|
|
|
|
|
#define ICE_AQ_VSI_TYPE_EMP_MNG 0x3
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Response descriptor for:
|
|
|
|
|
* Add VSI (indirect 0x0210)
|
|
|
|
|
* Update VSI (indirect 0x0211)
|
|
|
|
|
* Free VSI (indirect 0x0213)
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_add_update_free_vsi_resp {
|
|
|
|
|
__le16 vsi_num;
|
|
|
|
|
__le16 ext_status;
|
|
|
|
|
__le16 vsi_used;
|
|
|
|
|
__le16 vsi_free;
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ice_aqc_vsi_props {
|
|
|
|
|
__le16 valid_sections;
|
|
|
|
|
#define ICE_AQ_VSI_PROP_SW_VALID BIT(0)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_SECURITY_VALID BIT(1)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_VLAN_VALID BIT(2)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_OUTER_TAG_VALID BIT(3)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_INGRESS_UP_VALID BIT(4)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_EGRESS_UP_VALID BIT(5)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_RXQ_MAP_VALID BIT(6)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_Q_OPT_VALID BIT(7)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_OUTER_UP_VALID BIT(8)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_FLOW_DIR_VALID BIT(11)
|
|
|
|
|
#define ICE_AQ_VSI_PROP_PASID_VALID BIT(12)
|
|
|
|
|
/* switch section */
|
|
|
|
|
u8 sw_id;
|
|
|
|
|
u8 sw_flags;
|
|
|
|
|
#define ICE_AQ_VSI_SW_FLAG_ALLOW_LB BIT(5)
|
|
|
|
|
#define ICE_AQ_VSI_SW_FLAG_LOCAL_LB BIT(6)
|
|
|
|
|
#define ICE_AQ_VSI_SW_FLAG_SRC_PRUNE BIT(7)
|
|
|
|
|
u8 sw_flags2;
|
|
|
|
|
#define ICE_AQ_VSI_SW_FLAG_RX_PRUNE_EN_S 0
|
|
|
|
|
#define ICE_AQ_VSI_SW_FLAG_RX_PRUNE_EN_M \
|
|
|
|
|
(0xF << ICE_AQ_VSI_SW_FLAG_RX_PRUNE_EN_S)
|
|
|
|
|
#define ICE_AQ_VSI_SW_FLAG_RX_VLAN_PRUNE_ENA BIT(0)
|
|
|
|
|
#define ICE_AQ_VSI_SW_FLAG_LAN_ENA BIT(4)
|
|
|
|
|
u8 veb_stat_id;
|
|
|
|
|
#define ICE_AQ_VSI_SW_VEB_STAT_ID_S 0
|
|
|
|
|
#define ICE_AQ_VSI_SW_VEB_STAT_ID_M (0x1F << ICE_AQ_VSI_SW_VEB_STAT_ID_S)
|
|
|
|
|
#define ICE_AQ_VSI_SW_VEB_STAT_ID_VALID BIT(5)
|
|
|
|
|
/* security section */
|
|
|
|
|
u8 sec_flags;
|
|
|
|
|
#define ICE_AQ_VSI_SEC_FLAG_ALLOW_DEST_OVRD BIT(0)
|
|
|
|
|
#define ICE_AQ_VSI_SEC_FLAG_ENA_MAC_ANTI_SPOOF BIT(2)
|
|
|
|
|
#define ICE_AQ_VSI_SEC_TX_PRUNE_ENA_S 4
|
|
|
|
|
#define ICE_AQ_VSI_SEC_TX_PRUNE_ENA_M (0xF << ICE_AQ_VSI_SEC_TX_PRUNE_ENA_S)
|
|
|
|
|
#define ICE_AQ_VSI_SEC_TX_VLAN_PRUNE_ENA BIT(0)
|
|
|
|
|
u8 sec_reserved;
|
|
|
|
|
/* VLAN section */
|
|
|
|
|
__le16 pvid; /* VLANS include priority bits */
|
|
|
|
|
u8 pvlan_reserved[2];
|
|
|
|
|
u8 port_vlan_flags;
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_MODE_S 0
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_MODE_M (0x3 << ICE_AQ_VSI_PVLAN_MODE_S)
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_MODE_UNTAGGED 0x1
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_MODE_TAGGED 0x2
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_MODE_ALL 0x3
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_INSERT_PVID BIT(2)
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_EMOD_S 3
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_EMOD_M (0x3 << ICE_AQ_VSI_PVLAN_EMOD_S)
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_EMOD_STR_BOTH (0x0 << ICE_AQ_VSI_PVLAN_EMOD_S)
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_EMOD_STR_UP (0x1 << ICE_AQ_VSI_PVLAN_EMOD_S)
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_EMOD_STR (0x2 << ICE_AQ_VSI_PVLAN_EMOD_S)
|
|
|
|
|
#define ICE_AQ_VSI_PVLAN_EMOD_NOTHING (0x3 << ICE_AQ_VSI_PVLAN_EMOD_S)
|
|
|
|
|
u8 pvlan_reserved2[3];
|
|
|
|
|
/* ingress egress up sections */
|
|
|
|
|
__le32 ingress_table; /* bitmap, 3 bits per up */
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP0_S 0
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP0_M (0x7 << ICE_AQ_VSI_UP_TABLE_UP0_S)
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP1_S 3
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP1_M (0x7 << ICE_AQ_VSI_UP_TABLE_UP1_S)
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP2_S 6
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP2_M (0x7 << ICE_AQ_VSI_UP_TABLE_UP2_S)
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP3_S 9
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP3_M (0x7 << ICE_AQ_VSI_UP_TABLE_UP3_S)
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP4_S 12
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP4_M (0x7 << ICE_AQ_VSI_UP_TABLE_UP4_S)
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP5_S 15
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP5_M (0x7 << ICE_AQ_VSI_UP_TABLE_UP5_S)
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP6_S 18
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP6_M (0x7 << ICE_AQ_VSI_UP_TABLE_UP6_S)
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP7_S 21
|
|
|
|
|
#define ICE_AQ_VSI_UP_TABLE_UP7_M (0x7 << ICE_AQ_VSI_UP_TABLE_UP7_S)
|
|
|
|
|
__le32 egress_table; /* same defines as for ingress table */
|
|
|
|
|
/* outer tags section */
|
|
|
|
|
__le16 outer_tag;
|
|
|
|
|
u8 outer_tag_flags;
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_MODE_S 0
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_MODE_M (0x3 << ICE_AQ_VSI_OUTER_TAG_MODE_S)
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_NOTHING 0x0
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_REMOVE 0x1
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_COPY 0x2
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_TYPE_S 2
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_TYPE_M (0x3 << ICE_AQ_VSI_OUTER_TAG_TYPE_S)
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_NONE 0x0
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_STAG 0x1
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_VLAN_8100 0x2
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_VLAN_9100 0x3
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_INSERT BIT(4)
|
|
|
|
|
#define ICE_AQ_VSI_OUTER_TAG_ACCEPT_HOST BIT(6)
|
|
|
|
|
u8 outer_tag_reserved;
|
|
|
|
|
/* queue mapping section */
|
|
|
|
|
__le16 mapping_flags;
|
|
|
|
|
#define ICE_AQ_VSI_Q_MAP_CONTIG 0x0
|
|
|
|
|
#define ICE_AQ_VSI_Q_MAP_NONCONTIG BIT(0)
|
|
|
|
|
__le16 q_mapping[16];
|
|
|
|
|
#define ICE_AQ_VSI_Q_S 0
|
|
|
|
|
#define ICE_AQ_VSI_Q_M (0x7FF << ICE_AQ_VSI_Q_S)
|
|
|
|
|
__le16 tc_mapping[8];
|
|
|
|
|
#define ICE_AQ_VSI_TC_Q_OFFSET_S 0
|
|
|
|
|
#define ICE_AQ_VSI_TC_Q_OFFSET_M (0x7FF << ICE_AQ_VSI_TC_Q_OFFSET_S)
|
|
|
|
|
#define ICE_AQ_VSI_TC_Q_NUM_S 11
|
|
|
|
|
#define ICE_AQ_VSI_TC_Q_NUM_M (0xF << ICE_AQ_VSI_TC_Q_NUM_S)
|
|
|
|
|
/* queueing option section */
|
|
|
|
|
u8 q_opt_rss;
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_LUT_S 0
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_LUT_M (0x3 << ICE_AQ_VSI_Q_OPT_RSS_LUT_S)
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_LUT_VSI 0x0
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_LUT_PF 0x2
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_LUT_GBL 0x3
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_GBL_LUT_S 2
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_GBL_LUT_M (0xF << ICE_AQ_VSI_Q_OPT_RSS_GBL_LUT_S)
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_HASH_S 6
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_HASH_M (0x3 << ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_TPLZ (0x0 << ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_SYM_TPLZ (0x1 << ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_XOR (0x2 << ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_RSS_JHASH (0x3 << ICE_AQ_VSI_Q_OPT_RSS_HASH_S)
|
|
|
|
|
u8 q_opt_tc;
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_TC_OVR_S 0
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_TC_OVR_M (0x1F << ICE_AQ_VSI_Q_OPT_TC_OVR_S)
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_PROF_TC_OVR BIT(7)
|
|
|
|
|
u8 q_opt_flags;
|
|
|
|
|
#define ICE_AQ_VSI_Q_OPT_PE_FLTR_EN BIT(0)
|
|
|
|
|
u8 q_opt_reserved[3];
|
|
|
|
|
/* outer up section */
|
|
|
|
|
__le32 outer_up_table; /* same structure and defines as ingress tbl */
|
|
|
|
|
/* section 10 */
|
|
|
|
|
__le16 sect_10_reserved;
|
|
|
|
|
/* flow director section */
|
|
|
|
|
__le16 fd_options;
|
|
|
|
|
#define ICE_AQ_VSI_FD_ENABLE BIT(0)
|
|
|
|
|
#define ICE_AQ_VSI_FD_TX_AUTO_ENABLE BIT(1)
|
|
|
|
|
#define ICE_AQ_VSI_FD_PROG_ENABLE BIT(3)
|
|
|
|
|
__le16 max_fd_fltr_dedicated;
|
|
|
|
|
__le16 max_fd_fltr_shared;
|
|
|
|
|
__le16 fd_def_q;
|
|
|
|
|
#define ICE_AQ_VSI_FD_DEF_Q_S 0
|
|
|
|
|
#define ICE_AQ_VSI_FD_DEF_Q_M (0x7FF << ICE_AQ_VSI_FD_DEF_Q_S)
|
|
|
|
|
#define ICE_AQ_VSI_FD_DEF_GRP_S 12
|
|
|
|
|
#define ICE_AQ_VSI_FD_DEF_GRP_M (0x7 << ICE_AQ_VSI_FD_DEF_GRP_S)
|
|
|
|
|
__le16 fd_report_opt;
|
|
|
|
|
#define ICE_AQ_VSI_FD_REPORT_Q_S 0
|
|
|
|
|
#define ICE_AQ_VSI_FD_REPORT_Q_M (0x7FF << ICE_AQ_VSI_FD_REPORT_Q_S)
|
|
|
|
|
#define ICE_AQ_VSI_FD_DEF_PRIORITY_S 12
|
|
|
|
|
#define ICE_AQ_VSI_FD_DEF_PRIORITY_M (0x7 << ICE_AQ_VSI_FD_DEF_PRIORITY_S)
|
|
|
|
|
#define ICE_AQ_VSI_FD_DEF_DROP BIT(15)
|
|
|
|
|
/* PASID section */
|
|
|
|
|
__le32 pasid_id;
|
|
|
|
|
#define ICE_AQ_VSI_PASID_ID_S 0
|
|
|
|
|
#define ICE_AQ_VSI_PASID_ID_M (0xFFFFF << ICE_AQ_VSI_PASID_ID_S)
|
|
|
|
|
#define ICE_AQ_VSI_PASID_ID_VALID BIT(31)
|
|
|
|
|
u8 reserved[24];
|
|
|
|
|
};
|
|
|
|
|
|
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 22:58:12 +08:00
|
|
|
/* Add/Update/Remove/Get switch rules (indirect 0x02A0, 0x02A1, 0x02A2, 0x02A3)
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_sw_rules {
|
|
|
|
|
/* ops: add switch rules, referring the number of rules.
|
|
|
|
|
* ops: update switch rules, referring the number of filters
|
|
|
|
|
* ops: remove switch rules, referring the entry index.
|
|
|
|
|
* ops: get switch rules, referring to the number of filters.
|
|
|
|
|
*/
|
|
|
|
|
__le16 num_rules_fltr_entry_index;
|
|
|
|
|
u8 reserved[6];
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Add/Update/Get/Remove lookup Rx/Tx command/response entry
|
|
|
|
|
* This structures describes the lookup rules and associated actions. "index"
|
|
|
|
|
* is returned as part of a response to a successful Add command, and can be
|
|
|
|
|
* used to identify the rule for Update/Get/Remove commands.
|
|
|
|
|
*/
|
|
|
|
|
struct ice_sw_rule_lkup_rx_tx {
|
|
|
|
|
__le16 recipe_id;
|
|
|
|
|
#define ICE_SW_RECIPE_LOGICAL_PORT_FWD 10
|
|
|
|
|
/* Source port for LOOKUP_RX and source VSI in case of LOOKUP_TX */
|
|
|
|
|
__le16 src;
|
|
|
|
|
__le32 act;
|
|
|
|
|
|
|
|
|
|
/* Bit 0:1 - Action type */
|
|
|
|
|
#define ICE_SINGLE_ACT_TYPE_S 0x00
|
|
|
|
|
#define ICE_SINGLE_ACT_TYPE_M (0x3 << ICE_SINGLE_ACT_TYPE_S)
|
|
|
|
|
|
|
|
|
|
/* Bit 2 - Loop back enable
|
|
|
|
|
* Bit 3 - LAN enable
|
|
|
|
|
*/
|
|
|
|
|
#define ICE_SINGLE_ACT_LB_ENABLE BIT(2)
|
|
|
|
|
#define ICE_SINGLE_ACT_LAN_ENABLE BIT(3)
|
|
|
|
|
|
|
|
|
|
/* Action type = 0 - Forward to VSI or VSI list */
|
|
|
|
|
#define ICE_SINGLE_ACT_VSI_FORWARDING 0x0
|
|
|
|
|
|
|
|
|
|
#define ICE_SINGLE_ACT_VSI_ID_S 4
|
|
|
|
|
#define ICE_SINGLE_ACT_VSI_ID_M (0x3FF << ICE_SINGLE_ACT_VSI_ID_S)
|
|
|
|
|
#define ICE_SINGLE_ACT_VSI_LIST_ID_S 4
|
|
|
|
|
#define ICE_SINGLE_ACT_VSI_LIST_ID_M (0x3FF << ICE_SINGLE_ACT_VSI_LIST_ID_S)
|
|
|
|
|
/* This bit needs to be set if action is forward to VSI list */
|
|
|
|
|
#define ICE_SINGLE_ACT_VSI_LIST BIT(14)
|
|
|
|
|
#define ICE_SINGLE_ACT_VALID_BIT BIT(17)
|
|
|
|
|
#define ICE_SINGLE_ACT_DROP BIT(18)
|
|
|
|
|
|
|
|
|
|
/* Action type = 1 - Forward to Queue of Queue group */
|
|
|
|
|
#define ICE_SINGLE_ACT_TO_Q 0x1
|
|
|
|
|
#define ICE_SINGLE_ACT_Q_INDEX_S 4
|
|
|
|
|
#define ICE_SINGLE_ACT_Q_INDEX_M (0x7FF << ICE_SINGLE_ACT_Q_INDEX_S)
|
|
|
|
|
#define ICE_SINGLE_ACT_Q_REGION_S 15
|
|
|
|
|
#define ICE_SINGLE_ACT_Q_REGION_M (0x7 << ICE_SINGLE_ACT_Q_REGION_S)
|
|
|
|
|
#define ICE_SINGLE_ACT_Q_PRIORITY BIT(18)
|
|
|
|
|
|
|
|
|
|
/* Action type = 2 - Prune */
|
|
|
|
|
#define ICE_SINGLE_ACT_PRUNE 0x2
|
|
|
|
|
#define ICE_SINGLE_ACT_EGRESS BIT(15)
|
|
|
|
|
#define ICE_SINGLE_ACT_INGRESS BIT(16)
|
|
|
|
|
#define ICE_SINGLE_ACT_PRUNET BIT(17)
|
|
|
|
|
/* Bit 18 should be set to 0 for this action */
|
|
|
|
|
|
|
|
|
|
/* Action type = 2 - Pointer */
|
|
|
|
|
#define ICE_SINGLE_ACT_PTR 0x2
|
|
|
|
|
#define ICE_SINGLE_ACT_PTR_VAL_S 4
|
|
|
|
|
#define ICE_SINGLE_ACT_PTR_VAL_M (0x1FFF << ICE_SINGLE_ACT_PTR_VAL_S)
|
|
|
|
|
/* Bit 18 should be set to 1 */
|
|
|
|
|
#define ICE_SINGLE_ACT_PTR_BIT BIT(18)
|
|
|
|
|
|
|
|
|
|
/* Action type = 3 - Other actions. Last two bits
|
|
|
|
|
* are other action identifier
|
|
|
|
|
*/
|
|
|
|
|
#define ICE_SINGLE_ACT_OTHER_ACTS 0x3
|
|
|
|
|
#define ICE_SINGLE_OTHER_ACT_IDENTIFIER_S 17
|
|
|
|
|
#define ICE_SINGLE_OTHER_ACT_IDENTIFIER_M \
|
|
|
|
|
(0x3 << \ ICE_SINGLE_OTHER_ACT_IDENTIFIER_S)
|
|
|
|
|
|
|
|
|
|
/* Bit 17:18 - Defines other actions */
|
|
|
|
|
/* Other action = 0 - Mirror VSI */
|
|
|
|
|
#define ICE_SINGLE_OTHER_ACT_MIRROR 0
|
|
|
|
|
#define ICE_SINGLE_ACT_MIRROR_VSI_ID_S 4
|
|
|
|
|
#define ICE_SINGLE_ACT_MIRROR_VSI_ID_M \
|
|
|
|
|
(0x3FF << ICE_SINGLE_ACT_MIRROR_VSI_ID_S)
|
|
|
|
|
|
|
|
|
|
/* Other action = 3 - Set Stat count */
|
|
|
|
|
#define ICE_SINGLE_OTHER_ACT_STAT_COUNT 3
|
|
|
|
|
#define ICE_SINGLE_ACT_STAT_COUNT_INDEX_S 4
|
|
|
|
|
#define ICE_SINGLE_ACT_STAT_COUNT_INDEX_M \
|
|
|
|
|
(0x7F << ICE_SINGLE_ACT_STAT_COUNT_INDEX_S)
|
|
|
|
|
|
|
|
|
|
__le16 index; /* The index of the rule in the lookup table */
|
|
|
|
|
/* Length and values of the header to be matched per recipe or
|
|
|
|
|
* lookup-type
|
|
|
|
|
*/
|
|
|
|
|
__le16 hdr_len;
|
|
|
|
|
u8 hdr[1];
|
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
|
|
/* Add/Update/Remove large action command/response entry
|
|
|
|
|
* "index" is returned as part of a response to a successful Add command, and
|
|
|
|
|
* can be used to identify the action for Update/Get/Remove commands.
|
|
|
|
|
*/
|
|
|
|
|
struct ice_sw_rule_lg_act {
|
|
|
|
|
__le16 index; /* Index in large action table */
|
|
|
|
|
__le16 size;
|
|
|
|
|
__le32 act[1]; /* array of size for actions */
|
|
|
|
|
/* Max number of large actions */
|
|
|
|
|
#define ICE_MAX_LG_ACT 4
|
|
|
|
|
/* Bit 0:1 - Action type */
|
|
|
|
|
#define ICE_LG_ACT_TYPE_S 0
|
|
|
|
|
#define ICE_LG_ACT_TYPE_M (0x7 << ICE_LG_ACT_TYPE_S)
|
|
|
|
|
|
|
|
|
|
/* Action type = 0 - Forward to VSI or VSI list */
|
|
|
|
|
#define ICE_LG_ACT_VSI_FORWARDING 0
|
|
|
|
|
#define ICE_LG_ACT_VSI_ID_S 3
|
|
|
|
|
#define ICE_LG_ACT_VSI_ID_M (0x3FF << ICE_LG_ACT_VSI_ID_S)
|
|
|
|
|
#define ICE_LG_ACT_VSI_LIST_ID_S 3
|
|
|
|
|
#define ICE_LG_ACT_VSI_LIST_ID_M (0x3FF << ICE_LG_ACT_VSI_LIST_ID_S)
|
|
|
|
|
/* This bit needs to be set if action is forward to VSI list */
|
|
|
|
|
#define ICE_LG_ACT_VSI_LIST BIT(13)
|
|
|
|
|
|
|
|
|
|
#define ICE_LG_ACT_VALID_BIT BIT(16)
|
|
|
|
|
|
|
|
|
|
/* Action type = 1 - Forward to Queue of Queue group */
|
|
|
|
|
#define ICE_LG_ACT_TO_Q 0x1
|
|
|
|
|
#define ICE_LG_ACT_Q_INDEX_S 3
|
|
|
|
|
#define ICE_LG_ACT_Q_INDEX_M (0x7FF << ICE_LG_ACT_Q_INDEX_S)
|
|
|
|
|
#define ICE_LG_ACT_Q_REGION_S 14
|
|
|
|
|
#define ICE_LG_ACT_Q_REGION_M (0x7 << ICE_LG_ACT_Q_REGION_S)
|
|
|
|
|
#define ICE_LG_ACT_Q_PRIORITY_SET BIT(17)
|
|
|
|
|
|
|
|
|
|
/* Action type = 2 - Prune */
|
|
|
|
|
#define ICE_LG_ACT_PRUNE 0x2
|
|
|
|
|
#define ICE_LG_ACT_EGRESS BIT(14)
|
|
|
|
|
#define ICE_LG_ACT_INGRESS BIT(15)
|
|
|
|
|
#define ICE_LG_ACT_PRUNET BIT(16)
|
|
|
|
|
|
|
|
|
|
/* Action type = 3 - Mirror VSI */
|
|
|
|
|
#define ICE_LG_OTHER_ACT_MIRROR 0x3
|
|
|
|
|
#define ICE_LG_ACT_MIRROR_VSI_ID_S 3
|
|
|
|
|
#define ICE_LG_ACT_MIRROR_VSI_ID_M (0x3FF << ICE_LG_ACT_MIRROR_VSI_ID_S)
|
|
|
|
|
|
|
|
|
|
/* Action type = 5 - Large Action */
|
|
|
|
|
#define ICE_LG_ACT_GENERIC 0x5
|
|
|
|
|
#define ICE_LG_ACT_GENERIC_VALUE_S 3
|
|
|
|
|
#define ICE_LG_ACT_GENERIC_VALUE_M (0xFFFF << ICE_LG_ACT_GENERIC_VALUE_S)
|
|
|
|
|
#define ICE_LG_ACT_GENERIC_OFFSET_S 19
|
|
|
|
|
#define ICE_LG_ACT_GENERIC_OFFSET_M (0x7 << ICE_LG_ACT_GENERIC_OFFSET_S)
|
|
|
|
|
#define ICE_LG_ACT_GENERIC_PRIORITY_S 22
|
|
|
|
|
#define ICE_LG_ACT_GENERIC_PRIORITY_M (0x7 << ICE_LG_ACT_GENERIC_PRIORITY_S)
|
|
|
|
|
|
|
|
|
|
/* Action = 7 - Set Stat count */
|
|
|
|
|
#define ICE_LG_ACT_STAT_COUNT 0x7
|
|
|
|
|
#define ICE_LG_ACT_STAT_COUNT_S 3
|
|
|
|
|
#define ICE_LG_ACT_STAT_COUNT_M (0x7F << ICE_LG_ACT_STAT_COUNT_S)
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Add/Update/Remove VSI list command/response entry
|
|
|
|
|
* "index" is returned as part of a response to a successful Add command, and
|
|
|
|
|
* can be used to identify the VSI list for Update/Get/Remove commands.
|
|
|
|
|
*/
|
|
|
|
|
struct ice_sw_rule_vsi_list {
|
|
|
|
|
__le16 index; /* Index of VSI/Prune list */
|
|
|
|
|
__le16 number_vsi;
|
|
|
|
|
__le16 vsi[1]; /* Array of number_vsi VSI numbers */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Query VSI list command/response entry */
|
|
|
|
|
struct ice_sw_rule_vsi_list_query {
|
|
|
|
|
__le16 index;
|
|
|
|
|
DECLARE_BITMAP(vsi_list, ICE_MAX_VSI);
|
|
|
|
|
} __packed;
|
|
|
|
|
|
|
|
|
|
/* Add switch rule response:
|
|
|
|
|
* Content of return buffer is same as the input buffer. The status field and
|
|
|
|
|
* LUT index are updated as part of the response
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_sw_rules_elem {
|
|
|
|
|
__le16 type; /* Switch rule type, one of T_... */
|
|
|
|
|
#define ICE_AQC_SW_RULES_T_LKUP_RX 0x0
|
|
|
|
|
#define ICE_AQC_SW_RULES_T_LKUP_TX 0x1
|
|
|
|
|
#define ICE_AQC_SW_RULES_T_LG_ACT 0x2
|
|
|
|
|
#define ICE_AQC_SW_RULES_T_VSI_LIST_SET 0x3
|
|
|
|
|
#define ICE_AQC_SW_RULES_T_VSI_LIST_CLEAR 0x4
|
|
|
|
|
#define ICE_AQC_SW_RULES_T_PRUNE_LIST_SET 0x5
|
|
|
|
|
#define ICE_AQC_SW_RULES_T_PRUNE_LIST_CLEAR 0x6
|
|
|
|
|
__le16 status;
|
|
|
|
|
union {
|
|
|
|
|
struct ice_sw_rule_lkup_rx_tx lkup_tx_rx;
|
|
|
|
|
struct ice_sw_rule_lg_act lg_act;
|
|
|
|
|
struct ice_sw_rule_vsi_list vsi_list;
|
|
|
|
|
struct ice_sw_rule_vsi_list_query vsi_list_query;
|
|
|
|
|
} __packed pdata;
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-20 22:58:09 +08:00
|
|
|
/* Get Default Topology (indirect 0x0400) */
|
|
|
|
|
struct ice_aqc_get_topo {
|
|
|
|
|
u8 port_num;
|
|
|
|
|
u8 num_branches;
|
|
|
|
|
__le16 reserved1;
|
|
|
|
|
__le32 reserved2;
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
/* Add TSE (indirect 0x0401)
|
|
|
|
|
* Delete TSE (indirect 0x040F)
|
|
|
|
|
* Move TSE (indirect 0x0408)
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_add_move_delete_elem {
|
|
|
|
|
__le16 num_grps_req;
|
|
|
|
|
__le16 num_grps_updated;
|
|
|
|
|
__le32 reserved;
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ice_aqc_elem_info_bw {
|
|
|
|
|
__le16 bw_profile_idx;
|
|
|
|
|
__le16 bw_alloc;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ice_aqc_txsched_elem {
|
|
|
|
|
u8 elem_type; /* Special field, reserved for some aq calls */
|
|
|
|
|
#define ICE_AQC_ELEM_TYPE_UNDEFINED 0x0
|
|
|
|
|
#define ICE_AQC_ELEM_TYPE_ROOT_PORT 0x1
|
|
|
|
|
#define ICE_AQC_ELEM_TYPE_TC 0x2
|
|
|
|
|
#define ICE_AQC_ELEM_TYPE_SE_GENERIC 0x3
|
|
|
|
|
#define ICE_AQC_ELEM_TYPE_ENTRY_POINT 0x4
|
|
|
|
|
#define ICE_AQC_ELEM_TYPE_LEAF 0x5
|
|
|
|
|
#define ICE_AQC_ELEM_TYPE_SE_PADDED 0x6
|
|
|
|
|
u8 valid_sections;
|
|
|
|
|
#define ICE_AQC_ELEM_VALID_GENERIC BIT(0)
|
|
|
|
|
#define ICE_AQC_ELEM_VALID_CIR BIT(1)
|
|
|
|
|
#define ICE_AQC_ELEM_VALID_EIR BIT(2)
|
|
|
|
|
#define ICE_AQC_ELEM_VALID_SHARED BIT(3)
|
|
|
|
|
u8 generic;
|
|
|
|
|
#define ICE_AQC_ELEM_GENERIC_MODE_M 0x1
|
|
|
|
|
#define ICE_AQC_ELEM_GENERIC_PRIO_S 0x1
|
|
|
|
|
#define ICE_AQC_ELEM_GENERIC_PRIO_M (0x7 << ICE_AQC_ELEM_GENERIC_PRIO_S)
|
|
|
|
|
#define ICE_AQC_ELEM_GENERIC_SP_S 0x4
|
|
|
|
|
#define ICE_AQC_ELEM_GENERIC_SP_M (0x1 << ICE_AQC_ELEM_GENERIC_SP_S)
|
|
|
|
|
#define ICE_AQC_ELEM_GENERIC_ADJUST_VAL_S 0x5
|
|
|
|
|
#define ICE_AQC_ELEM_GENERIC_ADJUST_VAL_M \
|
|
|
|
|
(0x3 << ICE_AQC_ELEM_GENERIC_ADJUST_VAL_S)
|
|
|
|
|
u8 flags; /* Special field, reserved for some aq calls */
|
|
|
|
|
#define ICE_AQC_ELEM_FLAG_SUSPEND_M 0x1
|
|
|
|
|
struct ice_aqc_elem_info_bw cir_bw;
|
|
|
|
|
struct ice_aqc_elem_info_bw eir_bw;
|
|
|
|
|
__le16 srl_id;
|
|
|
|
|
__le16 reserved2;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ice_aqc_txsched_elem_data {
|
|
|
|
|
__le32 parent_teid;
|
|
|
|
|
__le32 node_teid;
|
|
|
|
|
struct ice_aqc_txsched_elem data;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ice_aqc_txsched_topo_grp_info_hdr {
|
|
|
|
|
__le32 parent_teid;
|
|
|
|
|
__le16 num_elems;
|
|
|
|
|
__le16 reserved2;
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-20 22:58:09 +08:00
|
|
|
struct ice_aqc_get_topo_elem {
|
|
|
|
|
struct ice_aqc_txsched_topo_grp_info_hdr hdr;
|
|
|
|
|
struct ice_aqc_txsched_elem_data
|
|
|
|
|
generic[ICE_AQC_TOPO_MAX_LEVEL_NUM];
|
|
|
|
|
};
|
|
|
|
|
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
struct ice_aqc_delete_elem {
|
|
|
|
|
struct ice_aqc_txsched_topo_grp_info_hdr hdr;
|
|
|
|
|
__le32 teid[1];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Query Scheduler Resource Allocation (indirect 0x0412)
|
|
|
|
|
* This indirect command retrieves the scheduler resources allocated by
|
|
|
|
|
* EMP Firmware to the given PF.
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_query_txsched_res {
|
|
|
|
|
u8 reserved[8];
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ice_aqc_generic_sched_props {
|
|
|
|
|
__le16 phys_levels;
|
|
|
|
|
__le16 logical_levels;
|
|
|
|
|
u8 flattening_bitmap;
|
|
|
|
|
u8 max_device_cgds;
|
|
|
|
|
u8 max_pf_cgds;
|
|
|
|
|
u8 rsvd0;
|
|
|
|
|
__le16 rdma_qsets;
|
|
|
|
|
u8 rsvd1[22];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ice_aqc_layer_props {
|
|
|
|
|
u8 logical_layer;
|
|
|
|
|
u8 chunk_size;
|
|
|
|
|
__le16 max_device_nodes;
|
|
|
|
|
__le16 max_pf_nodes;
|
|
|
|
|
u8 rsvd0[2];
|
|
|
|
|
__le16 max_shared_rate_lmtr;
|
|
|
|
|
__le16 max_children;
|
|
|
|
|
__le16 max_cir_rl_profiles;
|
|
|
|
|
__le16 max_eir_rl_profiles;
|
|
|
|
|
__le16 max_srl_profiles;
|
|
|
|
|
u8 rsvd1[14];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ice_aqc_query_txsched_res_resp {
|
|
|
|
|
struct ice_aqc_generic_sched_props sched_props;
|
|
|
|
|
struct ice_aqc_layer_props layer_props[ICE_AQC_TOPO_MAX_LEVEL_NUM];
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-20 22:58:09 +08:00
|
|
|
/* Get PHY capabilities (indirect 0x0600) */
|
|
|
|
|
struct ice_aqc_get_phy_caps {
|
|
|
|
|
u8 lport_num;
|
|
|
|
|
u8 reserved;
|
|
|
|
|
__le16 param0;
|
|
|
|
|
/* 18.0 - Report qualified modules */
|
|
|
|
|
#define ICE_AQC_GET_PHY_RQM BIT(0)
|
|
|
|
|
/* 18.1 - 18.2 : Report mode
|
|
|
|
|
* 00b - Report NVM capabilities
|
|
|
|
|
* 01b - Report topology capabilities
|
|
|
|
|
* 10b - Report SW configured
|
|
|
|
|
*/
|
|
|
|
|
#define ICE_AQC_REPORT_MODE_S 1
|
|
|
|
|
#define ICE_AQC_REPORT_MODE_M (3 << ICE_AQC_REPORT_MODE_S)
|
|
|
|
|
#define ICE_AQC_REPORT_NVM_CAP 0
|
|
|
|
|
#define ICE_AQC_REPORT_TOPO_CAP BIT(1)
|
|
|
|
|
#define ICE_AQC_REPORT_SW_CFG BIT(2)
|
|
|
|
|
__le32 reserved1;
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* This is #define of PHY type (Extended):
|
|
|
|
|
* The first set of defines is for phy_type_low.
|
|
|
|
|
*/
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_100BASE_TX BIT_ULL(0)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_100M_SGMII BIT_ULL(1)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_1000BASE_T BIT_ULL(2)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_1000BASE_SX BIT_ULL(3)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_1000BASE_LX BIT_ULL(4)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_1000BASE_KX BIT_ULL(5)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_1G_SGMII BIT_ULL(6)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_2500BASE_T BIT_ULL(7)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_2500BASE_X BIT_ULL(8)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_2500BASE_KX BIT_ULL(9)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_5GBASE_T BIT_ULL(10)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_5GBASE_KR BIT_ULL(11)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_10GBASE_T BIT_ULL(12)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_10G_SFI_DA BIT_ULL(13)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_10GBASE_SR BIT_ULL(14)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_10GBASE_LR BIT_ULL(15)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_10GBASE_KR_CR1 BIT_ULL(16)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_10G_SFI_AOC_ACC BIT_ULL(17)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_10G_SFI_C2C BIT_ULL(18)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25GBASE_T BIT_ULL(19)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25GBASE_CR BIT_ULL(20)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25GBASE_CR_S BIT_ULL(21)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25GBASE_CR1 BIT_ULL(22)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25GBASE_SR BIT_ULL(23)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25GBASE_LR BIT_ULL(24)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25GBASE_KR BIT_ULL(25)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25GBASE_KR_S BIT_ULL(26)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25GBASE_KR1 BIT_ULL(27)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25G_AUI_AOC_ACC BIT_ULL(28)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_25G_AUI_C2C BIT_ULL(29)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_40GBASE_CR4 BIT_ULL(30)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_40GBASE_SR4 BIT_ULL(31)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_40GBASE_LR4 BIT_ULL(32)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_40GBASE_KR4 BIT_ULL(33)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_40G_XLAUI_AOC_ACC BIT_ULL(34)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_40G_XLAUI BIT_ULL(35)
|
|
|
|
|
#define ICE_PHY_TYPE_LOW_MAX_INDEX 63
|
|
|
|
|
|
|
|
|
|
struct ice_aqc_get_phy_caps_data {
|
|
|
|
|
__le64 phy_type_low; /* Use values from ICE_PHY_TYPE_LOW_* */
|
|
|
|
|
__le64 reserved;
|
|
|
|
|
u8 caps;
|
|
|
|
|
#define ICE_AQC_PHY_EN_TX_LINK_PAUSE BIT(0)
|
|
|
|
|
#define ICE_AQC_PHY_EN_RX_LINK_PAUSE BIT(1)
|
|
|
|
|
#define ICE_AQC_PHY_LOW_POWER_MODE BIT(2)
|
|
|
|
|
#define ICE_AQC_PHY_EN_LINK BIT(3)
|
|
|
|
|
#define ICE_AQC_PHY_AN_MODE BIT(4)
|
|
|
|
|
#define ICE_AQC_GET_PHY_EN_MOD_QUAL BIT(5)
|
|
|
|
|
u8 low_power_ctrl;
|
|
|
|
|
#define ICE_AQC_PHY_EN_D3COLD_LOW_POWER_AUTONEG BIT(0)
|
|
|
|
|
__le16 eee_cap;
|
|
|
|
|
#define ICE_AQC_PHY_EEE_EN_100BASE_TX BIT(0)
|
|
|
|
|
#define ICE_AQC_PHY_EEE_EN_1000BASE_T BIT(1)
|
|
|
|
|
#define ICE_AQC_PHY_EEE_EN_10GBASE_T BIT(2)
|
|
|
|
|
#define ICE_AQC_PHY_EEE_EN_1000BASE_KX BIT(3)
|
|
|
|
|
#define ICE_AQC_PHY_EEE_EN_10GBASE_KR BIT(4)
|
|
|
|
|
#define ICE_AQC_PHY_EEE_EN_25GBASE_KR BIT(5)
|
|
|
|
|
#define ICE_AQC_PHY_EEE_EN_40GBASE_KR4 BIT(6)
|
|
|
|
|
__le16 eeer_value;
|
|
|
|
|
u8 phy_id_oui[4]; /* PHY/Module ID connected on the port */
|
|
|
|
|
u8 link_fec_options;
|
|
|
|
|
#define ICE_AQC_PHY_FEC_10G_KR_40G_KR4_EN BIT(0)
|
|
|
|
|
#define ICE_AQC_PHY_FEC_10G_KR_40G_KR4_REQ BIT(1)
|
|
|
|
|
#define ICE_AQC_PHY_FEC_25G_RS_528_REQ BIT(2)
|
|
|
|
|
#define ICE_AQC_PHY_FEC_25G_KR_REQ BIT(3)
|
|
|
|
|
#define ICE_AQC_PHY_FEC_25G_RS_544_REQ BIT(4)
|
|
|
|
|
#define ICE_AQC_PHY_FEC_25G_RS_CLAUSE91_EN BIT(6)
|
|
|
|
|
#define ICE_AQC_PHY_FEC_25G_KR_CLAUSE74_EN BIT(7)
|
|
|
|
|
u8 extended_compliance_code;
|
|
|
|
|
#define ICE_MODULE_TYPE_TOTAL_BYTE 3
|
|
|
|
|
u8 module_type[ICE_MODULE_TYPE_TOTAL_BYTE];
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE0_SFP_PLUS 0xA0
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE0_QSFP_PLUS 0x80
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE1_SFP_PLUS_CU_PASSIVE BIT(0)
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE1_SFP_PLUS_CU_ACTIVE BIT(1)
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE1_10G_BASE_SR BIT(4)
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE1_10G_BASE_LR BIT(5)
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE1_10G_BASE_LRM BIT(6)
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE1_10G_BASE_ER BIT(7)
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE2_SFP_PLUS 0xA0
|
|
|
|
|
#define ICE_AQC_MOD_TYPE_BYTE2_QSFP_PLUS 0x86
|
|
|
|
|
u8 qualified_module_count;
|
|
|
|
|
#define ICE_AQC_QUAL_MOD_COUNT_MAX 16
|
|
|
|
|
struct {
|
|
|
|
|
u8 v_oui[3];
|
|
|
|
|
u8 rsvd1;
|
|
|
|
|
u8 v_part[16];
|
|
|
|
|
__le32 v_rev;
|
|
|
|
|
__le64 rsvd8;
|
|
|
|
|
} qual_modules[ICE_AQC_QUAL_MOD_COUNT_MAX];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Get link status (indirect 0x0607), also used for Link Status Event */
|
|
|
|
|
struct ice_aqc_get_link_status {
|
|
|
|
|
u8 lport_num;
|
|
|
|
|
u8 reserved;
|
|
|
|
|
__le16 cmd_flags;
|
|
|
|
|
#define ICE_AQ_LSE_M 0x3
|
|
|
|
|
#define ICE_AQ_LSE_NOP 0x0
|
|
|
|
|
#define ICE_AQ_LSE_DIS 0x2
|
|
|
|
|
#define ICE_AQ_LSE_ENA 0x3
|
|
|
|
|
/* only response uses this flag */
|
|
|
|
|
#define ICE_AQ_LSE_IS_ENABLED 0x1
|
|
|
|
|
__le32 reserved2;
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Get link status response data structure, also used for Link Status Event */
|
|
|
|
|
struct ice_aqc_get_link_status_data {
|
|
|
|
|
u8 topo_media_conflict;
|
|
|
|
|
#define ICE_AQ_LINK_TOPO_CONFLICT BIT(0)
|
|
|
|
|
#define ICE_AQ_LINK_MEDIA_CONFLICT BIT(1)
|
|
|
|
|
#define ICE_AQ_LINK_TOPO_CORRUPT BIT(2)
|
|
|
|
|
u8 reserved1;
|
|
|
|
|
u8 link_info;
|
|
|
|
|
#define ICE_AQ_LINK_UP BIT(0) /* Link Status */
|
|
|
|
|
#define ICE_AQ_LINK_FAULT BIT(1)
|
|
|
|
|
#define ICE_AQ_LINK_FAULT_TX BIT(2)
|
|
|
|
|
#define ICE_AQ_LINK_FAULT_RX BIT(3)
|
|
|
|
|
#define ICE_AQ_LINK_FAULT_REMOTE BIT(4)
|
|
|
|
|
#define ICE_AQ_LINK_UP_PORT BIT(5) /* External Port Link Status */
|
|
|
|
|
#define ICE_AQ_MEDIA_AVAILABLE BIT(6)
|
|
|
|
|
#define ICE_AQ_SIGNAL_DETECT BIT(7)
|
|
|
|
|
u8 an_info;
|
|
|
|
|
#define ICE_AQ_AN_COMPLETED BIT(0)
|
|
|
|
|
#define ICE_AQ_LP_AN_ABILITY BIT(1)
|
|
|
|
|
#define ICE_AQ_PD_FAULT BIT(2) /* Parallel Detection Fault */
|
|
|
|
|
#define ICE_AQ_FEC_EN BIT(3)
|
|
|
|
|
#define ICE_AQ_PHY_LOW_POWER BIT(4) /* Low Power State */
|
|
|
|
|
#define ICE_AQ_LINK_PAUSE_TX BIT(5)
|
|
|
|
|
#define ICE_AQ_LINK_PAUSE_RX BIT(6)
|
|
|
|
|
#define ICE_AQ_QUALIFIED_MODULE BIT(7)
|
|
|
|
|
u8 ext_info;
|
|
|
|
|
#define ICE_AQ_LINK_PHY_TEMP_ALARM BIT(0)
|
|
|
|
|
#define ICE_AQ_LINK_EXCESSIVE_ERRORS BIT(1) /* Excessive Link Errors */
|
|
|
|
|
/* Port TX Suspended */
|
|
|
|
|
#define ICE_AQ_LINK_TX_S 2
|
|
|
|
|
#define ICE_AQ_LINK_TX_M (0x03 << ICE_AQ_LINK_TX_S)
|
|
|
|
|
#define ICE_AQ_LINK_TX_ACTIVE 0
|
|
|
|
|
#define ICE_AQ_LINK_TX_DRAINED 1
|
|
|
|
|
#define ICE_AQ_LINK_TX_FLUSHED 3
|
|
|
|
|
u8 reserved2;
|
|
|
|
|
__le16 max_frame_size;
|
|
|
|
|
u8 cfg;
|
|
|
|
|
#define ICE_AQ_LINK_25G_KR_FEC_EN BIT(0)
|
|
|
|
|
#define ICE_AQ_LINK_25G_RS_528_FEC_EN BIT(1)
|
|
|
|
|
#define ICE_AQ_LINK_25G_RS_544_FEC_EN BIT(2)
|
|
|
|
|
/* Pacing Config */
|
|
|
|
|
#define ICE_AQ_CFG_PACING_S 3
|
|
|
|
|
#define ICE_AQ_CFG_PACING_M (0xF << ICE_AQ_CFG_PACING_S)
|
|
|
|
|
#define ICE_AQ_CFG_PACING_TYPE_M BIT(7)
|
|
|
|
|
#define ICE_AQ_CFG_PACING_TYPE_AVG 0
|
|
|
|
|
#define ICE_AQ_CFG_PACING_TYPE_FIXED ICE_AQ_CFG_PACING_TYPE_M
|
|
|
|
|
/* External Device Power Ability */
|
|
|
|
|
u8 power_desc;
|
|
|
|
|
#define ICE_AQ_PWR_CLASS_M 0x3
|
|
|
|
|
#define ICE_AQ_LINK_PWR_BASET_LOW_HIGH 0
|
|
|
|
|
#define ICE_AQ_LINK_PWR_BASET_HIGH 1
|
|
|
|
|
#define ICE_AQ_LINK_PWR_QSFP_CLASS_1 0
|
|
|
|
|
#define ICE_AQ_LINK_PWR_QSFP_CLASS_2 1
|
|
|
|
|
#define ICE_AQ_LINK_PWR_QSFP_CLASS_3 2
|
|
|
|
|
#define ICE_AQ_LINK_PWR_QSFP_CLASS_4 3
|
|
|
|
|
__le16 link_speed;
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_10MB BIT(0)
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_100MB BIT(1)
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_1000MB BIT(2)
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_2500MB BIT(3)
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_5GB BIT(4)
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_10GB BIT(5)
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_20GB BIT(6)
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_25GB BIT(7)
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_40GB BIT(8)
|
|
|
|
|
#define ICE_AQ_LINK_SPEED_UNKNOWN BIT(15)
|
|
|
|
|
__le32 reserved3; /* Aligns next field to 8-byte boundary */
|
|
|
|
|
__le64 phy_type_low; /* Use values from ICE_PHY_TYPE_LOW_* */
|
|
|
|
|
__le64 reserved4;
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-20 22:58:07 +08:00
|
|
|
/* NVM Read command (indirect 0x0701)
|
|
|
|
|
* NVM Erase commands (direct 0x0702)
|
|
|
|
|
* NVM Update commands (indirect 0x0703)
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aqc_nvm {
|
|
|
|
|
u8 cmd_flags;
|
|
|
|
|
#define ICE_AQC_NVM_LAST_CMD BIT(0)
|
|
|
|
|
#define ICE_AQC_NVM_PCIR_REQ BIT(0) /* Used by NVM Update reply */
|
|
|
|
|
#define ICE_AQC_NVM_PRESERVATION_S 1
|
|
|
|
|
#define ICE_AQC_NVM_PRESERVATION_M (3 << CSR_AQ_NVM_PRESERVATION_S)
|
|
|
|
|
#define ICE_AQC_NVM_NO_PRESERVATION (0 << CSR_AQ_NVM_PRESERVATION_S)
|
|
|
|
|
#define ICE_AQC_NVM_PRESERVE_ALL BIT(1)
|
|
|
|
|
#define ICE_AQC_NVM_PRESERVE_SELECTED (3 << CSR_AQ_NVM_PRESERVATION_S)
|
|
|
|
|
#define ICE_AQC_NVM_FLASH_ONLY BIT(7)
|
|
|
|
|
u8 module_typeid;
|
|
|
|
|
__le16 length;
|
|
|
|
|
#define ICE_AQC_NVM_ERASE_LEN 0xFFFF
|
|
|
|
|
__le32 offset;
|
|
|
|
|
__le32 addr_high;
|
|
|
|
|
__le32 addr_low;
|
|
|
|
|
};
|
|
|
|
|
|
2018-03-20 22:58:06 +08:00
|
|
|
/**
|
|
|
|
|
* struct ice_aq_desc - Admin Queue (AQ) descriptor
|
|
|
|
|
* @flags: ICE_AQ_FLAG_* flags
|
|
|
|
|
* @opcode: AQ command opcode
|
|
|
|
|
* @datalen: length in bytes of indirect/external data buffer
|
|
|
|
|
* @retval: return value from firmware
|
|
|
|
|
* @cookie_h: opaque data high-half
|
|
|
|
|
* @cookie_l: opaque data low-half
|
|
|
|
|
* @params: command-specific parameters
|
|
|
|
|
*
|
|
|
|
|
* Descriptor format for commands the driver posts on the Admin Transmit Queue
|
|
|
|
|
* (ATQ). The firmware writes back onto the command descriptor and returns
|
|
|
|
|
* the result of the command. Asynchronous events that are not an immediate
|
|
|
|
|
* result of the command are written to the Admin Receive Queue (ARQ) using
|
|
|
|
|
* the same descriptor format. Descriptors are in little-endian notation with
|
|
|
|
|
* 32-bit words.
|
|
|
|
|
*/
|
|
|
|
|
struct ice_aq_desc {
|
|
|
|
|
__le16 flags;
|
|
|
|
|
__le16 opcode;
|
|
|
|
|
__le16 datalen;
|
|
|
|
|
__le16 retval;
|
|
|
|
|
__le32 cookie_high;
|
|
|
|
|
__le32 cookie_low;
|
|
|
|
|
union {
|
|
|
|
|
u8 raw[16];
|
|
|
|
|
struct ice_aqc_generic generic;
|
|
|
|
|
struct ice_aqc_get_ver get_ver;
|
|
|
|
|
struct ice_aqc_q_shutdown q_shutdown;
|
2018-03-20 22:58:07 +08:00
|
|
|
struct ice_aqc_req_res res_owner;
|
2018-03-20 22:58:09 +08:00
|
|
|
struct ice_aqc_manage_mac_read mac_read;
|
2018-03-20 22:58:07 +08:00
|
|
|
struct ice_aqc_clear_pxe clear_pxe;
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
struct ice_aqc_list_caps get_cap;
|
2018-03-20 22:58:09 +08:00
|
|
|
struct ice_aqc_get_phy_caps get_phy;
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
struct ice_aqc_get_sw_cfg get_sw_conf;
|
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 22:58:12 +08:00
|
|
|
struct ice_aqc_sw_rules sw_rules;
|
2018-03-20 22:58:09 +08:00
|
|
|
struct ice_aqc_get_topo get_topo;
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
struct ice_aqc_query_txsched_res query_sched_res;
|
|
|
|
|
struct ice_aqc_add_move_delete_elem add_move_delete_elem;
|
2018-03-20 22:58:07 +08:00
|
|
|
struct ice_aqc_nvm nvm;
|
2018-03-20 22:58:11 +08:00
|
|
|
struct ice_aqc_add_get_update_free_vsi vsi_cmd;
|
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 22:58:12 +08:00
|
|
|
struct ice_aqc_alloc_free_res_cmd sw_res_ctrl;
|
2018-03-20 22:58:09 +08:00
|
|
|
struct ice_aqc_get_link_status get_link_status;
|
2018-03-20 22:58:06 +08:00
|
|
|
} params;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* FW defined boundary for a large buffer, 4k >= Large buffer > 512 bytes */
|
|
|
|
|
#define ICE_AQ_LG_BUF 512
|
|
|
|
|
|
2018-03-20 22:58:10 +08:00
|
|
|
#define ICE_AQ_FLAG_ERR_S 2
|
2018-03-20 22:58:06 +08:00
|
|
|
#define ICE_AQ_FLAG_LB_S 9
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
#define ICE_AQ_FLAG_RD_S 10
|
2018-03-20 22:58:06 +08:00
|
|
|
#define ICE_AQ_FLAG_BUF_S 12
|
|
|
|
|
#define ICE_AQ_FLAG_SI_S 13
|
|
|
|
|
|
2018-03-20 22:58:10 +08:00
|
|
|
#define ICE_AQ_FLAG_ERR BIT(ICE_AQ_FLAG_ERR_S) /* 0x4 */
|
2018-03-20 22:58:06 +08:00
|
|
|
#define ICE_AQ_FLAG_LB BIT(ICE_AQ_FLAG_LB_S) /* 0x200 */
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
#define ICE_AQ_FLAG_RD BIT(ICE_AQ_FLAG_RD_S) /* 0x400 */
|
2018-03-20 22:58:06 +08:00
|
|
|
#define ICE_AQ_FLAG_BUF BIT(ICE_AQ_FLAG_BUF_S) /* 0x1000 */
|
|
|
|
|
#define ICE_AQ_FLAG_SI BIT(ICE_AQ_FLAG_SI_S) /* 0x2000 */
|
|
|
|
|
|
|
|
|
|
/* error codes */
|
|
|
|
|
enum ice_aq_err {
|
|
|
|
|
ICE_AQ_RC_OK = 0, /* success */
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
ICE_AQ_RC_ENOMEM = 9, /* Out of memory */
|
2018-03-20 22:58:07 +08:00
|
|
|
ICE_AQ_RC_EBUSY = 12, /* Device or resource busy */
|
|
|
|
|
ICE_AQ_RC_EEXIST = 13, /* object already exists */
|
2018-03-20 22:58:06 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* Admin Queue command opcodes */
|
|
|
|
|
enum ice_adminq_opc {
|
|
|
|
|
/* AQ commands */
|
|
|
|
|
ice_aqc_opc_get_ver = 0x0001,
|
|
|
|
|
ice_aqc_opc_q_shutdown = 0x0003,
|
2018-03-20 22:58:07 +08:00
|
|
|
|
|
|
|
|
/* resource ownership */
|
|
|
|
|
ice_aqc_opc_req_res = 0x0008,
|
|
|
|
|
ice_aqc_opc_release_res = 0x0009,
|
|
|
|
|
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
/* device/function capabilities */
|
|
|
|
|
ice_aqc_opc_list_func_caps = 0x000A,
|
|
|
|
|
ice_aqc_opc_list_dev_caps = 0x000B,
|
|
|
|
|
|
2018-03-20 22:58:09 +08:00
|
|
|
/* manage MAC address */
|
|
|
|
|
ice_aqc_opc_manage_mac_read = 0x0107,
|
|
|
|
|
|
2018-03-20 22:58:07 +08:00
|
|
|
/* PXE */
|
|
|
|
|
ice_aqc_opc_clear_pxe_mode = 0x0110,
|
|
|
|
|
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
/* internal switch commands */
|
|
|
|
|
ice_aqc_opc_get_sw_cfg = 0x0200,
|
|
|
|
|
|
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 22:58:12 +08:00
|
|
|
/* Alloc/Free/Get Resources */
|
|
|
|
|
ice_aqc_opc_alloc_res = 0x0208,
|
|
|
|
|
ice_aqc_opc_free_res = 0x0209,
|
|
|
|
|
|
2018-03-20 22:58:11 +08:00
|
|
|
/* VSI commands */
|
|
|
|
|
ice_aqc_opc_add_vsi = 0x0210,
|
|
|
|
|
ice_aqc_opc_update_vsi = 0x0211,
|
|
|
|
|
ice_aqc_opc_free_vsi = 0x0213,
|
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 22:58:12 +08:00
|
|
|
|
|
|
|
|
/* switch rules population commands */
|
|
|
|
|
ice_aqc_opc_add_sw_rules = 0x02A0,
|
|
|
|
|
ice_aqc_opc_update_sw_rules = 0x02A1,
|
|
|
|
|
ice_aqc_opc_remove_sw_rules = 0x02A2,
|
|
|
|
|
|
2018-03-20 22:58:07 +08:00
|
|
|
ice_aqc_opc_clear_pf_cfg = 0x02A4,
|
|
|
|
|
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
/* transmit scheduler commands */
|
2018-03-20 22:58:09 +08:00
|
|
|
ice_aqc_opc_get_dflt_topo = 0x0400,
|
ice: Get switch config, scheduler config and device capabilities
This patch adds to the initialization flow by getting switch
configuration, scheduler configuration and device capabilities.
Switch configuration:
On boot, an L2 switch element is created in the firmware per physical
function. Each physical function is also mapped to a port, to which its
switch element is connected. In other words, this switch can be visualized
as an embedded vSwitch that can connect a physical function's virtual
station interfaces (VSIs) to the egress/ingress port. Egress/ingress
filters will be eventually created and applied on this switch element.
As part of the initialization flow, the driver gets configuration data
from this switch element and stores it.
Scheduler configuration:
The Tx scheduler is a subsystem responsible for setting and enforcing QoS.
As part of the initialization flow, the driver queries and stores the
default scheduler configuration for the given physical function.
Device capabilities:
As part of initialization, the driver has to determine what the device is
capable of (ex. max queues, VSIs, etc). This information is obtained from
the firmware and stored by the driver.
CC: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-03-20 22:58:08 +08:00
|
|
|
ice_aqc_opc_delete_sched_elems = 0x040F,
|
|
|
|
|
ice_aqc_opc_query_sched_res = 0x0412,
|
|
|
|
|
|
2018-03-20 22:58:09 +08:00
|
|
|
/* PHY commands */
|
|
|
|
|
ice_aqc_opc_get_phy_caps = 0x0600,
|
|
|
|
|
ice_aqc_opc_get_link_status = 0x0607,
|
|
|
|
|
|
2018-03-20 22:58:07 +08:00
|
|
|
/* NVM commands */
|
|
|
|
|
ice_aqc_opc_nvm_read = 0x0701,
|
|
|
|
|
|
2018-03-20 22:58:06 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#endif /* _ICE_ADMINQ_CMD_H_ */
|