2018-03-20 07:58:05 -07:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
# Copyright (c) 2018, Intel Corporation.
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# Makefile for the Intel(R) Ethernet Connection E800 Series Linux Driver
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
obj-$(CONFIG_ICE) += ice.o
|
|
|
|
|
|
2018-03-20 07:58:06 -07:00
|
|
|
ice-y := ice_main.o \
|
|
|
|
|
ice_controlq.o \
|
2018-03-20 07:58:07 -07:00
|
|
|
ice_common.o \
|
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 07:58:08 -07:00
|
|
|
ice_nvm.o \
|
|
|
|
|
ice_switch.o \
|
2018-03-20 07:58:13 -07:00
|
|
|
ice_sched.o \
|
2019-10-24 01:11:17 -07:00
|
|
|
ice_base.o \
|
2018-09-19 17:23:04 -07:00
|
|
|
ice_lib.o \
|
2019-11-04 09:38:56 -08:00
|
|
|
ice_txrx_lib.o \
|
2018-03-20 07:58:16 -07:00
|
|
|
ice_txrx.o \
|
2020-05-07 17:41:08 -07:00
|
|
|
ice_fltr.o \
|
2020-05-11 18:01:40 -07:00
|
|
|
ice_fdir.o \
|
|
|
|
|
ice_ethtool_fdir.o \
|
2020-01-17 07:39:12 -08:00
|
|
|
ice_flex_pipe.o \
|
|
|
|
|
ice_flow.o \
|
2020-03-11 18:58:15 -07:00
|
|
|
ice_devlink.o \
|
ice: implement device flash update via devlink
Use the newly added pldmfw library to implement device flash update for
the Intel ice networking device driver. This support uses the devlink
flash update interface.
The main parts of the flash include the Option ROM, the netlist module,
and the main NVM data. The PLDM firmware file contains modules for each
of these components.
Using the pldmfw library, the provided firmware file will be scanned for
the three major components, "fw.undi" for the Option ROM, "fw.mgmt" for
the main NVM module containing the primary device firmware, and
"fw.netlist" containing the netlist module.
The flash is separated into two banks, the active bank containing the
running firmware, and the inactive bank which we use for update. Each
module is updated in a staged process. First, the inactive bank is
erased, preparing the device for update. Second, the contents of the
component are copied to the inactive portion of the flash. After all
components are updated, the driver signals the device to switch the
active bank during the next EMP reset (which would usually occur during
the next reboot).
Although the firmware AdminQ interface does report an immediate status
for each command, the NVM erase and NVM write commands receive status
asynchronously. The driver must not continue writing until previous
erase and write commands have finished. The real status of the NVM
commands is returned over the receive AdminQ. Implement a simple
interface that uses a wait queue so that the main update thread can
sleep until the completion status is reported by firmware. For erasing
the inactive banks, this can take quite a while in practice.
To help visualize the process to the devlink application and other
applications based on the devlink netlink interface, status is reported
via the devlink_flash_update_status_notify. While we do report status
after each 4k block when writing, there is no real status we can report
during erasing. We simply must wait for the complete module erasure to
finish.
With this implementation, basic flash update for the ice hardware is
supported.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-07-23 17:22:03 -07:00
|
|
|
ice_fw_update.o \
|
2018-03-20 07:58:16 -07:00
|
|
|
ice_ethtool.o
|
2018-09-19 17:42:57 -07:00
|
|
|
ice-$(CONFIG_PCI_IOV) += ice_virtchnl_pf.o ice_sriov.o
|
2019-11-06 02:05:29 -08:00
|
|
|
ice-$(CONFIG_DCB) += ice_dcb.o ice_dcb_nl.o ice_dcb_lib.o
|
2020-05-11 18:01:46 -07:00
|
|
|
ice-$(CONFIG_RFS_ACCEL) += ice_arfs.o
|
2019-11-04 09:38:56 -08:00
|
|
|
ice-$(CONFIG_XDP_SOCKETS) += ice_xsk.o
|