2020-03-12 09:58:15 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/* Copyright (c) 2020, Intel Corporation. */
|
|
|
|
|
2021-12-29 08:49:13 +08:00
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
|
2020-03-12 09:58:15 +08:00
|
|
|
#include "ice.h"
|
2020-03-12 09:58:17 +08:00
|
|
|
#include "ice_lib.h"
|
2020-03-12 09:58:15 +08:00
|
|
|
#include "ice_devlink.h"
|
2021-08-20 08:08:48 +08:00
|
|
|
#include "ice_eswitch.h"
|
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-24 08:22:03 +08:00
|
|
|
#include "ice_fw_update.h"
|
2020-03-12 09:58:15 +08:00
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
/* context for devlink info version reporting */
|
|
|
|
struct ice_info_ctx {
|
|
|
|
char buf[128];
|
2020-11-12 08:43:30 +08:00
|
|
|
struct ice_orom_info pending_orom;
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
struct ice_nvm_info pending_nvm;
|
2020-11-12 08:43:29 +08:00
|
|
|
struct ice_netlist_info pending_netlist;
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
struct ice_hw_dev_caps dev_caps;
|
2020-11-12 08:43:24 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/* The following functions are used to format specific strings for various
|
|
|
|
* devlink info versions. The ctx parameter is used to provide the storage
|
|
|
|
* buffer, as well as any ancillary information calculated when the info
|
|
|
|
* request was made.
|
|
|
|
*
|
|
|
|
* If a version does not exist, for example when attempting to get the
|
|
|
|
* inactive version of flash when there is no pending update, the function
|
2021-08-20 23:09:50 +08:00
|
|
|
* should leave the buffer in the ctx structure empty.
|
2020-11-12 08:43:24 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
static void ice_info_get_dsn(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:17 +08:00
|
|
|
{
|
|
|
|
u8 dsn[8];
|
|
|
|
|
|
|
|
/* Copy the DSN into an array in Big Endian format */
|
|
|
|
put_unaligned_be64(pci_get_dsn(pf->pdev), dsn);
|
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%8phD", dsn);
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_pba(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:18 +08:00
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
2021-10-08 06:56:57 +08:00
|
|
|
int status;
|
2020-03-12 09:58:18 +08:00
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
status = ice_read_pba_string(hw, (u8 *)ctx->buf, sizeof(ctx->buf));
|
2020-03-12 09:58:18 +08:00
|
|
|
if (status)
|
2021-08-20 06:34:51 +08:00
|
|
|
/* We failed to locate the PBA, so just skip this entry */
|
2021-10-08 06:56:02 +08:00
|
|
|
dev_dbg(ice_pf_to_dev(pf), "Failed to read Product Board Assembly string, status %d\n",
|
|
|
|
status);
|
2020-03-12 09:58:18 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_fw_mgmt(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:17 +08:00
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%u.%u.%u",
|
|
|
|
hw->fw_maj_ver, hw->fw_min_ver, hw->fw_patch);
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_fw_api(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:17 +08:00
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
|
2021-09-28 02:21:50 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%u.%u.%u", hw->api_maj_ver,
|
|
|
|
hw->api_min_ver, hw->api_patch);
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_fw_build(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:17 +08:00
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "0x%08x", hw->fw_build);
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_orom_ver(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:17 +08:00
|
|
|
{
|
2020-10-02 01:31:41 +08:00
|
|
|
struct ice_orom_info *orom = &pf->hw.flash.orom;
|
2020-03-12 09:58:17 +08:00
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%u.%u.%u",
|
|
|
|
orom->major, orom->build, orom->patch);
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void
|
|
|
|
ice_info_pending_orom_ver(struct ice_pf __always_unused *pf,
|
|
|
|
struct ice_info_ctx *ctx)
|
2020-11-12 08:43:30 +08:00
|
|
|
{
|
|
|
|
struct ice_orom_info *orom = &ctx->pending_orom;
|
|
|
|
|
|
|
|
if (ctx->dev_caps.common_cap.nvm_update_pending_orom)
|
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%u.%u.%u",
|
|
|
|
orom->major, orom->build, orom->patch);
|
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_nvm_ver(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:17 +08:00
|
|
|
{
|
2020-10-02 01:31:41 +08:00
|
|
|
struct ice_nvm_info *nvm = &pf->hw.flash.nvm;
|
2020-03-12 09:58:17 +08:00
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%x.%02x", nvm->major, nvm->minor);
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void
|
|
|
|
ice_info_pending_nvm_ver(struct ice_pf __always_unused *pf,
|
|
|
|
struct ice_info_ctx *ctx)
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
{
|
|
|
|
struct ice_nvm_info *nvm = &ctx->pending_nvm;
|
|
|
|
|
|
|
|
if (ctx->dev_caps.common_cap.nvm_update_pending_nvm)
|
2021-08-20 23:09:50 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%x.%02x",
|
|
|
|
nvm->major, nvm->minor);
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_eetrack(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:17 +08:00
|
|
|
{
|
2020-10-02 01:31:41 +08:00
|
|
|
struct ice_nvm_info *nvm = &pf->hw.flash.nvm;
|
2020-03-12 09:58:17 +08:00
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "0x%08x", nvm->eetrack);
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void
|
|
|
|
ice_info_pending_eetrack(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
{
|
|
|
|
struct ice_nvm_info *nvm = &ctx->pending_nvm;
|
|
|
|
|
|
|
|
if (ctx->dev_caps.common_cap.nvm_update_pending_nvm)
|
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "0x%08x", nvm->eetrack);
|
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_ddp_pkg_name(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:17 +08:00
|
|
|
{
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%s", hw->active_pkg_name);
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void
|
|
|
|
ice_info_ddp_pkg_version(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-03-12 09:58:17 +08:00
|
|
|
{
|
|
|
|
struct ice_pkg_ver *pkg = &pf->hw.active_pkg_ver;
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%u.%u.%u.%u",
|
|
|
|
pkg->major, pkg->minor, pkg->update, pkg->draft);
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void
|
|
|
|
ice_info_ddp_pkg_bundle_id(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-10-08 01:54:43 +08:00
|
|
|
{
|
2020-11-12 08:43:24 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "0x%08x", pf->hw.active_track_id);
|
2020-10-08 01:54:43 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_netlist_ver(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-05-06 06:55:37 +08:00
|
|
|
{
|
2020-10-02 01:31:41 +08:00
|
|
|
struct ice_netlist_info *netlist = &pf->hw.flash.netlist;
|
2020-05-06 06:55:37 +08:00
|
|
|
|
|
|
|
/* The netlist version fields are BCD formatted */
|
2021-08-20 23:09:50 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%x.%x.%x-%x.%x.%x",
|
|
|
|
netlist->major, netlist->minor,
|
|
|
|
netlist->type >> 16, netlist->type & 0xFFFF,
|
|
|
|
netlist->rev, netlist->cust_ver);
|
2020-05-06 06:55:37 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void ice_info_netlist_build(struct ice_pf *pf, struct ice_info_ctx *ctx)
|
2020-05-06 06:55:37 +08:00
|
|
|
{
|
2020-10-02 01:31:41 +08:00
|
|
|
struct ice_netlist_info *netlist = &pf->hw.flash.netlist;
|
2020-05-06 06:55:37 +08:00
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "0x%08x", netlist->hash);
|
2020-05-06 06:55:37 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void
|
|
|
|
ice_info_pending_netlist_ver(struct ice_pf __always_unused *pf,
|
|
|
|
struct ice_info_ctx *ctx)
|
2020-11-12 08:43:29 +08:00
|
|
|
{
|
|
|
|
struct ice_netlist_info *netlist = &ctx->pending_netlist;
|
|
|
|
|
|
|
|
/* The netlist version fields are BCD formatted */
|
|
|
|
if (ctx->dev_caps.common_cap.nvm_update_pending_netlist)
|
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "%x.%x.%x-%x.%x.%x",
|
|
|
|
netlist->major, netlist->minor,
|
2021-08-20 23:09:50 +08:00
|
|
|
netlist->type >> 16, netlist->type & 0xFFFF,
|
|
|
|
netlist->rev, netlist->cust_ver);
|
2020-11-12 08:43:29 +08:00
|
|
|
}
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
static void
|
|
|
|
ice_info_pending_netlist_build(struct ice_pf __always_unused *pf,
|
|
|
|
struct ice_info_ctx *ctx)
|
2020-11-12 08:43:29 +08:00
|
|
|
{
|
|
|
|
struct ice_netlist_info *netlist = &ctx->pending_netlist;
|
|
|
|
|
|
|
|
if (ctx->dev_caps.common_cap.nvm_update_pending_netlist)
|
|
|
|
snprintf(ctx->buf, sizeof(ctx->buf), "0x%08x", netlist->hash);
|
|
|
|
}
|
|
|
|
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
#define fixed(key, getter) { ICE_VERSION_FIXED, key, getter, NULL }
|
|
|
|
#define running(key, getter) { ICE_VERSION_RUNNING, key, getter, NULL }
|
|
|
|
#define stored(key, getter, fallback) { ICE_VERSION_STORED, key, getter, fallback }
|
|
|
|
|
|
|
|
/* The combined() macro inserts both the running entry as well as a stored
|
|
|
|
* entry. The running entry will always report the version from the active
|
|
|
|
* handler. The stored entry will first try the pending handler, and fallback
|
|
|
|
* to the active handler if the pending function does not report a version.
|
|
|
|
* The pending handler should check the status of a pending update for the
|
|
|
|
* relevant flash component. It should only fill in the buffer in the case
|
|
|
|
* where a valid pending version is available. This ensures that the related
|
|
|
|
* stored and running versions remain in sync, and that stored versions are
|
|
|
|
* correctly reported as expected.
|
|
|
|
*/
|
|
|
|
#define combined(key, active, pending) \
|
|
|
|
running(key, active), \
|
|
|
|
stored(key, pending, active)
|
2020-03-12 09:58:17 +08:00
|
|
|
|
|
|
|
enum ice_version_type {
|
|
|
|
ICE_VERSION_FIXED,
|
|
|
|
ICE_VERSION_RUNNING,
|
|
|
|
ICE_VERSION_STORED,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct ice_devlink_version {
|
|
|
|
enum ice_version_type type;
|
|
|
|
const char *key;
|
2021-08-20 23:09:50 +08:00
|
|
|
void (*getter)(struct ice_pf *pf, struct ice_info_ctx *ctx);
|
|
|
|
void (*fallback)(struct ice_pf *pf, struct ice_info_ctx *ctx);
|
2020-03-12 09:58:17 +08:00
|
|
|
} ice_devlink_versions[] = {
|
2020-03-12 09:58:18 +08:00
|
|
|
fixed(DEVLINK_INFO_VERSION_GENERIC_BOARD_ID, ice_info_pba),
|
2020-03-12 09:58:17 +08:00
|
|
|
running(DEVLINK_INFO_VERSION_GENERIC_FW_MGMT, ice_info_fw_mgmt),
|
|
|
|
running("fw.mgmt.api", ice_info_fw_api),
|
|
|
|
running("fw.mgmt.build", ice_info_fw_build),
|
2020-11-12 08:43:30 +08:00
|
|
|
combined(DEVLINK_INFO_VERSION_GENERIC_FW_UNDI, ice_info_orom_ver, ice_info_pending_orom_ver),
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
combined("fw.psid.api", ice_info_nvm_ver, ice_info_pending_nvm_ver),
|
|
|
|
combined(DEVLINK_INFO_VERSION_GENERIC_FW_BUNDLE_ID, ice_info_eetrack, ice_info_pending_eetrack),
|
2020-03-12 09:58:17 +08:00
|
|
|
running("fw.app.name", ice_info_ddp_pkg_name),
|
|
|
|
running(DEVLINK_INFO_VERSION_GENERIC_FW_APP, ice_info_ddp_pkg_version),
|
2020-10-08 01:54:43 +08:00
|
|
|
running("fw.app.bundle_id", ice_info_ddp_pkg_bundle_id),
|
2020-11-12 08:43:29 +08:00
|
|
|
combined("fw.netlist", ice_info_netlist_ver, ice_info_pending_netlist_ver),
|
|
|
|
combined("fw.netlist.build", ice_info_netlist_build, ice_info_pending_netlist_build),
|
2020-03-12 09:58:17 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_devlink_info_get - .info_get devlink handler
|
|
|
|
* @devlink: devlink instance structure
|
|
|
|
* @req: the devlink info request
|
|
|
|
* @extack: extended netdev ack structure
|
|
|
|
*
|
|
|
|
* Callback for the devlink .info_get operation. Reports information about the
|
|
|
|
* device.
|
|
|
|
*
|
2020-03-12 09:58:18 +08:00
|
|
|
* Return: zero on success or an error code on failure.
|
2020-03-12 09:58:17 +08:00
|
|
|
*/
|
|
|
|
static int ice_devlink_info_get(struct devlink *devlink,
|
|
|
|
struct devlink_info_req *req,
|
|
|
|
struct netlink_ext_ack *extack)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
2020-11-12 08:43:24 +08:00
|
|
|
struct ice_info_ctx *ctx;
|
2020-03-12 09:58:17 +08:00
|
|
|
size_t i;
|
|
|
|
int err;
|
|
|
|
|
2021-05-06 23:39:59 +08:00
|
|
|
err = ice_wait_for_reset(pf, 10 * HZ);
|
|
|
|
if (err) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Device is busy resetting");
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
|
|
|
|
if (!ctx)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
/* discover capabilities first */
|
2021-10-08 07:00:23 +08:00
|
|
|
err = ice_discover_dev_caps(hw, &ctx->dev_caps);
|
|
|
|
if (err) {
|
2021-10-08 06:56:02 +08:00
|
|
|
dev_dbg(dev, "Failed to discover device capabilities, status %d aq_err %s\n",
|
2021-10-08 07:00:23 +08:00
|
|
|
err, ice_aq_str(hw->adminq.sq_last_status));
|
2021-05-06 23:39:57 +08:00
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Unable to discover device capabilities");
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
goto out_free_ctx;
|
|
|
|
}
|
|
|
|
|
2020-11-12 08:43:30 +08:00
|
|
|
if (ctx->dev_caps.common_cap.nvm_update_pending_orom) {
|
2021-10-08 07:00:23 +08:00
|
|
|
err = ice_get_inactive_orom_ver(hw, &ctx->pending_orom);
|
|
|
|
if (err) {
|
2021-10-08 06:56:02 +08:00
|
|
|
dev_dbg(dev, "Unable to read inactive Option ROM version data, status %d aq_err %s\n",
|
2021-10-08 07:00:23 +08:00
|
|
|
err, ice_aq_str(hw->adminq.sq_last_status));
|
2020-11-12 08:43:30 +08:00
|
|
|
|
|
|
|
/* disable display of pending Option ROM */
|
|
|
|
ctx->dev_caps.common_cap.nvm_update_pending_orom = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
if (ctx->dev_caps.common_cap.nvm_update_pending_nvm) {
|
2021-10-08 07:00:23 +08:00
|
|
|
err = ice_get_inactive_nvm_ver(hw, &ctx->pending_nvm);
|
|
|
|
if (err) {
|
2021-10-08 06:56:02 +08:00
|
|
|
dev_dbg(dev, "Unable to read inactive NVM version data, status %d aq_err %s\n",
|
2021-10-08 07:00:23 +08:00
|
|
|
err, ice_aq_str(hw->adminq.sq_last_status));
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
|
|
|
|
/* disable display of pending Option ROM */
|
|
|
|
ctx->dev_caps.common_cap.nvm_update_pending_nvm = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-12 08:43:29 +08:00
|
|
|
if (ctx->dev_caps.common_cap.nvm_update_pending_netlist) {
|
2021-10-08 07:00:23 +08:00
|
|
|
err = ice_get_inactive_netlist_ver(hw, &ctx->pending_netlist);
|
|
|
|
if (err) {
|
2021-10-08 06:56:02 +08:00
|
|
|
dev_dbg(dev, "Unable to read inactive Netlist version data, status %d aq_err %s\n",
|
2021-10-08 07:00:23 +08:00
|
|
|
err, ice_aq_str(hw->adminq.sq_last_status));
|
2020-11-12 08:43:29 +08:00
|
|
|
|
|
|
|
/* disable display of pending Option ROM */
|
|
|
|
ctx->dev_caps.common_cap.nvm_update_pending_netlist = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-12 09:58:17 +08:00
|
|
|
err = devlink_info_driver_name_put(req, KBUILD_MODNAME);
|
|
|
|
if (err) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Unable to set driver name");
|
2020-11-12 08:43:24 +08:00
|
|
|
goto out_free_ctx;
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
ice_info_get_dsn(pf, ctx);
|
2020-03-12 09:58:17 +08:00
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
err = devlink_info_serial_number_put(req, ctx->buf);
|
2020-03-12 09:58:17 +08:00
|
|
|
if (err) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Unable to set serial number");
|
2020-11-12 08:43:24 +08:00
|
|
|
goto out_free_ctx;
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(ice_devlink_versions); i++) {
|
|
|
|
enum ice_version_type type = ice_devlink_versions[i].type;
|
|
|
|
const char *key = ice_devlink_versions[i].key;
|
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
memset(ctx->buf, 0, sizeof(ctx->buf));
|
|
|
|
|
2021-08-20 23:09:50 +08:00
|
|
|
ice_devlink_versions[i].getter(pf, ctx);
|
2020-03-12 09:58:17 +08:00
|
|
|
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
/* If the default getter doesn't report a version, use the
|
|
|
|
* fallback function. This is primarily useful in the case of
|
|
|
|
* "stored" versions that want to report the same value as the
|
|
|
|
* running version in the normal case of no pending update.
|
|
|
|
*/
|
2021-08-20 23:09:50 +08:00
|
|
|
if (ctx->buf[0] == '\0' && ice_devlink_versions[i].fallback)
|
|
|
|
ice_devlink_versions[i].fallback(pf, ctx);
|
ice: display some stored NVM versions via devlink info
The devlink info interface supports drivers reporting "stored" versions.
These versions indicate the version of an update that has been
downloaded to the device, but is not yet active.
The code for extracting the NVM version recently changed to enable
support for reading from either the active or the inactive bank. Use
this to implement ice_get_inactive_nvm_ver, which will read the NVM
version data from the inactive section of flash.
When reporting the versions via devlink info, first read the device
capabilities. Determine if there is a pending flash update, and if so,
extract relevant version information from the inactive flash. Store
these within the info context structure.
When reporting "stored" firmware versions, devlink documentation
indicates that we ought to always report a stored value, even if there
is no pending update. In this common case, the stored version should
match the running version. This means that each stored version should by
default fallback to the same value as reported by the running handler.
To support this, modify the version structure to have both a "getter"
and a "fallback". Modify the control loop so that it will use the
"fallback" function if the "getter" function does not report a version.
To report versions for which we can read the stored value, use a new
"stored()" macro. This macro will insert two entries into the version
list. The first entry is the traditional running version. The second is
the stored version, implemented with a fallback to the active version.
This is a little tricky, but reduces the overall duplication of elements
in the entry list, and ensures that running and stored values remain
consistent.
To avoid some duplication, add a combined() macro that will insert both
the running and stored versions into the version entry list.
Using this new support, add pending version reporter functions for
"fw.psid.api" and "fw.bundle_id". This enables reporting the stored
values for some of versions in the NVM module of the flash.
Reporting management versions is not implemented by this patch. The
active management version is reported to the driver via the AdminQ
mailbox during load. Although the version must be in the firmware binary
somewhere, accessing this from the inactive firmware is not trivial and
has not been implemented in this change.
Future changes will introduce support for reading the UNDI Option ROM
version and the version associated with the Netlist module.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2020-11-12 08:43:28 +08:00
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
/* Do not report missing versions */
|
|
|
|
if (ctx->buf[0] == '\0')
|
|
|
|
continue;
|
|
|
|
|
2020-03-12 09:58:17 +08:00
|
|
|
switch (type) {
|
|
|
|
case ICE_VERSION_FIXED:
|
2020-11-12 08:43:24 +08:00
|
|
|
err = devlink_info_version_fixed_put(req, key, ctx->buf);
|
2020-03-12 09:58:17 +08:00
|
|
|
if (err) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Unable to set fixed version");
|
2020-11-12 08:43:24 +08:00
|
|
|
goto out_free_ctx;
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case ICE_VERSION_RUNNING:
|
2020-11-12 08:43:24 +08:00
|
|
|
err = devlink_info_version_running_put(req, key, ctx->buf);
|
2020-03-12 09:58:17 +08:00
|
|
|
if (err) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Unable to set running version");
|
2020-11-12 08:43:24 +08:00
|
|
|
goto out_free_ctx;
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case ICE_VERSION_STORED:
|
2020-11-12 08:43:24 +08:00
|
|
|
err = devlink_info_version_stored_put(req, key, ctx->buf);
|
2020-03-12 09:58:17 +08:00
|
|
|
if (err) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Unable to set stored version");
|
2020-11-12 08:43:24 +08:00
|
|
|
goto out_free_ctx;
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-11-12 08:43:24 +08:00
|
|
|
out_free_ctx:
|
|
|
|
kfree(ctx);
|
|
|
|
return err;
|
2020-03-12 09:58:17 +08:00
|
|
|
}
|
|
|
|
|
ice: support immediate firmware activation via devlink reload
The ice hardware contains an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).
Activating the new firmware image currently requires that the system be
rebooted. This is not ideal as rebooting the system can cause unwanted
downtime.
In practical terms, activating the firmware does not always require a
full system reboot. In many cases it is possible to activate the EMP
firmware immediately. There are a couple of different scenarios to
cover.
* The EMP firmware itself can be reloaded by issuing a special update
to the device called an Embedded Management Processor reset (EMP
reset). This reset causes the device to reset and reload the EMP
firmware.
* PCI configuration changes are only reloaded after a cold PCIe reset.
Unfortunately there is no generic way to trigger this for a PCIe
device without a system reboot.
When performing a flash update, firmware is capable of responding with
some information about the specific update requirements.
The driver updates the flash by programming a secondary inactive bank
with the contents of the new image, and then issuing a command to
request to switch the active bank starting from the next load.
The response to the final command for updating the inactive NVM flash
bank includes an indication of the minimum reset required to fully
update the device. This can be one of the following:
* A full power on is required
* A cold PCIe reset is required
* An EMP reset is required
The response to the command to switch flash banks includes an indication
of whether or not the firmware will allow an EMP reset request.
For most updates, an EMP reset is sufficient to load the new EMP
firmware without issues. In some cases, this reset is not sufficient
because the PCI configuration space has changed. When this could cause
incompatibility with the new EMP image, the firmware is capable of
rejecting the EMP reset request.
Add logic to ice_fw_update.c to handle the response data flash update
AdminQ commands.
For the reset level, issue a devlink status notification informing the
user of how to complete the update with a simple suggestion like
"Activate new firmware by rebooting the system".
Cache the status of whether or not firmware will restrict the EMP reset
for use in implementing devlink reload.
Implement support for devlink reload with the "fw_activate" flag. This
allows user space to request the firmware be activated immediately.
For the .reload_down handler, we will issue a request for the EMP reset
using the appropriate firmware AdminQ command. If we know that the
firmware will not allow an EMP reset, simply exit with a suitable
netlink extended ACK message indicating that the EMP reset is not
available.
For the .reload_up handler, simply wait until the driver has finished
resetting. Logic to handle processing of an EMP reset already exists in
the driver as part of its reset and rebuild flows.
Implement support for the devlink reload interface with the
"fw_activate" action. This allows userspace to request activation of
firmware without a reboot.
Note that support for indicating the required reset and EMP reset
restriction is not supported on old versions of firmware. The driver can
determine if the two features are supported by checking the device
capabilities report. I confirmed support has existed since at least
version 5.5.2 as reported by the 'fw.mgmt' version. Support to issue the
EMP reset request has existed in all version of the EMP firmware for the
ice hardware.
Check the device capabilities report to determine whether or not the
indications are reported by the running firmware. If the reset
requirement indication is not supported, always assume a full power on
is necessary. If the reset restriction capability is not supported,
always assume the EMP reset is available.
Users can verify if the EMP reset has activated the firmware by using
the devlink info report to check that the 'running' firmware version has
updated. For example a user might do the following:
# Check current version
$ devlink dev info
# Update the device
$ devlink dev flash pci/0000:af:00.0 file firmware.bin
# Confirm stored version updated
$ devlink dev info
# Reload to activate new firmware
$ devlink dev reload pci/0000:af:00.0 action fw_activate
# Confirm running version updated
$ devlink dev info
Finally, this change does *not* implement basic driver-only reload
support. I did look into trying to do this. However, it requires
significant refactor of how the ice driver probes and loads everything.
The ice driver probe and allocation flows were not designed with such
a reload in mind. Refactoring the flow to support this is beyond the
scope of this change.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-28 07:22:55 +08:00
|
|
|
/**
|
|
|
|
* ice_devlink_reload_empr_start - Start EMP reset to activate new firmware
|
|
|
|
* @devlink: pointer to the devlink instance to reload
|
|
|
|
* @netns_change: if true, the network namespace is changing
|
|
|
|
* @action: the action to perform. Must be DEVLINK_RELOAD_ACTION_FW_ACTIVATE
|
|
|
|
* @limit: limits on what reload should do, such as not resetting
|
|
|
|
* @extack: netlink extended ACK structure
|
|
|
|
*
|
|
|
|
* Allow user to activate new Embedded Management Processor firmware by
|
|
|
|
* issuing device specific EMP reset. Called in response to
|
|
|
|
* a DEVLINK_CMD_RELOAD with the DEVLINK_RELOAD_ACTION_FW_ACTIVATE.
|
|
|
|
*
|
|
|
|
* Note that teardown and rebuild of the driver state happens automatically as
|
|
|
|
* part of an interrupt and watchdog task. This is because all physical
|
|
|
|
* functions on the device must be able to reset when an EMP reset occurs from
|
|
|
|
* any source.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_devlink_reload_empr_start(struct devlink *devlink, bool netns_change,
|
|
|
|
enum devlink_reload_action action,
|
|
|
|
enum devlink_reload_limit limit,
|
|
|
|
struct netlink_ext_ack *extack)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u8 pending;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = ice_get_pending_updates(pf, &pending, extack);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
/* pending is a bitmask of which flash banks have a pending update,
|
|
|
|
* including the main NVM bank, the Option ROM bank, and the netlist
|
|
|
|
* bank. If any of these bits are set, then there is a pending update
|
|
|
|
* waiting to be activated.
|
|
|
|
*/
|
|
|
|
if (!pending) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "No pending firmware update");
|
|
|
|
return -ECANCELED;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (pf->fw_emp_reset_disabled) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "EMP reset is not available. To activate firmware, a reboot or power cycle is needed");
|
|
|
|
return -ECANCELED;
|
|
|
|
}
|
|
|
|
|
|
|
|
dev_dbg(dev, "Issuing device EMP reset to activate firmware\n");
|
|
|
|
|
|
|
|
err = ice_aq_nvm_update_empr(hw);
|
|
|
|
if (err) {
|
|
|
|
dev_err(dev, "Failed to trigger EMP device reset to reload firmware, err %d aq_err %s\n",
|
|
|
|
err, ice_aq_str(hw->adminq.sq_last_status));
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Failed to trigger EMP device reset to reload firmware");
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_devlink_reload_empr_finish - Wait for EMP reset to finish
|
|
|
|
* @devlink: pointer to the devlink instance reloading
|
|
|
|
* @action: the action requested
|
|
|
|
* @limit: limits imposed by userspace, such as not resetting
|
|
|
|
* @actions_performed: on return, indicate what actions actually performed
|
|
|
|
* @extack: netlink extended ACK structure
|
|
|
|
*
|
|
|
|
* Wait for driver to finish rebuilding after EMP reset is completed. This
|
|
|
|
* includes time to wait for both the actual device reset as well as the time
|
|
|
|
* for the driver's rebuild to complete.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_devlink_reload_empr_finish(struct devlink *devlink,
|
|
|
|
enum devlink_reload_action action,
|
|
|
|
enum devlink_reload_limit limit,
|
|
|
|
u32 *actions_performed,
|
|
|
|
struct netlink_ext_ack *extack)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
int err;
|
|
|
|
|
|
|
|
*actions_performed = BIT(DEVLINK_RELOAD_ACTION_FW_ACTIVATE);
|
|
|
|
|
|
|
|
err = ice_wait_for_reset(pf, 60 * HZ);
|
|
|
|
if (err) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Device still resetting after 1 minute");
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-12 09:58:15 +08:00
|
|
|
static const struct devlink_ops ice_devlink_ops = {
|
2020-09-26 04:46:09 +08:00
|
|
|
.supported_flash_update_params = DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK,
|
ice: support immediate firmware activation via devlink reload
The ice hardware contains an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).
Activating the new firmware image currently requires that the system be
rebooted. This is not ideal as rebooting the system can cause unwanted
downtime.
In practical terms, activating the firmware does not always require a
full system reboot. In many cases it is possible to activate the EMP
firmware immediately. There are a couple of different scenarios to
cover.
* The EMP firmware itself can be reloaded by issuing a special update
to the device called an Embedded Management Processor reset (EMP
reset). This reset causes the device to reset and reload the EMP
firmware.
* PCI configuration changes are only reloaded after a cold PCIe reset.
Unfortunately there is no generic way to trigger this for a PCIe
device without a system reboot.
When performing a flash update, firmware is capable of responding with
some information about the specific update requirements.
The driver updates the flash by programming a secondary inactive bank
with the contents of the new image, and then issuing a command to
request to switch the active bank starting from the next load.
The response to the final command for updating the inactive NVM flash
bank includes an indication of the minimum reset required to fully
update the device. This can be one of the following:
* A full power on is required
* A cold PCIe reset is required
* An EMP reset is required
The response to the command to switch flash banks includes an indication
of whether or not the firmware will allow an EMP reset request.
For most updates, an EMP reset is sufficient to load the new EMP
firmware without issues. In some cases, this reset is not sufficient
because the PCI configuration space has changed. When this could cause
incompatibility with the new EMP image, the firmware is capable of
rejecting the EMP reset request.
Add logic to ice_fw_update.c to handle the response data flash update
AdminQ commands.
For the reset level, issue a devlink status notification informing the
user of how to complete the update with a simple suggestion like
"Activate new firmware by rebooting the system".
Cache the status of whether or not firmware will restrict the EMP reset
for use in implementing devlink reload.
Implement support for devlink reload with the "fw_activate" flag. This
allows user space to request the firmware be activated immediately.
For the .reload_down handler, we will issue a request for the EMP reset
using the appropriate firmware AdminQ command. If we know that the
firmware will not allow an EMP reset, simply exit with a suitable
netlink extended ACK message indicating that the EMP reset is not
available.
For the .reload_up handler, simply wait until the driver has finished
resetting. Logic to handle processing of an EMP reset already exists in
the driver as part of its reset and rebuild flows.
Implement support for the devlink reload interface with the
"fw_activate" action. This allows userspace to request activation of
firmware without a reboot.
Note that support for indicating the required reset and EMP reset
restriction is not supported on old versions of firmware. The driver can
determine if the two features are supported by checking the device
capabilities report. I confirmed support has existed since at least
version 5.5.2 as reported by the 'fw.mgmt' version. Support to issue the
EMP reset request has existed in all version of the EMP firmware for the
ice hardware.
Check the device capabilities report to determine whether or not the
indications are reported by the running firmware. If the reset
requirement indication is not supported, always assume a full power on
is necessary. If the reset restriction capability is not supported,
always assume the EMP reset is available.
Users can verify if the EMP reset has activated the firmware by using
the devlink info report to check that the 'running' firmware version has
updated. For example a user might do the following:
# Check current version
$ devlink dev info
# Update the device
$ devlink dev flash pci/0000:af:00.0 file firmware.bin
# Confirm stored version updated
$ devlink dev info
# Reload to activate new firmware
$ devlink dev reload pci/0000:af:00.0 action fw_activate
# Confirm running version updated
$ devlink dev info
Finally, this change does *not* implement basic driver-only reload
support. I did look into trying to do this. However, it requires
significant refactor of how the ice driver probes and loads everything.
The ice driver probe and allocation flows were not designed with such
a reload in mind. Refactoring the flow to support this is beyond the
scope of this change.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-28 07:22:55 +08:00
|
|
|
.reload_actions = BIT(DEVLINK_RELOAD_ACTION_FW_ACTIVATE),
|
|
|
|
/* The ice driver currently does not support driver reinit */
|
|
|
|
.reload_down = ice_devlink_reload_empr_start,
|
|
|
|
.reload_up = ice_devlink_reload_empr_finish,
|
2021-08-20 08:08:48 +08:00
|
|
|
.eswitch_mode_get = ice_eswitch_mode_get,
|
|
|
|
.eswitch_mode_set = ice_eswitch_mode_set,
|
2020-03-12 09:58:17 +08:00
|
|
|
.info_get = ice_devlink_info_get,
|
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-24 08:22:03 +08:00
|
|
|
.flash_update = ice_devlink_flash_update,
|
2020-03-12 09:58:15 +08:00
|
|
|
};
|
|
|
|
|
2021-10-19 07:16:02 +08:00
|
|
|
static int
|
|
|
|
ice_devlink_enable_roce_get(struct devlink *devlink, u32 id,
|
|
|
|
struct devlink_param_gset_ctx *ctx)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
|
2021-11-24 20:41:35 +08:00
|
|
|
ctx->val.vbool = pf->rdma_mode & IIDC_RDMA_PROTOCOL_ROCEV2 ? true : false;
|
2021-10-19 07:16:02 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
ice_devlink_enable_roce_set(struct devlink *devlink, u32 id,
|
|
|
|
struct devlink_param_gset_ctx *ctx)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
bool roce_ena = ctx->val.vbool;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!roce_ena) {
|
|
|
|
ice_unplug_aux_dev(pf);
|
|
|
|
pf->rdma_mode &= ~IIDC_RDMA_PROTOCOL_ROCEV2;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
pf->rdma_mode |= IIDC_RDMA_PROTOCOL_ROCEV2;
|
|
|
|
ret = ice_plug_aux_dev(pf);
|
|
|
|
if (ret)
|
|
|
|
pf->rdma_mode &= ~IIDC_RDMA_PROTOCOL_ROCEV2;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
ice_devlink_enable_roce_validate(struct devlink *devlink, u32 id,
|
|
|
|
union devlink_param_value val,
|
|
|
|
struct netlink_ext_ack *extack)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
|
|
|
|
if (!test_bit(ICE_FLAG_RDMA_ENA, pf->flags))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
if (pf->rdma_mode & IIDC_RDMA_PROTOCOL_IWARP) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "iWARP is currently enabled. This device cannot enable iWARP and RoCEv2 simultaneously");
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
ice_devlink_enable_iw_get(struct devlink *devlink, u32 id,
|
|
|
|
struct devlink_param_gset_ctx *ctx)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
|
|
|
|
ctx->val.vbool = pf->rdma_mode & IIDC_RDMA_PROTOCOL_IWARP;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
ice_devlink_enable_iw_set(struct devlink *devlink, u32 id,
|
|
|
|
struct devlink_param_gset_ctx *ctx)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
bool iw_ena = ctx->val.vbool;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!iw_ena) {
|
|
|
|
ice_unplug_aux_dev(pf);
|
|
|
|
pf->rdma_mode &= ~IIDC_RDMA_PROTOCOL_IWARP;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
pf->rdma_mode |= IIDC_RDMA_PROTOCOL_IWARP;
|
|
|
|
ret = ice_plug_aux_dev(pf);
|
|
|
|
if (ret)
|
|
|
|
pf->rdma_mode &= ~IIDC_RDMA_PROTOCOL_IWARP;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
ice_devlink_enable_iw_validate(struct devlink *devlink, u32 id,
|
|
|
|
union devlink_param_value val,
|
|
|
|
struct netlink_ext_ack *extack)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
|
|
|
|
if (!test_bit(ICE_FLAG_RDMA_ENA, pf->flags))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
if (pf->rdma_mode & IIDC_RDMA_PROTOCOL_ROCEV2) {
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "RoCEv2 is currently enabled. This device cannot enable iWARP and RoCEv2 simultaneously");
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct devlink_param ice_devlink_params[] = {
|
|
|
|
DEVLINK_PARAM_GENERIC(ENABLE_ROCE, BIT(DEVLINK_PARAM_CMODE_RUNTIME),
|
|
|
|
ice_devlink_enable_roce_get,
|
|
|
|
ice_devlink_enable_roce_set,
|
|
|
|
ice_devlink_enable_roce_validate),
|
|
|
|
DEVLINK_PARAM_GENERIC(ENABLE_IWARP, BIT(DEVLINK_PARAM_CMODE_RUNTIME),
|
|
|
|
ice_devlink_enable_iw_get,
|
|
|
|
ice_devlink_enable_iw_set,
|
|
|
|
ice_devlink_enable_iw_validate),
|
|
|
|
|
|
|
|
};
|
|
|
|
|
2020-03-12 09:58:15 +08:00
|
|
|
static void ice_devlink_free(void *devlink_ptr)
|
|
|
|
{
|
|
|
|
devlink_free((struct devlink *)devlink_ptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_allocate_pf - Allocate devlink and return PF structure pointer
|
|
|
|
* @dev: the device to allocate for
|
|
|
|
*
|
|
|
|
* Allocate a devlink instance for this device and return the private area as
|
|
|
|
* the PF structure. The devlink memory is kept track of through devres by
|
|
|
|
* adding an action to remove it when unwinding.
|
|
|
|
*/
|
|
|
|
struct ice_pf *ice_allocate_pf(struct device *dev)
|
|
|
|
{
|
|
|
|
struct devlink *devlink;
|
|
|
|
|
2021-08-09 02:57:43 +08:00
|
|
|
devlink = devlink_alloc(&ice_devlink_ops, sizeof(struct ice_pf), dev);
|
2020-03-12 09:58:15 +08:00
|
|
|
if (!devlink)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* Add an action to teardown the devlink when unwinding the driver */
|
2021-09-22 20:59:46 +08:00
|
|
|
if (devm_add_action_or_reset(dev, ice_devlink_free, devlink))
|
2020-03-12 09:58:15 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return devlink_priv(devlink);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_devlink_register - Register devlink interface for this PF
|
|
|
|
* @pf: the PF to register the devlink for.
|
|
|
|
*
|
|
|
|
* Register the devlink instance associated with this physical function.
|
|
|
|
*
|
|
|
|
* Return: zero on success or an error code on failure.
|
|
|
|
*/
|
2021-09-22 16:58:03 +08:00
|
|
|
void ice_devlink_register(struct ice_pf *pf)
|
2020-03-12 09:58:15 +08:00
|
|
|
{
|
|
|
|
struct devlink *devlink = priv_to_devlink(pf);
|
|
|
|
|
ice: support immediate firmware activation via devlink reload
The ice hardware contains an embedded chip with firmware which can be
updated using devlink flash. The firmware which runs on this chip is
referred to as the Embedded Management Processor firmware (EMP
firmware).
Activating the new firmware image currently requires that the system be
rebooted. This is not ideal as rebooting the system can cause unwanted
downtime.
In practical terms, activating the firmware does not always require a
full system reboot. In many cases it is possible to activate the EMP
firmware immediately. There are a couple of different scenarios to
cover.
* The EMP firmware itself can be reloaded by issuing a special update
to the device called an Embedded Management Processor reset (EMP
reset). This reset causes the device to reset and reload the EMP
firmware.
* PCI configuration changes are only reloaded after a cold PCIe reset.
Unfortunately there is no generic way to trigger this for a PCIe
device without a system reboot.
When performing a flash update, firmware is capable of responding with
some information about the specific update requirements.
The driver updates the flash by programming a secondary inactive bank
with the contents of the new image, and then issuing a command to
request to switch the active bank starting from the next load.
The response to the final command for updating the inactive NVM flash
bank includes an indication of the minimum reset required to fully
update the device. This can be one of the following:
* A full power on is required
* A cold PCIe reset is required
* An EMP reset is required
The response to the command to switch flash banks includes an indication
of whether or not the firmware will allow an EMP reset request.
For most updates, an EMP reset is sufficient to load the new EMP
firmware without issues. In some cases, this reset is not sufficient
because the PCI configuration space has changed. When this could cause
incompatibility with the new EMP image, the firmware is capable of
rejecting the EMP reset request.
Add logic to ice_fw_update.c to handle the response data flash update
AdminQ commands.
For the reset level, issue a devlink status notification informing the
user of how to complete the update with a simple suggestion like
"Activate new firmware by rebooting the system".
Cache the status of whether or not firmware will restrict the EMP reset
for use in implementing devlink reload.
Implement support for devlink reload with the "fw_activate" flag. This
allows user space to request the firmware be activated immediately.
For the .reload_down handler, we will issue a request for the EMP reset
using the appropriate firmware AdminQ command. If we know that the
firmware will not allow an EMP reset, simply exit with a suitable
netlink extended ACK message indicating that the EMP reset is not
available.
For the .reload_up handler, simply wait until the driver has finished
resetting. Logic to handle processing of an EMP reset already exists in
the driver as part of its reset and rebuild flows.
Implement support for the devlink reload interface with the
"fw_activate" action. This allows userspace to request activation of
firmware without a reboot.
Note that support for indicating the required reset and EMP reset
restriction is not supported on old versions of firmware. The driver can
determine if the two features are supported by checking the device
capabilities report. I confirmed support has existed since at least
version 5.5.2 as reported by the 'fw.mgmt' version. Support to issue the
EMP reset request has existed in all version of the EMP firmware for the
ice hardware.
Check the device capabilities report to determine whether or not the
indications are reported by the running firmware. If the reset
requirement indication is not supported, always assume a full power on
is necessary. If the reset restriction capability is not supported,
always assume the EMP reset is available.
Users can verify if the EMP reset has activated the firmware by using
the devlink info report to check that the 'running' firmware version has
updated. For example a user might do the following:
# Check current version
$ devlink dev info
# Update the device
$ devlink dev flash pci/0000:af:00.0 file firmware.bin
# Confirm stored version updated
$ devlink dev info
# Reload to activate new firmware
$ devlink dev reload pci/0000:af:00.0 action fw_activate
# Confirm running version updated
$ devlink dev info
Finally, this change does *not* implement basic driver-only reload
support. I did look into trying to do this. However, it requires
significant refactor of how the ice driver probes and loads everything.
The ice driver probe and allocation flows were not designed with such
a reload in mind. Refactoring the flow to support this is beyond the
scope of this change.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-10-28 07:22:55 +08:00
|
|
|
devlink_set_features(devlink, DEVLINK_F_RELOAD);
|
2021-09-22 16:58:03 +08:00
|
|
|
devlink_register(devlink);
|
2020-03-12 09:58:15 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_devlink_unregister - Unregister devlink resources for this PF.
|
|
|
|
* @pf: the PF structure to cleanup
|
|
|
|
*
|
|
|
|
* Releases resources used by devlink and cleans up associated memory.
|
|
|
|
*/
|
|
|
|
void ice_devlink_unregister(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
devlink_unregister(priv_to_devlink(pf));
|
|
|
|
}
|
|
|
|
|
2021-10-19 07:16:02 +08:00
|
|
|
int ice_devlink_register_params(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct devlink *devlink = priv_to_devlink(pf);
|
|
|
|
union devlink_param_value value;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = devlink_params_register(devlink, ice_devlink_params,
|
|
|
|
ARRAY_SIZE(ice_devlink_params));
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
value.vbool = false;
|
|
|
|
devlink_param_driverinit_value_set(devlink,
|
|
|
|
DEVLINK_PARAM_GENERIC_ID_ENABLE_IWARP,
|
|
|
|
value);
|
|
|
|
|
|
|
|
value.vbool = test_bit(ICE_FLAG_RDMA_ENA, pf->flags) ? true : false;
|
|
|
|
devlink_param_driverinit_value_set(devlink,
|
|
|
|
DEVLINK_PARAM_GENERIC_ID_ENABLE_ROCE,
|
|
|
|
value);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ice_devlink_unregister_params(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
devlink_params_unregister(priv_to_devlink(pf), ice_devlink_params,
|
|
|
|
ARRAY_SIZE(ice_devlink_params));
|
|
|
|
}
|
|
|
|
|
2020-03-12 09:58:15 +08:00
|
|
|
/**
|
2021-08-20 08:08:49 +08:00
|
|
|
* ice_devlink_create_pf_port - Create a devlink port for this PF
|
|
|
|
* @pf: the PF to create a devlink port for
|
2020-03-12 09:58:15 +08:00
|
|
|
*
|
2021-08-20 08:08:49 +08:00
|
|
|
* Create and register a devlink_port for this PF.
|
2020-03-12 09:58:15 +08:00
|
|
|
*
|
|
|
|
* Return: zero on success or an error code on failure.
|
|
|
|
*/
|
2021-08-20 08:08:49 +08:00
|
|
|
int ice_devlink_create_pf_port(struct ice_pf *pf)
|
2020-03-12 09:58:15 +08:00
|
|
|
{
|
2020-07-09 21:18:16 +08:00
|
|
|
struct devlink_port_attrs attrs = {};
|
2021-08-20 08:08:49 +08:00
|
|
|
struct devlink_port *devlink_port;
|
ice: refactor devlink_port to be per-VSI
Currently, the devlink_port structure is stored within the ice_pf. This
made sense because we create a single devlink_port for each PF. This
setup does not mesh with the abstractions in the driver very well, and
led to a flow where we accidentally call devlink_port_unregister twice
during error cleanup.
In particular, if devlink_port_register or devlink_port_unregister are
called twice, this leads to a kernel panic. This appears to occur during
some possible flows while cleaning up from a failure during driver
probe.
If register_netdev fails, then we will call devlink_port_unregister in
ice_cfg_netdev as it cleans up. Later, we again call
devlink_port_unregister since we assume that we must cleanup the port
that is associated with the PF structure.
This occurs because we cleanup the devlink_port for the main PF even
though it was not allocated. We allocated the port within a per-VSI
function for managing the main netdev, but did not release the port when
cleaning up that VSI, the allocation and destruction are not aligned.
Instead of attempting to manage the devlink_port as part of the PF
structure, manage it as part of the PF VSI. Doing this has advantages,
as we can match the de-allocation of the devlink_port with the
unregister_netdev associated with the main PF VSI.
Moving the port to the VSI is preferable as it paves the way for
handling devlink ports allocated for other purposes such as SR-IOV VFs.
Since we're changing up how we allocate the devlink_port, also change
the indexing. Originally, we indexed the port using the PF id number.
This came from an old goal of sharing a devlink for each physical
function. Managing devlink instances across multiple function drivers is
not workable. Instead, lets set the port number to the logical port
number returned by firmware and set the index using the VSI index
(sometimes referred to as VSI handle).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-08 01:54:44 +08:00
|
|
|
struct devlink *devlink;
|
2021-08-20 08:08:49 +08:00
|
|
|
struct ice_vsi *vsi;
|
ice: refactor devlink_port to be per-VSI
Currently, the devlink_port structure is stored within the ice_pf. This
made sense because we create a single devlink_port for each PF. This
setup does not mesh with the abstractions in the driver very well, and
led to a flow where we accidentally call devlink_port_unregister twice
during error cleanup.
In particular, if devlink_port_register or devlink_port_unregister are
called twice, this leads to a kernel panic. This appears to occur during
some possible flows while cleaning up from a failure during driver
probe.
If register_netdev fails, then we will call devlink_port_unregister in
ice_cfg_netdev as it cleans up. Later, we again call
devlink_port_unregister since we assume that we must cleanup the port
that is associated with the PF structure.
This occurs because we cleanup the devlink_port for the main PF even
though it was not allocated. We allocated the port within a per-VSI
function for managing the main netdev, but did not release the port when
cleaning up that VSI, the allocation and destruction are not aligned.
Instead of attempting to manage the devlink_port as part of the PF
structure, manage it as part of the PF VSI. Doing this has advantages,
as we can match the de-allocation of the devlink_port with the
unregister_netdev associated with the main PF VSI.
Moving the port to the VSI is preferable as it paves the way for
handling devlink ports allocated for other purposes such as SR-IOV VFs.
Since we're changing up how we allocate the devlink_port, also change
the indexing. Originally, we indexed the port using the PF id number.
This came from an old goal of sharing a devlink for each physical
function. Managing devlink instances across multiple function drivers is
not workable. Instead, lets set the port number to the logical port
number returned by firmware and set the index using the VSI index
(sometimes referred to as VSI handle).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-08 01:54:44 +08:00
|
|
|
struct device *dev;
|
2020-03-12 09:58:15 +08:00
|
|
|
int err;
|
|
|
|
|
ice: refactor devlink_port to be per-VSI
Currently, the devlink_port structure is stored within the ice_pf. This
made sense because we create a single devlink_port for each PF. This
setup does not mesh with the abstractions in the driver very well, and
led to a flow where we accidentally call devlink_port_unregister twice
during error cleanup.
In particular, if devlink_port_register or devlink_port_unregister are
called twice, this leads to a kernel panic. This appears to occur during
some possible flows while cleaning up from a failure during driver
probe.
If register_netdev fails, then we will call devlink_port_unregister in
ice_cfg_netdev as it cleans up. Later, we again call
devlink_port_unregister since we assume that we must cleanup the port
that is associated with the PF structure.
This occurs because we cleanup the devlink_port for the main PF even
though it was not allocated. We allocated the port within a per-VSI
function for managing the main netdev, but did not release the port when
cleaning up that VSI, the allocation and destruction are not aligned.
Instead of attempting to manage the devlink_port as part of the PF
structure, manage it as part of the PF VSI. Doing this has advantages,
as we can match the de-allocation of the devlink_port with the
unregister_netdev associated with the main PF VSI.
Moving the port to the VSI is preferable as it paves the way for
handling devlink ports allocated for other purposes such as SR-IOV VFs.
Since we're changing up how we allocate the devlink_port, also change
the indexing. Originally, we indexed the port using the PF id number.
This came from an old goal of sharing a devlink for each physical
function. Managing devlink instances across multiple function drivers is
not workable. Instead, lets set the port number to the logical port
number returned by firmware and set the index using the VSI index
(sometimes referred to as VSI handle).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-08 01:54:44 +08:00
|
|
|
dev = ice_pf_to_dev(pf);
|
2021-08-20 08:08:49 +08:00
|
|
|
|
|
|
|
devlink_port = &pf->devlink_port;
|
|
|
|
|
|
|
|
vsi = ice_get_main_vsi(pf);
|
|
|
|
if (!vsi)
|
|
|
|
return -EIO;
|
2020-03-12 09:58:15 +08:00
|
|
|
|
2020-07-09 21:18:16 +08:00
|
|
|
attrs.flavour = DEVLINK_PORT_FLAVOUR_PHYSICAL;
|
2021-08-20 08:08:49 +08:00
|
|
|
attrs.phys.port_number = pf->hw.bus.func;
|
|
|
|
devlink_port_attrs_set(devlink_port, &attrs);
|
|
|
|
devlink = priv_to_devlink(pf);
|
|
|
|
|
|
|
|
err = devlink_port_register(devlink, devlink_port, vsi->idx);
|
2020-03-12 09:58:15 +08:00
|
|
|
if (err) {
|
2021-08-20 08:08:49 +08:00
|
|
|
dev_err(dev, "Failed to create devlink port for PF %d, error %d\n",
|
|
|
|
pf->hw.pf_id, err);
|
2020-03-12 09:58:15 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2021-08-20 08:08:49 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_devlink_destroy_pf_port - Destroy the devlink_port for this PF
|
|
|
|
* @pf: the PF to cleanup
|
|
|
|
*
|
|
|
|
* Unregisters the devlink_port structure associated with this PF.
|
|
|
|
*/
|
|
|
|
void ice_devlink_destroy_pf_port(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct devlink_port *devlink_port;
|
|
|
|
|
|
|
|
devlink_port = &pf->devlink_port;
|
|
|
|
|
|
|
|
devlink_port_type_clear(devlink_port);
|
|
|
|
devlink_port_unregister(devlink_port);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_devlink_create_vf_port - Create a devlink port for this VF
|
|
|
|
* @vf: the VF to create a port for
|
|
|
|
*
|
|
|
|
* Create and register a devlink_port for this VF.
|
|
|
|
*
|
|
|
|
* Return: zero on success or an error code on failure.
|
|
|
|
*/
|
|
|
|
int ice_devlink_create_vf_port(struct ice_vf *vf)
|
|
|
|
{
|
|
|
|
struct devlink_port_attrs attrs = {};
|
|
|
|
struct devlink_port *devlink_port;
|
|
|
|
struct devlink *devlink;
|
|
|
|
struct ice_vsi *vsi;
|
|
|
|
struct device *dev;
|
|
|
|
struct ice_pf *pf;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
pf = vf->pf;
|
|
|
|
dev = ice_pf_to_dev(pf);
|
|
|
|
vsi = ice_get_vf_vsi(vf);
|
|
|
|
devlink_port = &vf->devlink_port;
|
|
|
|
|
|
|
|
attrs.flavour = DEVLINK_PORT_FLAVOUR_PCI_VF;
|
|
|
|
attrs.pci_vf.pf = pf->hw.bus.func;
|
|
|
|
attrs.pci_vf.vf = vf->vf_id;
|
|
|
|
|
|
|
|
devlink_port_attrs_set(devlink_port, &attrs);
|
|
|
|
devlink = priv_to_devlink(pf);
|
|
|
|
|
|
|
|
err = devlink_port_register(devlink, devlink_port, vsi->idx);
|
|
|
|
if (err) {
|
|
|
|
dev_err(dev, "Failed to create devlink port for VF %d, error %d\n",
|
|
|
|
vf->vf_id, err);
|
|
|
|
return err;
|
|
|
|
}
|
ice: refactor devlink_port to be per-VSI
Currently, the devlink_port structure is stored within the ice_pf. This
made sense because we create a single devlink_port for each PF. This
setup does not mesh with the abstractions in the driver very well, and
led to a flow where we accidentally call devlink_port_unregister twice
during error cleanup.
In particular, if devlink_port_register or devlink_port_unregister are
called twice, this leads to a kernel panic. This appears to occur during
some possible flows while cleaning up from a failure during driver
probe.
If register_netdev fails, then we will call devlink_port_unregister in
ice_cfg_netdev as it cleans up. Later, we again call
devlink_port_unregister since we assume that we must cleanup the port
that is associated with the PF structure.
This occurs because we cleanup the devlink_port for the main PF even
though it was not allocated. We allocated the port within a per-VSI
function for managing the main netdev, but did not release the port when
cleaning up that VSI, the allocation and destruction are not aligned.
Instead of attempting to manage the devlink_port as part of the PF
structure, manage it as part of the PF VSI. Doing this has advantages,
as we can match the de-allocation of the devlink_port with the
unregister_netdev associated with the main PF VSI.
Moving the port to the VSI is preferable as it paves the way for
handling devlink ports allocated for other purposes such as SR-IOV VFs.
Since we're changing up how we allocate the devlink_port, also change
the indexing. Originally, we indexed the port using the PF id number.
This came from an old goal of sharing a devlink for each physical
function. Managing devlink instances across multiple function drivers is
not workable. Instead, lets set the port number to the logical port
number returned by firmware and set the index using the VSI index
(sometimes referred to as VSI handle).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-08 01:54:44 +08:00
|
|
|
|
2020-03-12 09:58:15 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2021-08-20 08:08:49 +08:00
|
|
|
* ice_devlink_destroy_vf_port - Destroy the devlink_port for this VF
|
|
|
|
* @vf: the VF to cleanup
|
2020-03-12 09:58:15 +08:00
|
|
|
*
|
2021-08-20 08:08:49 +08:00
|
|
|
* Unregisters the devlink_port structure associated with this VF.
|
2020-03-12 09:58:15 +08:00
|
|
|
*/
|
2021-08-20 08:08:49 +08:00
|
|
|
void ice_devlink_destroy_vf_port(struct ice_vf *vf)
|
2020-03-12 09:58:15 +08:00
|
|
|
{
|
2021-08-20 08:08:49 +08:00
|
|
|
struct devlink_port *devlink_port;
|
ice: refactor devlink_port to be per-VSI
Currently, the devlink_port structure is stored within the ice_pf. This
made sense because we create a single devlink_port for each PF. This
setup does not mesh with the abstractions in the driver very well, and
led to a flow where we accidentally call devlink_port_unregister twice
during error cleanup.
In particular, if devlink_port_register or devlink_port_unregister are
called twice, this leads to a kernel panic. This appears to occur during
some possible flows while cleaning up from a failure during driver
probe.
If register_netdev fails, then we will call devlink_port_unregister in
ice_cfg_netdev as it cleans up. Later, we again call
devlink_port_unregister since we assume that we must cleanup the port
that is associated with the PF structure.
This occurs because we cleanup the devlink_port for the main PF even
though it was not allocated. We allocated the port within a per-VSI
function for managing the main netdev, but did not release the port when
cleaning up that VSI, the allocation and destruction are not aligned.
Instead of attempting to manage the devlink_port as part of the PF
structure, manage it as part of the PF VSI. Doing this has advantages,
as we can match the de-allocation of the devlink_port with the
unregister_netdev associated with the main PF VSI.
Moving the port to the VSI is preferable as it paves the way for
handling devlink ports allocated for other purposes such as SR-IOV VFs.
Since we're changing up how we allocate the devlink_port, also change
the indexing. Originally, we indexed the port using the PF id number.
This came from an old goal of sharing a devlink for each physical
function. Managing devlink instances across multiple function drivers is
not workable. Instead, lets set the port number to the logical port
number returned by firmware and set the index using the VSI index
(sometimes referred to as VSI handle).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-08 01:54:44 +08:00
|
|
|
|
2021-08-20 08:08:49 +08:00
|
|
|
devlink_port = &vf->devlink_port;
|
ice: refactor devlink_port to be per-VSI
Currently, the devlink_port structure is stored within the ice_pf. This
made sense because we create a single devlink_port for each PF. This
setup does not mesh with the abstractions in the driver very well, and
led to a flow where we accidentally call devlink_port_unregister twice
during error cleanup.
In particular, if devlink_port_register or devlink_port_unregister are
called twice, this leads to a kernel panic. This appears to occur during
some possible flows while cleaning up from a failure during driver
probe.
If register_netdev fails, then we will call devlink_port_unregister in
ice_cfg_netdev as it cleans up. Later, we again call
devlink_port_unregister since we assume that we must cleanup the port
that is associated with the PF structure.
This occurs because we cleanup the devlink_port for the main PF even
though it was not allocated. We allocated the port within a per-VSI
function for managing the main netdev, but did not release the port when
cleaning up that VSI, the allocation and destruction are not aligned.
Instead of attempting to manage the devlink_port as part of the PF
structure, manage it as part of the PF VSI. Doing this has advantages,
as we can match the de-allocation of the devlink_port with the
unregister_netdev associated with the main PF VSI.
Moving the port to the VSI is preferable as it paves the way for
handling devlink ports allocated for other purposes such as SR-IOV VFs.
Since we're changing up how we allocate the devlink_port, also change
the indexing. Originally, we indexed the port using the PF id number.
This came from an old goal of sharing a devlink for each physical
function. Managing devlink instances across multiple function drivers is
not workable. Instead, lets set the port number to the logical port
number returned by firmware and set the index using the VSI index
(sometimes referred to as VSI handle).
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-10-08 01:54:44 +08:00
|
|
|
|
2021-08-20 08:08:49 +08:00
|
|
|
devlink_port_type_clear(devlink_port);
|
|
|
|
devlink_port_unregister(devlink_port);
|
2020-03-12 09:58:15 +08:00
|
|
|
}
|
2020-03-27 02:37:18 +08:00
|
|
|
|
|
|
|
/**
|
2021-10-12 08:41:10 +08:00
|
|
|
* ice_devlink_nvm_snapshot - Capture a snapshot of the NVM flash contents
|
2020-03-27 02:37:18 +08:00
|
|
|
* @devlink: the devlink instance
|
2020-09-19 03:11:02 +08:00
|
|
|
* @ops: the devlink region being snapshotted
|
2020-03-27 02:37:18 +08:00
|
|
|
* @extack: extended ACK response structure
|
|
|
|
* @data: on exit points to snapshot data buffer
|
|
|
|
*
|
|
|
|
* This function is called in response to the DEVLINK_CMD_REGION_TRIGGER for
|
2021-10-12 08:41:10 +08:00
|
|
|
* the nvm-flash devlink region. It captures a snapshot of the full NVM flash
|
|
|
|
* contents, including both banks of flash. This snapshot can later be viewed
|
|
|
|
* via the devlink-region interface.
|
|
|
|
*
|
|
|
|
* It captures the flash using the FLASH_ONLY bit set when reading via
|
|
|
|
* firmware, so it does not read the current Shadow RAM contents. For that,
|
|
|
|
* use the shadow-ram region.
|
2020-03-27 02:37:18 +08:00
|
|
|
*
|
|
|
|
* @returns zero on success, and updates the data pointer. Returns a non-zero
|
|
|
|
* error code on failure.
|
|
|
|
*/
|
|
|
|
static int ice_devlink_nvm_snapshot(struct devlink *devlink,
|
2020-09-19 03:11:02 +08:00
|
|
|
const struct devlink_region_ops *ops,
|
2020-03-27 02:37:18 +08:00
|
|
|
struct netlink_ext_ack *extack, u8 **data)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
void *nvm_data;
|
|
|
|
u32 nvm_size;
|
2021-10-08 06:59:03 +08:00
|
|
|
int status;
|
2020-03-27 02:37:18 +08:00
|
|
|
|
2020-10-02 01:31:41 +08:00
|
|
|
nvm_size = hw->flash.flash_size;
|
2020-03-27 02:37:18 +08:00
|
|
|
nvm_data = vzalloc(nvm_size);
|
|
|
|
if (!nvm_data)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
status = ice_acquire_nvm(hw, ICE_RES_READ);
|
|
|
|
if (status) {
|
|
|
|
dev_dbg(dev, "ice_acquire_nvm failed, err %d aq_err %d\n",
|
|
|
|
status, hw->adminq.sq_last_status);
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Failed to acquire NVM semaphore");
|
|
|
|
vfree(nvm_data);
|
2021-10-08 07:01:58 +08:00
|
|
|
return status;
|
2020-03-27 02:37:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
status = ice_read_flat_nvm(hw, 0, &nvm_size, nvm_data, false);
|
|
|
|
if (status) {
|
|
|
|
dev_dbg(dev, "ice_read_flat_nvm failed after reading %u bytes, err %d aq_err %d\n",
|
|
|
|
nvm_size, status, hw->adminq.sq_last_status);
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Failed to read NVM contents");
|
|
|
|
ice_release_nvm(hw);
|
|
|
|
vfree(nvm_data);
|
2021-10-08 07:01:58 +08:00
|
|
|
return status;
|
2020-03-27 02:37:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ice_release_nvm(hw);
|
|
|
|
|
|
|
|
*data = nvm_data;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-10-12 08:41:10 +08:00
|
|
|
/**
|
|
|
|
* ice_devlink_sram_snapshot - Capture a snapshot of the Shadow RAM contents
|
|
|
|
* @devlink: the devlink instance
|
|
|
|
* @ops: the devlink region being snapshotted
|
|
|
|
* @extack: extended ACK response structure
|
|
|
|
* @data: on exit points to snapshot data buffer
|
|
|
|
*
|
|
|
|
* This function is called in response to the DEVLINK_CMD_REGION_TRIGGER for
|
|
|
|
* the shadow-ram devlink region. It captures a snapshot of the shadow ram
|
|
|
|
* contents. This snapshot can later be viewed via the devlink-region
|
|
|
|
* interface.
|
|
|
|
*
|
|
|
|
* @returns zero on success, and updates the data pointer. Returns a non-zero
|
|
|
|
* error code on failure.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_devlink_sram_snapshot(struct devlink *devlink,
|
|
|
|
const struct devlink_region_ops __always_unused *ops,
|
|
|
|
struct netlink_ext_ack *extack, u8 **data)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
u8 *sram_data;
|
|
|
|
u32 sram_size;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
sram_size = hw->flash.sr_words * 2u;
|
|
|
|
sram_data = vzalloc(sram_size);
|
|
|
|
if (!sram_data)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
err = ice_acquire_nvm(hw, ICE_RES_READ);
|
|
|
|
if (err) {
|
|
|
|
dev_dbg(dev, "ice_acquire_nvm failed, err %d aq_err %d\n",
|
|
|
|
err, hw->adminq.sq_last_status);
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Failed to acquire NVM semaphore");
|
|
|
|
vfree(sram_data);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read from the Shadow RAM, rather than directly from NVM */
|
|
|
|
err = ice_read_flat_nvm(hw, 0, &sram_size, sram_data, true);
|
|
|
|
if (err) {
|
|
|
|
dev_dbg(dev, "ice_read_flat_nvm failed after reading %u bytes, err %d aq_err %d\n",
|
|
|
|
sram_size, err, hw->adminq.sq_last_status);
|
|
|
|
NL_SET_ERR_MSG_MOD(extack,
|
|
|
|
"Failed to read Shadow RAM contents");
|
|
|
|
ice_release_nvm(hw);
|
|
|
|
vfree(sram_data);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
ice_release_nvm(hw);
|
|
|
|
|
|
|
|
*data = sram_data;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-06-19 02:46:11 +08:00
|
|
|
/**
|
|
|
|
* ice_devlink_devcaps_snapshot - Capture snapshot of device capabilities
|
|
|
|
* @devlink: the devlink instance
|
2020-09-19 03:11:02 +08:00
|
|
|
* @ops: the devlink region being snapshotted
|
2020-06-19 02:46:11 +08:00
|
|
|
* @extack: extended ACK response structure
|
|
|
|
* @data: on exit points to snapshot data buffer
|
|
|
|
*
|
|
|
|
* This function is called in response to the DEVLINK_CMD_REGION_TRIGGER for
|
|
|
|
* the device-caps devlink region. It captures a snapshot of the device
|
|
|
|
* capabilities reported by firmware.
|
|
|
|
*
|
|
|
|
* @returns zero on success, and updates the data pointer. Returns a non-zero
|
|
|
|
* error code on failure.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
ice_devlink_devcaps_snapshot(struct devlink *devlink,
|
2020-09-19 03:11:02 +08:00
|
|
|
const struct devlink_region_ops *ops,
|
2020-06-19 02:46:11 +08:00
|
|
|
struct netlink_ext_ack *extack, u8 **data)
|
|
|
|
{
|
|
|
|
struct ice_pf *pf = devlink_priv(devlink);
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
|
|
|
struct ice_hw *hw = &pf->hw;
|
|
|
|
void *devcaps;
|
2021-10-08 06:59:03 +08:00
|
|
|
int status;
|
2020-06-19 02:46:11 +08:00
|
|
|
|
|
|
|
devcaps = vzalloc(ICE_AQ_MAX_BUF_LEN);
|
|
|
|
if (!devcaps)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
status = ice_aq_list_caps(hw, devcaps, ICE_AQ_MAX_BUF_LEN, NULL,
|
|
|
|
ice_aqc_opc_list_dev_caps, NULL);
|
|
|
|
if (status) {
|
|
|
|
dev_dbg(dev, "ice_aq_list_caps: failed to read device capabilities, err %d aq_err %d\n",
|
|
|
|
status, hw->adminq.sq_last_status);
|
|
|
|
NL_SET_ERR_MSG_MOD(extack, "Failed to read device capabilities");
|
|
|
|
vfree(devcaps);
|
2021-10-08 07:01:58 +08:00
|
|
|
return status;
|
2020-06-19 02:46:11 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
*data = (u8 *)devcaps;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-03-27 02:37:18 +08:00
|
|
|
static const struct devlink_region_ops ice_nvm_region_ops = {
|
|
|
|
.name = "nvm-flash",
|
|
|
|
.destructor = vfree,
|
|
|
|
.snapshot = ice_devlink_nvm_snapshot,
|
|
|
|
};
|
|
|
|
|
2021-10-12 08:41:10 +08:00
|
|
|
static const struct devlink_region_ops ice_sram_region_ops = {
|
|
|
|
.name = "shadow-ram",
|
|
|
|
.destructor = vfree,
|
|
|
|
.snapshot = ice_devlink_sram_snapshot,
|
|
|
|
};
|
|
|
|
|
2020-06-19 02:46:11 +08:00
|
|
|
static const struct devlink_region_ops ice_devcaps_region_ops = {
|
|
|
|
.name = "device-caps",
|
|
|
|
.destructor = vfree,
|
|
|
|
.snapshot = ice_devlink_devcaps_snapshot,
|
|
|
|
};
|
|
|
|
|
2020-03-27 02:37:18 +08:00
|
|
|
/**
|
|
|
|
* ice_devlink_init_regions - Initialize devlink regions
|
|
|
|
* @pf: the PF device structure
|
|
|
|
*
|
|
|
|
* Create devlink regions used to enable access to dump the contents of the
|
|
|
|
* flash memory on the device.
|
|
|
|
*/
|
|
|
|
void ice_devlink_init_regions(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
struct devlink *devlink = priv_to_devlink(pf);
|
|
|
|
struct device *dev = ice_pf_to_dev(pf);
|
2021-10-12 08:41:10 +08:00
|
|
|
u64 nvm_size, sram_size;
|
2020-03-27 02:37:18 +08:00
|
|
|
|
2020-10-02 01:31:41 +08:00
|
|
|
nvm_size = pf->hw.flash.flash_size;
|
2020-03-27 02:37:18 +08:00
|
|
|
pf->nvm_region = devlink_region_create(devlink, &ice_nvm_region_ops, 1,
|
|
|
|
nvm_size);
|
|
|
|
if (IS_ERR(pf->nvm_region)) {
|
|
|
|
dev_err(dev, "failed to create NVM devlink region, err %ld\n",
|
|
|
|
PTR_ERR(pf->nvm_region));
|
|
|
|
pf->nvm_region = NULL;
|
|
|
|
}
|
2020-06-19 02:46:11 +08:00
|
|
|
|
2021-10-12 08:41:10 +08:00
|
|
|
sram_size = pf->hw.flash.sr_words * 2u;
|
|
|
|
pf->sram_region = devlink_region_create(devlink, &ice_sram_region_ops,
|
|
|
|
1, sram_size);
|
|
|
|
if (IS_ERR(pf->sram_region)) {
|
|
|
|
dev_err(dev, "failed to create shadow-ram devlink region, err %ld\n",
|
|
|
|
PTR_ERR(pf->sram_region));
|
|
|
|
pf->sram_region = NULL;
|
|
|
|
}
|
|
|
|
|
2020-06-19 02:46:11 +08:00
|
|
|
pf->devcaps_region = devlink_region_create(devlink,
|
|
|
|
&ice_devcaps_region_ops, 10,
|
|
|
|
ICE_AQ_MAX_BUF_LEN);
|
|
|
|
if (IS_ERR(pf->devcaps_region)) {
|
|
|
|
dev_err(dev, "failed to create device-caps devlink region, err %ld\n",
|
|
|
|
PTR_ERR(pf->devcaps_region));
|
|
|
|
pf->devcaps_region = NULL;
|
|
|
|
}
|
2020-03-27 02:37:18 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_devlink_destroy_regions - Destroy devlink regions
|
|
|
|
* @pf: the PF device structure
|
|
|
|
*
|
|
|
|
* Remove previously created regions for this PF.
|
|
|
|
*/
|
|
|
|
void ice_devlink_destroy_regions(struct ice_pf *pf)
|
|
|
|
{
|
|
|
|
if (pf->nvm_region)
|
|
|
|
devlink_region_destroy(pf->nvm_region);
|
2021-10-12 08:41:10 +08:00
|
|
|
|
|
|
|
if (pf->sram_region)
|
|
|
|
devlink_region_destroy(pf->sram_region);
|
|
|
|
|
2020-06-19 02:46:11 +08:00
|
|
|
if (pf->devcaps_region)
|
|
|
|
devlink_region_destroy(pf->devcaps_region);
|
2020-03-27 02:37:18 +08:00
|
|
|
}
|