* [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
@ 2020-05-18 8:27 Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 1/4] devlink: Add new "enable_hot_fw_reset" generic device parameter Vasundhara Volam
` (4 more replies)
0 siblings, 5 replies; 19+ messages in thread
From: Vasundhara Volam @ 2020-05-18 8:27 UTC (permalink / raw)
To: davem; +Cc: netdev, Vasundhara Volam
This patchset adds support for a "enable_hot_fw_reset" generic devlink
parameter and use it in bnxt_en driver.
Also, firmware spec. is updated to 1.10.1.40.
Vasundhara Volam (4):
devlink: Add new "enable_hot_fw_reset" generic device parameter.
bnxt_en: Update firmware spec. to 1.10.1.40.
bnxt_en: Use enable_hot_fw_reset generic devlink parameter
bnxt_en: Check if hot_fw_reset is allowed before doing ETHTOOL_RESET
Documentation/networking/devlink/bnxt.rst | 6 ++
.../networking/devlink/devlink-params.rst | 6 ++
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 28 +++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 2 +
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 61 +++++++++++++++++++++
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 +
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 17 +++---
drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h | 64 +++++++++++++---------
include/net/devlink.h | 4 ++
net/core/devlink.c | 5 ++
10 files changed, 158 insertions(+), 36 deletions(-)
--
1.8.3.1
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH net-next 1/4] devlink: Add new "enable_hot_fw_reset" generic device parameter.
2020-05-18 8:27 [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Vasundhara Volam
@ 2020-05-18 8:27 ` Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 2/4] bnxt_en: Update firmware spec. to 1.10.1.40 Vasundhara Volam
` (3 subsequent siblings)
4 siblings, 0 replies; 19+ messages in thread
From: Vasundhara Volam @ 2020-05-18 8:27 UTC (permalink / raw)
To: davem; +Cc: netdev, Vasundhara Volam, Jiri Pirko, Michael Chan
Add a new "enable_hot_fw_reset" generic device parameter to enable
or disable hot firmware reset capability on the device.
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
---
Documentation/networking/devlink/devlink-params.rst | 6 ++++++
include/net/devlink.h | 4 ++++
net/core/devlink.c | 5 +++++
3 files changed, 15 insertions(+)
diff --git a/Documentation/networking/devlink/devlink-params.rst b/Documentation/networking/devlink/devlink-params.rst
index d075fd0..ba75437 100644
--- a/Documentation/networking/devlink/devlink-params.rst
+++ b/Documentation/networking/devlink/devlink-params.rst
@@ -108,3 +108,9 @@ own name.
* - ``region_snapshot_enable``
- Boolean
- Enable capture of ``devlink-region`` snapshots.
+ * - ``enable_hot_fw_reset``
+ - Boolean
+ - Enable hot firmware reset on the device. When enabled, device supports
+ hot firmware reset capability which will be able to reset the running
+ firmware or upgrade/downgrade of flashed firmware without a driver
+ reload.
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 8ffc1b5c..57377bf 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -406,6 +406,7 @@ enum devlink_param_generic_id {
DEVLINK_PARAM_GENERIC_ID_FW_LOAD_POLICY,
DEVLINK_PARAM_GENERIC_ID_RESET_DEV_ON_DRV_PROBE,
DEVLINK_PARAM_GENERIC_ID_ENABLE_ROCE,
+ DEVLINK_PARAM_GENERIC_ID_ENABLE_HOT_FW_RESET,
/* add new param generic ids above here*/
__DEVLINK_PARAM_GENERIC_ID_MAX,
@@ -443,6 +444,9 @@ enum devlink_param_generic_id {
#define DEVLINK_PARAM_GENERIC_ENABLE_ROCE_NAME "enable_roce"
#define DEVLINK_PARAM_GENERIC_ENABLE_ROCE_TYPE DEVLINK_PARAM_TYPE_BOOL
+#define DEVLINK_PARAM_GENERIC_ENABLE_HOT_FW_RESET_NAME "enable_hot_fw_reset"
+#define DEVLINK_PARAM_GENERIC_ENABLE_HOT_FW_RESET_TYPE DEVLINK_PARAM_TYPE_BOOL
+
#define DEVLINK_PARAM_GENERIC(_id, _cmodes, _get, _set, _validate) \
{ \
.id = DEVLINK_PARAM_GENERIC_ID_##_id, \
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 7b76e5f..32fb8e6 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -3011,6 +3011,11 @@ static int devlink_nl_cmd_flash_update(struct sk_buff *skb,
.name = DEVLINK_PARAM_GENERIC_ENABLE_ROCE_NAME,
.type = DEVLINK_PARAM_GENERIC_ENABLE_ROCE_TYPE,
},
+ {
+ .id = DEVLINK_PARAM_GENERIC_ID_ENABLE_HOT_FW_RESET,
+ .name = DEVLINK_PARAM_GENERIC_ENABLE_HOT_FW_RESET_NAME,
+ .type = DEVLINK_PARAM_GENERIC_ENABLE_HOT_FW_RESET_TYPE,
+ },
};
static int devlink_param_generic_verify(const struct devlink_param *param)
--
1.8.3.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH net-next 2/4] bnxt_en: Update firmware spec. to 1.10.1.40.
2020-05-18 8:27 [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 1/4] devlink: Add new "enable_hot_fw_reset" generic device parameter Vasundhara Volam
@ 2020-05-18 8:27 ` Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 3/4] bnxt_en: Use enable_hot_fw_reset generic devlink parameter Vasundhara Volam
` (2 subsequent siblings)
4 siblings, 0 replies; 19+ messages in thread
From: Vasundhara Volam @ 2020-05-18 8:27 UTC (permalink / raw)
To: davem; +Cc: netdev, Vasundhara Volam, Michael Chan
Major changes are to add additional flags to configure hot firmware
reset.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h | 64 ++++++++++++++++-----------
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h
index 7e9235c..0a6e60e 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_hsi.h
@@ -367,6 +367,8 @@ struct cmd_nums {
#define HWRM_TF_EXT_EM_OP 0x2ddUL
#define HWRM_TF_EXT_EM_CFG 0x2deUL
#define HWRM_TF_EXT_EM_QCFG 0x2dfUL
+ #define HWRM_TF_EM_INSERT 0x2e0UL
+ #define HWRM_TF_EM_DELETE 0x2e1UL
#define HWRM_TF_TCAM_SET 0x2eeUL
#define HWRM_TF_TCAM_GET 0x2efUL
#define HWRM_TF_TCAM_MOVE 0x2f0UL
@@ -391,6 +393,7 @@ struct cmd_nums {
#define HWRM_DBG_QCAPS 0xff20UL
#define HWRM_DBG_QCFG 0xff21UL
#define HWRM_DBG_CRASHDUMP_MEDIUM_CFG 0xff22UL
+ #define HWRM_NVM_REQ_ARBITRATION 0xffedUL
#define HWRM_NVM_FACTORY_DEFAULTS 0xffeeUL
#define HWRM_NVM_VALIDATE_OPTION 0xffefUL
#define HWRM_NVM_FLUSH 0xfff0UL
@@ -464,8 +467,8 @@ struct hwrm_err_output {
#define HWRM_VERSION_MAJOR 1
#define HWRM_VERSION_MINOR 10
#define HWRM_VERSION_UPDATE 1
-#define HWRM_VERSION_RSVD 33
-#define HWRM_VERSION_STR "1.10.1.33"
+#define HWRM_VERSION_RSVD 40
+#define HWRM_VERSION_STR "1.10.1.40"
/* hwrm_ver_get_input (size:192b/24B) */
struct hwrm_ver_get_input {
@@ -1192,6 +1195,7 @@ struct hwrm_func_qcaps_output {
#define FUNC_QCAPS_RESP_FLAGS_EXT_ECN_MARK_SUPPORTED 0x1UL
#define FUNC_QCAPS_RESP_FLAGS_EXT_ECN_STATS_SUPPORTED 0x2UL
#define FUNC_QCAPS_RESP_FLAGS_EXT_EXT_HW_STATS_SUPPORTED 0x4UL
+ #define FUNC_QCAPS_RESP_FLAGS_EXT_HOT_RESET_IF_SUPPORT 0x8UL
u8 unused_1[3];
u8 valid;
};
@@ -1226,6 +1230,7 @@ struct hwrm_func_qcfg_output {
#define FUNC_QCFG_RESP_FLAGS_TRUSTED_VF 0x40UL
#define FUNC_QCFG_RESP_FLAGS_SECURE_MODE_ENABLED 0x80UL
#define FUNC_QCFG_RESP_FLAGS_PREBOOT_LEGACY_L2_RINGS 0x100UL
+ #define FUNC_QCFG_RESP_FLAGS_HOT_RESET_ALLOWED 0x200UL
u8 mac_address[6];
__le16 pci_id;
__le16 alloc_rsscos_ctx;
@@ -1352,30 +1357,32 @@ struct hwrm_func_cfg_input {
#define FUNC_CFG_REQ_FLAGS_NQ_ASSETS_TEST 0x800000UL
#define FUNC_CFG_REQ_FLAGS_TRUSTED_VF_DISABLE 0x1000000UL
#define FUNC_CFG_REQ_FLAGS_PREBOOT_LEGACY_L2_RINGS 0x2000000UL
+ #define FUNC_CFG_REQ_FLAGS_HOT_RESET_IF_EN_DIS 0x4000000UL
__le32 enables;
- #define FUNC_CFG_REQ_ENABLES_MTU 0x1UL
- #define FUNC_CFG_REQ_ENABLES_MRU 0x2UL
- #define FUNC_CFG_REQ_ENABLES_NUM_RSSCOS_CTXS 0x4UL
- #define FUNC_CFG_REQ_ENABLES_NUM_CMPL_RINGS 0x8UL
- #define FUNC_CFG_REQ_ENABLES_NUM_TX_RINGS 0x10UL
- #define FUNC_CFG_REQ_ENABLES_NUM_RX_RINGS 0x20UL
- #define FUNC_CFG_REQ_ENABLES_NUM_L2_CTXS 0x40UL
- #define FUNC_CFG_REQ_ENABLES_NUM_VNICS 0x80UL
- #define FUNC_CFG_REQ_ENABLES_NUM_STAT_CTXS 0x100UL
- #define FUNC_CFG_REQ_ENABLES_DFLT_MAC_ADDR 0x200UL
- #define FUNC_CFG_REQ_ENABLES_DFLT_VLAN 0x400UL
- #define FUNC_CFG_REQ_ENABLES_DFLT_IP_ADDR 0x800UL
- #define FUNC_CFG_REQ_ENABLES_MIN_BW 0x1000UL
- #define FUNC_CFG_REQ_ENABLES_MAX_BW 0x2000UL
- #define FUNC_CFG_REQ_ENABLES_ASYNC_EVENT_CR 0x4000UL
- #define FUNC_CFG_REQ_ENABLES_VLAN_ANTISPOOF_MODE 0x8000UL
- #define FUNC_CFG_REQ_ENABLES_ALLOWED_VLAN_PRIS 0x10000UL
- #define FUNC_CFG_REQ_ENABLES_EVB_MODE 0x20000UL
- #define FUNC_CFG_REQ_ENABLES_NUM_MCAST_FILTERS 0x40000UL
- #define FUNC_CFG_REQ_ENABLES_NUM_HW_RING_GRPS 0x80000UL
- #define FUNC_CFG_REQ_ENABLES_CACHE_LINESIZE 0x100000UL
- #define FUNC_CFG_REQ_ENABLES_NUM_MSIX 0x200000UL
- #define FUNC_CFG_REQ_ENABLES_ADMIN_LINK_STATE 0x400000UL
+ #define FUNC_CFG_REQ_ENABLES_MTU 0x1UL
+ #define FUNC_CFG_REQ_ENABLES_MRU 0x2UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_RSSCOS_CTXS 0x4UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_CMPL_RINGS 0x8UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_TX_RINGS 0x10UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_RX_RINGS 0x20UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_L2_CTXS 0x40UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_VNICS 0x80UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_STAT_CTXS 0x100UL
+ #define FUNC_CFG_REQ_ENABLES_DFLT_MAC_ADDR 0x200UL
+ #define FUNC_CFG_REQ_ENABLES_DFLT_VLAN 0x400UL
+ #define FUNC_CFG_REQ_ENABLES_DFLT_IP_ADDR 0x800UL
+ #define FUNC_CFG_REQ_ENABLES_MIN_BW 0x1000UL
+ #define FUNC_CFG_REQ_ENABLES_MAX_BW 0x2000UL
+ #define FUNC_CFG_REQ_ENABLES_ASYNC_EVENT_CR 0x4000UL
+ #define FUNC_CFG_REQ_ENABLES_VLAN_ANTISPOOF_MODE 0x8000UL
+ #define FUNC_CFG_REQ_ENABLES_ALLOWED_VLAN_PRIS 0x10000UL
+ #define FUNC_CFG_REQ_ENABLES_EVB_MODE 0x20000UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_MCAST_FILTERS 0x40000UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_HW_RING_GRPS 0x80000UL
+ #define FUNC_CFG_REQ_ENABLES_CACHE_LINESIZE 0x100000UL
+ #define FUNC_CFG_REQ_ENABLES_NUM_MSIX 0x200000UL
+ #define FUNC_CFG_REQ_ENABLES_ADMIN_LINK_STATE 0x400000UL
+ #define FUNC_CFG_REQ_ENABLES_HOT_RESET_IF_SUPPORT 0x800000UL
__le16 mtu;
__le16 mru;
__le16 num_rsscos_ctxs;
@@ -7620,7 +7627,8 @@ struct hwrm_dbg_ring_info_get_input {
#define DBG_RING_INFO_GET_REQ_RING_TYPE_L2_CMPL 0x0UL
#define DBG_RING_INFO_GET_REQ_RING_TYPE_TX 0x1UL
#define DBG_RING_INFO_GET_REQ_RING_TYPE_RX 0x2UL
- #define DBG_RING_INFO_GET_REQ_RING_TYPE_LAST DBG_RING_INFO_GET_REQ_RING_TYPE_RX
+ #define DBG_RING_INFO_GET_REQ_RING_TYPE_NQ 0x3UL
+ #define DBG_RING_INFO_GET_REQ_RING_TYPE_LAST DBG_RING_INFO_GET_REQ_RING_TYPE_NQ
u8 unused_0[3];
__le32 fw_ring_id;
};
@@ -7633,7 +7641,8 @@ struct hwrm_dbg_ring_info_get_output {
__le16 resp_len;
__le32 producer_index;
__le32 consumer_index;
- u8 unused_0[7];
+ __le32 cag_vector_ctrl;
+ u8 unused_0[3];
u8 valid;
};
@@ -7922,6 +7931,7 @@ struct hwrm_nvm_install_update_input {
#define NVM_INSTALL_UPDATE_REQ_FLAGS_ERASE_UNUSED_SPACE 0x1UL
#define NVM_INSTALL_UPDATE_REQ_FLAGS_REMOVE_UNUSED_PKG 0x2UL
#define NVM_INSTALL_UPDATE_REQ_FLAGS_ALLOWED_TO_DEFRAG 0x4UL
+ #define NVM_INSTALL_UPDATE_REQ_FLAGS_VERIFY_ONLY 0x8UL
u8 unused_0[2];
};
--
1.8.3.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH net-next 3/4] bnxt_en: Use enable_hot_fw_reset generic devlink parameter
2020-05-18 8:27 [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 1/4] devlink: Add new "enable_hot_fw_reset" generic device parameter Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 2/4] bnxt_en: Update firmware spec. to 1.10.1.40 Vasundhara Volam
@ 2020-05-18 8:27 ` Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 4/4] bnxt_en: Check if hot_fw_reset is allowed before doing ETHTOOL_RESET Vasundhara Volam
2020-05-18 11:01 ` [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Jiri Pirko
4 siblings, 0 replies; 19+ messages in thread
From: Vasundhara Volam @ 2020-05-18 8:27 UTC (permalink / raw)
To: davem; +Cc: netdev, Vasundhara Volam, Michael Chan
enable_hot_fw_reset parameter supports both permanent and runtime
configuration modes. This parameter enables or disables the hot
firmware reset capability of the device which either resets the
currently running firmware or upgrades/downgrades flashed
firmware.
For the runtime parameter to be true, all the loaded host driver
interfaces must support hot firmware reset. If any driver's
interface capability is set to false by the user, the device cannot
support hot firmware reset. To re-enable the capability, all the
driver interfaces have to set the value to true.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
---
Documentation/networking/devlink/bnxt.rst | 6 +++
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 28 ++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 2 +
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 61 +++++++++++++++++++++++
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 +
5 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/Documentation/networking/devlink/bnxt.rst b/Documentation/networking/devlink/bnxt.rst
index 3dfd84c..69393d3 100644
--- a/Documentation/networking/devlink/bnxt.rst
+++ b/Documentation/networking/devlink/bnxt.rst
@@ -14,6 +14,7 @@ Parameters
* - Name
- Mode
+ - Description
* - ``enable_sriov``
- Permanent
* - ``ignore_ari``
@@ -22,6 +23,11 @@ Parameters
- Permanent
* - ``msix_vec_per_pf_min``
- Permanent
+ * - ``enable_hot_fw_reset``
+ - Permanent, runtime
+ - For the runtime parameter to be true, all the loaded host driver
+ interfaces must support hot firmware reset. To re-enable the
+ capability, all the driver interfaces have to set the value to true.
The ``bnxt`` driver also implements the following driver-specific
parameters.
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index f86b621..535fe8f 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -6955,7 +6955,7 @@ static int __bnxt_hwrm_func_qcaps(struct bnxt *bp)
struct hwrm_func_qcaps_input req = {0};
struct hwrm_func_qcaps_output *resp = bp->hwrm_cmd_resp_addr;
struct bnxt_hw_resc *hw_resc = &bp->hw_resc;
- u32 flags;
+ u32 flags, flags_ext;
bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FUNC_QCAPS, -1, -1);
req.fid = cpu_to_le16(0xffff);
@@ -6985,6 +6985,10 @@ static int __bnxt_hwrm_func_qcaps(struct bnxt *bp)
if (flags & FUNC_QCAPS_RESP_FLAGS_PUSH_MODE_SUPPORTED)
bp->tx_push_thresh = BNXT_TX_PUSH_THRESH;
+ flags_ext = le32_to_cpu(resp->flags_ext);
+ if (flags_ext & FUNC_QCAPS_RESP_FLAGS_EXT_HOT_RESET_IF_SUPPORT)
+ bp->fw_cap |= BNXT_FW_CAP_HOT_RESET_IF_SUPPORT;
+
hw_resc->max_rsscos_ctxs = le16_to_cpu(resp->max_rsscos_ctx);
hw_resc->max_cp_rings = le16_to_cpu(resp->max_cmpl_rings);
hw_resc->max_tx_rings = le16_to_cpu(resp->max_tx_rings);
@@ -8773,6 +8777,28 @@ static int bnxt_hwrm_shutdown_link(struct bnxt *bp)
static int bnxt_fw_init_one(struct bnxt *bp);
+int bnxt_hwrm_get_hot_reset(struct bnxt *bp, bool *hot_reset_allowed)
+{
+ struct hwrm_func_qcfg_output *resp = bp->hwrm_cmd_resp_addr;
+ struct hwrm_func_qcfg_input req = {0};
+ int rc;
+
+ if (!(bp->fw_cap & BNXT_FW_CAP_HOT_RESET_IF_SUPPORT)) {
+ *hot_reset_allowed = !!(bp->fw_cap & BNXT_FW_CAP_HOT_RESET);
+ return 0;
+ }
+
+ bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FUNC_QCFG, -1, -1);
+ req.fid = cpu_to_le16(0xffff);
+ mutex_lock(&bp->hwrm_cmd_lock);
+ rc = _hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
+ if (!rc)
+ *hot_reset_allowed = !!(le16_to_cpu(resp->flags) &
+ FUNC_QCFG_RESP_FLAGS_HOT_RESET_ALLOWED);
+ mutex_unlock(&bp->hwrm_cmd_lock);
+ return rc;
+}
+
static int bnxt_hwrm_if_change(struct bnxt *bp, bool up)
{
struct hwrm_func_drv_if_change_output *resp = bp->hwrm_cmd_resp_addr;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index c04ac4a..fd6592e 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -1710,6 +1710,7 @@ struct bnxt {
#define BNXT_FW_CAP_ERR_RECOVER_RELOAD 0x00100000
#define BNXT_FW_CAP_HOT_RESET 0x00200000
#define BNXT_FW_CAP_SHARED_PORT_CFG 0x00400000
+ #define BNXT_FW_CAP_HOT_RESET_IF_SUPPORT 0x08000000
#define BNXT_NEW_RM(bp) ((bp)->fw_cap & BNXT_FW_CAP_NEW_RM)
u32 hwrm_spec_code;
@@ -2062,5 +2063,6 @@ int bnxt_get_port_parent_id(struct net_device *dev,
struct netdev_phys_item_id *ppid);
void bnxt_dim_work(struct work_struct *work);
int bnxt_hwrm_set_ring_coal(struct bnxt *bp, struct bnxt_napi *bnapi);
+int bnxt_hwrm_get_hot_reset(struct bnxt *bp, bool *hot_reset_allowed);
#endif
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index a812beb..61bf630 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -314,6 +314,8 @@ enum bnxt_dl_param_id {
NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7, 4},
{BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK, NVM_OFF_DIS_GRE_VER_CHECK,
BNXT_NVM_SHARED_CFG, 1, 1},
+ {DEVLINK_PARAM_GENERIC_ID_ENABLE_HOT_FW_RESET,
+ NVM_OFF_LIVE_FW_UPGRADE, BNXT_NVM_SHARED_CFG, 1, 1},
};
union bnxt_nvm_data {
@@ -618,6 +620,61 @@ static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
return 0;
}
+static int bnxt_dl_param_get(struct devlink *dl, u32 id,
+ struct devlink_param_gset_ctx *ctx)
+{
+ struct bnxt *bp = bnxt_get_bp_from_dl(dl);
+
+ if (ctx->cmode == DEVLINK_PARAM_CMODE_PERMANENT)
+ return bnxt_dl_nvm_param_get(dl, id, ctx);
+ else if (ctx->cmode == DEVLINK_PARAM_CMODE_RUNTIME)
+ return bnxt_hwrm_get_hot_reset(bp, &ctx->val.vbool);
+
+ return -EOPNOTSUPP;
+}
+
+static int bnxt_hwrm_set_hot_reset(struct bnxt *bp, bool hot_reset_if_support)
+{
+ struct hwrm_func_cfg_input req = {0};
+ bool hot_reset_allowed;
+ int rc;
+
+ if (!(bp->fw_cap & BNXT_FW_CAP_HOT_RESET_IF_SUPPORT))
+ return -EOPNOTSUPP;
+
+ bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_FUNC_CFG, -1, -1);
+ req.fid = cpu_to_le16(0xffff);
+ req.enables = cpu_to_le32(FUNC_CFG_REQ_ENABLES_HOT_RESET_IF_SUPPORT);
+ if (hot_reset_if_support)
+ req.flags = cpu_to_le32(FUNC_CFG_REQ_FLAGS_HOT_RESET_IF_EN_DIS);
+
+ rc = hwrm_send_message(bp, &req, sizeof(req), HWRM_CMD_TIMEOUT);
+ if (rc)
+ return rc;
+
+ rc = bnxt_hwrm_get_hot_reset(bp, &hot_reset_allowed);
+ if (rc)
+ return rc;
+
+ if (hot_reset_if_support && !hot_reset_allowed)
+ netdev_info(bp->dev, "Hot FW Reset enabled, but is disallowed as it is disabled on other interface(s) of this device.\n");
+
+ return 0;
+}
+
+static int bnxt_dl_param_set(struct devlink *dl, u32 id,
+ struct devlink_param_gset_ctx *ctx)
+{
+ struct bnxt *bp = bnxt_get_bp_from_dl(dl);
+
+ if (ctx->cmode == DEVLINK_PARAM_CMODE_PERMANENT)
+ return bnxt_dl_nvm_param_set(dl, id, ctx);
+ else if (ctx->cmode == DEVLINK_PARAM_CMODE_RUNTIME)
+ return bnxt_hwrm_set_hot_reset(bp, ctx->val.vbool);
+
+ return -EOPNOTSUPP;
+}
+
static const struct devlink_param bnxt_dl_params[] = {
DEVLINK_PARAM_GENERIC(ENABLE_SRIOV,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
@@ -640,6 +697,10 @@ static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
NULL),
+ DEVLINK_PARAM_GENERIC(ENABLE_HOT_FW_RESET,
+ BIT(DEVLINK_PARAM_CMODE_PERMANENT) |
+ BIT(DEVLINK_PARAM_CMODE_RUNTIME),
+ bnxt_dl_param_get, bnxt_dl_param_set, NULL),
};
static const struct devlink_param bnxt_dl_port_params[] = {
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index d5c8bd4..0a5efff 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -39,6 +39,7 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
#define NVM_OFF_DIS_GRE_VER_CHECK 171
#define NVM_OFF_ENABLE_SRIOV 401
#define NVM_OFF_NVM_CFG_VER 602
+#define NVM_OFF_LIVE_FW_UPGRADE 917
#define BNXT_NVM_CFG_VER_BITS 24
#define BNXT_NVM_CFG_VER_BYTES 4
--
1.8.3.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH net-next 4/4] bnxt_en: Check if hot_fw_reset is allowed before doing ETHTOOL_RESET
2020-05-18 8:27 [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Vasundhara Volam
` (2 preceding siblings ...)
2020-05-18 8:27 ` [PATCH net-next 3/4] bnxt_en: Use enable_hot_fw_reset generic devlink parameter Vasundhara Volam
@ 2020-05-18 8:27 ` Vasundhara Volam
2020-05-18 11:01 ` [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Jiri Pirko
4 siblings, 0 replies; 19+ messages in thread
From: Vasundhara Volam @ 2020-05-18 8:27 UTC (permalink / raw)
To: davem; +Cc: netdev, Vasundhara Volam, Michael Chan
If device does not allow hot_fw_reset, issue firmware reset
without graceful flag.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Reviewed-by: Edwin Peer <edwin.peer@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
index dd0c3f2..e5eb8d2 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c
@@ -1888,12 +1888,11 @@ static int bnxt_firmware_reset(struct net_device *dev,
return bnxt_hwrm_firmware_reset(dev, proc_type, self_reset, flags);
}
-static int bnxt_firmware_reset_chip(struct net_device *dev)
+static int bnxt_firmware_reset_chip(struct net_device *dev, bool hot_reset)
{
- struct bnxt *bp = netdev_priv(dev);
u8 flags = 0;
- if (bp->fw_cap & BNXT_FW_CAP_HOT_RESET)
+ if (hot_reset)
flags = FW_RESET_REQ_FLAGS_RESET_GRACEFUL;
return bnxt_hwrm_firmware_reset(dev,
@@ -3082,7 +3081,7 @@ static void bnxt_self_test(struct net_device *dev, struct ethtool_test *etest,
static int bnxt_reset(struct net_device *dev, u32 *flags)
{
struct bnxt *bp = netdev_priv(dev);
- bool reload = false;
+ bool reload = false, hot_reset;
u32 req = *flags;
if (!req)
@@ -3093,8 +3092,10 @@ static int bnxt_reset(struct net_device *dev, u32 *flags)
return -EOPNOTSUPP;
}
- if (pci_vfs_assigned(bp->pdev) &&
- !(bp->fw_cap & BNXT_FW_CAP_HOT_RESET)) {
+ if (bnxt_hwrm_get_hot_reset(bp, &hot_reset))
+ hot_reset = !!(bp->fw_cap & BNXT_FW_CAP_HOT_RESET);
+
+ if (pci_vfs_assigned(bp->pdev) && !hot_reset) {
netdev_err(dev,
"Reset not allowed when VFs are assigned to VMs\n");
return -EBUSY;
@@ -3103,9 +3104,9 @@ static int bnxt_reset(struct net_device *dev, u32 *flags)
if ((req & BNXT_FW_RESET_CHIP) == BNXT_FW_RESET_CHIP) {
/* This feature is not supported in older firmware versions */
if (bp->hwrm_spec_code >= 0x10803) {
- if (!bnxt_firmware_reset_chip(dev)) {
+ if (!bnxt_firmware_reset_chip(dev, hot_reset)) {
netdev_info(dev, "Firmware reset request successful.\n");
- if (!(bp->fw_cap & BNXT_FW_CAP_HOT_RESET))
+ if (!hot_reset)
reload = true;
*flags &= ~BNXT_FW_RESET_CHIP;
}
--
1.8.3.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-18 8:27 [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Vasundhara Volam
` (3 preceding siblings ...)
2020-05-18 8:27 ` [PATCH net-next 4/4] bnxt_en: Check if hot_fw_reset is allowed before doing ETHTOOL_RESET Vasundhara Volam
@ 2020-05-18 11:01 ` Jiri Pirko
2020-05-18 23:43 ` Jakub Kicinski
2020-05-19 4:31 ` Vasundhara Volam
4 siblings, 2 replies; 19+ messages in thread
From: Jiri Pirko @ 2020-05-18 11:01 UTC (permalink / raw)
To: Vasundhara Volam; +Cc: davem, netdev
Mon, May 18, 2020 at 10:27:15AM CEST, vasundhara-v.volam@broadcom.com wrote:
>This patchset adds support for a "enable_hot_fw_reset" generic devlink
>parameter and use it in bnxt_en driver.
>
>Also, firmware spec. is updated to 1.10.1.40.
Hi.
We've been discussing this internally for some time.
I don't like to use params for this purpose.
We already have "devlink dev flash" and "devlink dev reload" commands.
Combination of these two with appropriate attributes should provide what
you want. The "param" you are introducing is related to either "flash"
or "reload", so I don't think it is good to have separate param, when we
can extend the command attributes.
How does flash&reload work for mlxsw now:
# devlink flash
Now new version is pending, old FW is running
# devlink reload
Driver resets the device, new FW is loaded
I propose to extend reload like this:
devlink dev reload DEV [ level { driver-default | fw-reset | driver-only | fw-live-patch } ]
driver-default - means one of following to, according to what is
default for the driver
fw-reset - does FW reset and driver entities re-instantiation
driver-only - does driver entities re-instantiation only
fw-live-patch - does only FW live patching - no effect on kernel
Could be an enum or bitfield. Does not matter. The point is to use
reload with attribute to achieve what user wants. In your usecase, user
would do:
# devlink flash
# devlink reload level fw-live-patch
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-18 11:01 ` [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Jiri Pirko
@ 2020-05-18 23:43 ` Jakub Kicinski
2020-05-19 5:24 ` Jiri Pirko
2020-05-19 4:31 ` Vasundhara Volam
1 sibling, 1 reply; 19+ messages in thread
From: Jakub Kicinski @ 2020-05-18 23:43 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Vasundhara Volam, davem, netdev
On Mon, 18 May 2020 13:01:52 +0200 Jiri Pirko wrote:
> Mon, May 18, 2020 at 10:27:15AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >This patchset adds support for a "enable_hot_fw_reset" generic devlink
> >parameter and use it in bnxt_en driver.
> >
> >Also, firmware spec. is updated to 1.10.1.40.
>
> Hi.
>
> We've been discussing this internally for some time.
> I don't like to use params for this purpose.
> We already have "devlink dev flash" and "devlink dev reload" commands.
> Combination of these two with appropriate attributes should provide what
> you want. The "param" you are introducing is related to either "flash"
> or "reload", so I don't think it is good to have separate param, when we
> can extend the command attributes.
>
> How does flash&reload work for mlxsw now:
>
> # devlink flash
> Now new version is pending, old FW is running
> # devlink reload
> Driver resets the device, new FW is loaded
>
> I propose to extend reload like this:
>
> devlink dev reload DEV [ level { driver-default | fw-reset | driver-only | fw-live-patch } ]
> driver-default - means one of following to, according to what is
> default for the driver
> fw-reset - does FW reset and driver entities re-instantiation
> driver-only - does driver entities re-instantiation only
> fw-live-patch - does only FW live patching - no effect on kernel
>
> Could be an enum or bitfield. Does not matter. The point is to use
> reload with attribute to achieve what user wants. In your usecase, user
> would do:
>
> # devlink flash
> # devlink reload level fw-live-patch
Unfortunately for SmartNICs and MultiHost systems the reset may not be
initiated locally. I agree it'd be great to have a normal netlink knob
for this instead of a param. But it has to be some form of a policy of
allowing the reset to happen, rather than an action/trigger kind of
thing.
Also user space notification should be generated when reset happens,
IMO. devlink dev info contents will likely change after reset, if
nothing else.
Plus this functionality will need proper documentation.
FWIW - I am unconvinced that applications will be happy to experience
network black outs, rather than being fully killed and re-spawned. For
a micro-service worker shutdown + re-spawn should be bread and butter.
But we already have ionic doing this, so seems like vendors are
convinced otherwise, so a common interface is probably a good step.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-18 11:01 ` [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Jiri Pirko
2020-05-18 23:43 ` Jakub Kicinski
@ 2020-05-19 4:31 ` Vasundhara Volam
2020-05-19 5:27 ` Jiri Pirko
1 sibling, 1 reply; 19+ messages in thread
From: Vasundhara Volam @ 2020-05-19 4:31 UTC (permalink / raw)
To: Jiri Pirko; +Cc: David Miller, Netdev
On Mon, May 18, 2020 at 4:31 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Mon, May 18, 2020 at 10:27:15AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >This patchset adds support for a "enable_hot_fw_reset" generic devlink
> >parameter and use it in bnxt_en driver.
> >
> >Also, firmware spec. is updated to 1.10.1.40.
>
> Hi.
>
> We've been discussing this internally for some time.
> I don't like to use params for this purpose.
> We already have "devlink dev flash" and "devlink dev reload" commands.
> Combination of these two with appropriate attributes should provide what
> you want. The "param" you are introducing is related to either "flash"
> or "reload", so I don't think it is good to have separate param, when we
> can extend the command attributes.
>
> How does flash&reload work for mlxsw now:
>
> # devlink flash
> Now new version is pending, old FW is running
> # devlink reload
> Driver resets the device, new FW is loaded
>
> I propose to extend reload like this:
>
> devlink dev reload DEV [ level { driver-default | fw-reset | driver-only | fw-live-patch } ]
> driver-default - means one of following to, according to what is
> default for the driver
> fw-reset - does FW reset and driver entities re-instantiation
> driver-only - does driver entities re-instantiation only
> fw-live-patch - does only FW live patching - no effect on kernel
>
> Could be an enum or bitfield. Does not matter. The point is to use
> reload with attribute to achieve what user wants. In your usecase, user
> would do:
>
> # devlink flash
> # devlink reload level fw-live-patch
Jiri,
I am adding this param to control the fw hot reset capability of the device.
Permanent configuration mode will toggle the NVM config space which is
very similar to enable_roce/enable_sriov param and runtime configuration
mode will toggle the driver level knob to avoid/allow fw-live-reset.
From above. I see that you are suggesting how to trigger the fw hot reset.
This is good to have, but does not serve the purpose of enabling or disabling
of the feature. Our driver is currently using "ethtool --reset" for
triggering fw-reset
or fw-live-patch.
Thanks,
Vasundhara
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-18 23:43 ` Jakub Kicinski
@ 2020-05-19 5:24 ` Jiri Pirko
2020-05-19 17:44 ` Jakub Kicinski
0 siblings, 1 reply; 19+ messages in thread
From: Jiri Pirko @ 2020-05-19 5:24 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: Vasundhara Volam, davem, netdev
Tue, May 19, 2020 at 01:43:09AM CEST, kuba@kernel.org wrote:
>On Mon, 18 May 2020 13:01:52 +0200 Jiri Pirko wrote:
>> Mon, May 18, 2020 at 10:27:15AM CEST, vasundhara-v.volam@broadcom.com wrote:
>> >This patchset adds support for a "enable_hot_fw_reset" generic devlink
>> >parameter and use it in bnxt_en driver.
>> >
>> >Also, firmware spec. is updated to 1.10.1.40.
>>
>> Hi.
>>
>> We've been discussing this internally for some time.
>> I don't like to use params for this purpose.
>> We already have "devlink dev flash" and "devlink dev reload" commands.
>> Combination of these two with appropriate attributes should provide what
>> you want. The "param" you are introducing is related to either "flash"
>> or "reload", so I don't think it is good to have separate param, when we
>> can extend the command attributes.
>>
>> How does flash&reload work for mlxsw now:
>>
>> # devlink flash
>> Now new version is pending, old FW is running
>> # devlink reload
>> Driver resets the device, new FW is loaded
>>
>> I propose to extend reload like this:
>>
>> devlink dev reload DEV [ level { driver-default | fw-reset | driver-only | fw-live-patch } ]
>> driver-default - means one of following to, according to what is
>> default for the driver
>> fw-reset - does FW reset and driver entities re-instantiation
>> driver-only - does driver entities re-instantiation only
>> fw-live-patch - does only FW live patching - no effect on kernel
>>
>> Could be an enum or bitfield. Does not matter. The point is to use
>> reload with attribute to achieve what user wants. In your usecase, user
>> would do:
>>
>> # devlink flash
>> # devlink reload level fw-live-patch
>
>Unfortunately for SmartNICs and MultiHost systems the reset may not be
>initiated locally. I agree it'd be great to have a normal netlink knob
I don't follow. Locally initiated or not, why what I suggested is not
enough to cover that?
>for this instead of a param. But it has to be some form of a policy of
>allowing the reset to happen, rather than an action/trigger kind of
>thing.
The "host" allows to reset himself by the "smartnic", right? For that, I
can imagine a param. But that is not the case of this patchset.
>
>Also user space notification should be generated when reset happens,
>IMO. devlink dev info contents will likely change after reset, if
>nothing else.
I agree.
>
>Plus this functionality will need proper documentation.
Also agreed.
>
>FWIW - I am unconvinced that applications will be happy to experience
>network black outs, rather than being fully killed and re-spawned. For
>a micro-service worker shutdown + re-spawn should be bread and butter.
>But we already have ionic doing this, so seems like vendors are
>convinced otherwise, so a common interface is probably a good step.
Hmm, not sure I follow what you mean by this para in context of this
patchset. Could you please explain? Thanks!
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 4:31 ` Vasundhara Volam
@ 2020-05-19 5:27 ` Jiri Pirko
2020-05-19 5:43 ` Vasundhara Volam
2020-05-19 7:13 ` Edwin Peer
0 siblings, 2 replies; 19+ messages in thread
From: Jiri Pirko @ 2020-05-19 5:27 UTC (permalink / raw)
To: Vasundhara Volam; +Cc: David Miller, Netdev
Tue, May 19, 2020 at 06:31:27AM CEST, vasundhara-v.volam@broadcom.com wrote:
>On Mon, May 18, 2020 at 4:31 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Mon, May 18, 2020 at 10:27:15AM CEST, vasundhara-v.volam@broadcom.com wrote:
>> >This patchset adds support for a "enable_hot_fw_reset" generic devlink
>> >parameter and use it in bnxt_en driver.
>> >
>> >Also, firmware spec. is updated to 1.10.1.40.
>>
>> Hi.
>>
>> We've been discussing this internally for some time.
>> I don't like to use params for this purpose.
>> We already have "devlink dev flash" and "devlink dev reload" commands.
>> Combination of these two with appropriate attributes should provide what
>> you want. The "param" you are introducing is related to either "flash"
>> or "reload", so I don't think it is good to have separate param, when we
>> can extend the command attributes.
>>
>> How does flash&reload work for mlxsw now:
>>
>> # devlink flash
>> Now new version is pending, old FW is running
>> # devlink reload
>> Driver resets the device, new FW is loaded
>>
>> I propose to extend reload like this:
>>
>> devlink dev reload DEV [ level { driver-default | fw-reset | driver-only | fw-live-patch } ]
>> driver-default - means one of following to, according to what is
>> default for the driver
>> fw-reset - does FW reset and driver entities re-instantiation
>> driver-only - does driver entities re-instantiation only
>> fw-live-patch - does only FW live patching - no effect on kernel
>>
>> Could be an enum or bitfield. Does not matter. The point is to use
>> reload with attribute to achieve what user wants. In your usecase, user
>> would do:
>>
>> # devlink flash
>> # devlink reload level fw-live-patch
>
>Jiri,
>
>I am adding this param to control the fw hot reset capability of the device.
I don't follow, sorry. Could you be more verbose about what you are
trying to achieve here?
>Permanent configuration mode will toggle the NVM config space which is
>very similar to enable_roce/enable_sriov param and runtime configuration
>mode will toggle the driver level knob to avoid/allow fw-live-reset.
>
>From above. I see that you are suggesting how to trigger the fw hot reset.
>This is good to have, but does not serve the purpose of enabling or disabling
>of the feature. Our driver is currently using "ethtool --reset" for
>triggering fw-reset
>or fw-live-patch.
>
>Thanks,
>Vasundhara
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 5:27 ` Jiri Pirko
@ 2020-05-19 5:43 ` Vasundhara Volam
2020-05-19 7:30 ` Jiri Pirko
2020-05-19 7:13 ` Edwin Peer
1 sibling, 1 reply; 19+ messages in thread
From: Vasundhara Volam @ 2020-05-19 5:43 UTC (permalink / raw)
To: Jiri Pirko; +Cc: David Miller, Netdev
On Tue, May 19, 2020 at 10:57 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Tue, May 19, 2020 at 06:31:27AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >On Mon, May 18, 2020 at 4:31 PM Jiri Pirko <jiri@resnulli.us> wrote:
> >>
> >> Mon, May 18, 2020 at 10:27:15AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >> >This patchset adds support for a "enable_hot_fw_reset" generic devlink
> >> >parameter and use it in bnxt_en driver.
> >> >
> >> >Also, firmware spec. is updated to 1.10.1.40.
> >>
> >> Hi.
> >>
> >> We've been discussing this internally for some time.
> >> I don't like to use params for this purpose.
> >> We already have "devlink dev flash" and "devlink dev reload" commands.
> >> Combination of these two with appropriate attributes should provide what
> >> you want. The "param" you are introducing is related to either "flash"
> >> or "reload", so I don't think it is good to have separate param, when we
> >> can extend the command attributes.
> >>
> >> How does flash&reload work for mlxsw now:
> >>
> >> # devlink flash
> >> Now new version is pending, old FW is running
> >> # devlink reload
> >> Driver resets the device, new FW is loaded
> >>
> >> I propose to extend reload like this:
> >>
> >> devlink dev reload DEV [ level { driver-default | fw-reset | driver-only | fw-live-patch } ]
> >> driver-default - means one of following to, according to what is
> >> default for the driver
> >> fw-reset - does FW reset and driver entities re-instantiation
> >> driver-only - does driver entities re-instantiation only
> >> fw-live-patch - does only FW live patching - no effect on kernel
> >>
> >> Could be an enum or bitfield. Does not matter. The point is to use
> >> reload with attribute to achieve what user wants. In your usecase, user
> >> would do:
> >>
> >> # devlink flash
> >> # devlink reload level fw-live-patch
> >
> >Jiri,
> >
> >I am adding this param to control the fw hot reset capability of the device.
>
> I don't follow, sorry. Could you be more verbose about what you are
> trying to achieve here?
As mentioned below, hot_fw_reset is a device capability similar to roce.
Capability can be enabled or disabled on the device, if the device supports.
When enabled and if supported firmware and driver are loaded, user can
utilise the capability to fw_reset or fw_live_patch.
So, we need a policy to enable/disable the capability.
Thanks.
>
> >Permanent configuration mode will toggle the NVM config space which is
> >very similar to enable_roce/enable_sriov param and runtime configuration
> >mode will toggle the driver level knob to avoid/allow fw-live-reset.
> >
> >From above. I see that you are suggesting how to trigger the fw hot reset.
> >This is good to have, but does not serve the purpose of enabling or disabling
> >of the feature. Our driver is currently using "ethtool --reset" for
> >triggering fw-reset
> >or fw-live-patch.
> >
> >Thanks,
> >Vasundhara
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 5:27 ` Jiri Pirko
2020-05-19 5:43 ` Vasundhara Volam
@ 2020-05-19 7:13 ` Edwin Peer
2020-05-19 7:29 ` Jiri Pirko
1 sibling, 1 reply; 19+ messages in thread
From: Edwin Peer @ 2020-05-19 7:13 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Vasundhara Volam, David Miller, Netdev
On Mon, May 18, 2020 at 10:27 PM Jiri Pirko <jiri@resnulli.us> wrote:
> >I am adding this param to control the fw hot reset capability of the device.
>
> I don't follow, sorry. Could you be more verbose about what you are
> trying to achieve here?
Hi Jiri,
Vasundhara is not adding a mechanism to trigger the actual reset here.
This is a parameter to enable or disable the hot reset functionality.
It's configuration, not an action.
Regards,
Edwin Peer
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 7:13 ` Edwin Peer
@ 2020-05-19 7:29 ` Jiri Pirko
0 siblings, 0 replies; 19+ messages in thread
From: Jiri Pirko @ 2020-05-19 7:29 UTC (permalink / raw)
To: Edwin Peer; +Cc: Vasundhara Volam, David Miller, Netdev
Tue, May 19, 2020 at 09:13:46AM CEST, edwin.peer@broadcom.com wrote:
>On Mon, May 18, 2020 at 10:27 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
>> >I am adding this param to control the fw hot reset capability of the device.
>>
>> I don't follow, sorry. Could you be more verbose about what you are
>> trying to achieve here?
>
>Hi Jiri,
>
>Vasundhara is not adding a mechanism to trigger the actual reset here.
>This is a parameter to enable or disable the hot reset functionality.
>It's configuration, not an action.
I understand is it not an action.
But I think I missed what exactly it configures. I still don't have a
clue.
>
>Regards,
>Edwin Peer
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 5:43 ` Vasundhara Volam
@ 2020-05-19 7:30 ` Jiri Pirko
2020-05-19 8:41 ` Michael Chan
0 siblings, 1 reply; 19+ messages in thread
From: Jiri Pirko @ 2020-05-19 7:30 UTC (permalink / raw)
To: Vasundhara Volam; +Cc: David Miller, Netdev
Tue, May 19, 2020 at 07:43:01AM CEST, vasundhara-v.volam@broadcom.com wrote:
>On Tue, May 19, 2020 at 10:57 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Tue, May 19, 2020 at 06:31:27AM CEST, vasundhara-v.volam@broadcom.com wrote:
>> >On Mon, May 18, 2020 at 4:31 PM Jiri Pirko <jiri@resnulli.us> wrote:
>> >>
>> >> Mon, May 18, 2020 at 10:27:15AM CEST, vasundhara-v.volam@broadcom.com wrote:
>> >> >This patchset adds support for a "enable_hot_fw_reset" generic devlink
>> >> >parameter and use it in bnxt_en driver.
>> >> >
>> >> >Also, firmware spec. is updated to 1.10.1.40.
>> >>
>> >> Hi.
>> >>
>> >> We've been discussing this internally for some time.
>> >> I don't like to use params for this purpose.
>> >> We already have "devlink dev flash" and "devlink dev reload" commands.
>> >> Combination of these two with appropriate attributes should provide what
>> >> you want. The "param" you are introducing is related to either "flash"
>> >> or "reload", so I don't think it is good to have separate param, when we
>> >> can extend the command attributes.
>> >>
>> >> How does flash&reload work for mlxsw now:
>> >>
>> >> # devlink flash
>> >> Now new version is pending, old FW is running
>> >> # devlink reload
>> >> Driver resets the device, new FW is loaded
>> >>
>> >> I propose to extend reload like this:
>> >>
>> >> devlink dev reload DEV [ level { driver-default | fw-reset | driver-only | fw-live-patch } ]
>> >> driver-default - means one of following to, according to what is
>> >> default for the driver
>> >> fw-reset - does FW reset and driver entities re-instantiation
>> >> driver-only - does driver entities re-instantiation only
>> >> fw-live-patch - does only FW live patching - no effect on kernel
>> >>
>> >> Could be an enum or bitfield. Does not matter. The point is to use
>> >> reload with attribute to achieve what user wants. In your usecase, user
>> >> would do:
>> >>
>> >> # devlink flash
>> >> # devlink reload level fw-live-patch
>> >
>> >Jiri,
>> >
>> >I am adding this param to control the fw hot reset capability of the device.
>>
>> I don't follow, sorry. Could you be more verbose about what you are
>> trying to achieve here?
>As mentioned below, hot_fw_reset is a device capability similar to roce.
>Capability can be enabled or disabled on the device, if the device supports.
>When enabled and if supported firmware and driver are loaded, user can
>utilise the capability to fw_reset or fw_live_patch.
I don't undestand what exactly is this supposed to enable/disable. Could
you be more specific?
>
>So, we need a policy to enable/disable the capability.
>
>Thanks.
>>
>> >Permanent configuration mode will toggle the NVM config space which is
>> >very similar to enable_roce/enable_sriov param and runtime configuration
>> >mode will toggle the driver level knob to avoid/allow fw-live-reset.
>> >
>> >From above. I see that you are suggesting how to trigger the fw hot reset.
>> >This is good to have, but does not serve the purpose of enabling or disabling
>> >of the feature. Our driver is currently using "ethtool --reset" for
>> >triggering fw-reset
>> >or fw-live-patch.
>> >
>> >Thanks,
>> >Vasundhara
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 7:30 ` Jiri Pirko
@ 2020-05-19 8:41 ` Michael Chan
2020-05-19 9:41 ` Jiri Pirko
0 siblings, 1 reply; 19+ messages in thread
From: Michael Chan @ 2020-05-19 8:41 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Vasundhara Volam, David Miller, Netdev
On Tue, May 19, 2020 at 12:30 AM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Tue, May 19, 2020 at 07:43:01AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >On Tue, May 19, 2020 at 10:57 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >>
> >> I don't follow, sorry. Could you be more verbose about what you are
> >> trying to achieve here?
> >As mentioned below, hot_fw_reset is a device capability similar to roce.
> >Capability can be enabled or disabled on the device, if the device supports.
> >When enabled and if supported firmware and driver are loaded, user can
> >utilise the capability to fw_reset or fw_live_patch.
>
> I don't undestand what exactly is this supposed to enable/disable. Could
> you be more specific?
Let me see if I can help clarify. Here's a little background. Hot
reset is a feature supported by the firmware and requires the
coordinated support of all function drivers. The firmware will only
initiate this hot reset when all function drivers can support it. For
example, if one function is running a really old driver that doesn't
support it, the firmware will not support this until this old driver
gets unloaded or upgraded. Until then, a PCI reset is needed to reset
the firmware.
Now, let's say one function driver that normally supports this
firmware hot reset now wants to disable this feature. For example,
the function is running a mission critical application and does not
want any hot firmware reset that may cause a hiccup during this time.
It will use this devlink parameter to disable it. When the critical
app is done, it can then re-enable the parameter. Of course other
functions can also disable it and it is only enabled when all
functions have enabled it.
Hope this clarifies it. Thanks.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 8:41 ` Michael Chan
@ 2020-05-19 9:41 ` Jiri Pirko
2020-05-19 10:50 ` Vasundhara Volam
0 siblings, 1 reply; 19+ messages in thread
From: Jiri Pirko @ 2020-05-19 9:41 UTC (permalink / raw)
To: Michael Chan; +Cc: Vasundhara Volam, David Miller, Netdev
Tue, May 19, 2020 at 10:41:44AM CEST, michael.chan@broadcom.com wrote:
>On Tue, May 19, 2020 at 12:30 AM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Tue, May 19, 2020 at 07:43:01AM CEST, vasundhara-v.volam@broadcom.com wrote:
>> >On Tue, May 19, 2020 at 10:57 AM Jiri Pirko <jiri@resnulli.us> wrote:
>> >>
>> >> I don't follow, sorry. Could you be more verbose about what you are
>> >> trying to achieve here?
>> >As mentioned below, hot_fw_reset is a device capability similar to roce.
>> >Capability can be enabled or disabled on the device, if the device supports.
>> >When enabled and if supported firmware and driver are loaded, user can
>> >utilise the capability to fw_reset or fw_live_patch.
>>
>> I don't undestand what exactly is this supposed to enable/disable. Could
>> you be more specific?
>
>Let me see if I can help clarify. Here's a little background. Hot
>reset is a feature supported by the firmware and requires the
>coordinated support of all function drivers. The firmware will only
>initiate this hot reset when all function drivers can support it. For
>example, if one function is running a really old driver that doesn't
>support it, the firmware will not support this until this old driver
>gets unloaded or upgraded. Until then, a PCI reset is needed to reset
>the firmware.
>
>Now, let's say one function driver that normally supports this
>firmware hot reset now wants to disable this feature. For example,
>the function is running a mission critical application and does not
>want any hot firmware reset that may cause a hiccup during this time.
>It will use this devlink parameter to disable it. When the critical
>app is done, it can then re-enable the parameter. Of course other
>functions can also disable it and it is only enabled when all
>functions have enabled it.
>
>Hope this clarifies it. Thanks.
Okay. So this is about the "allowing to be reseted from the outside".
I see. For that I think it makes sense to have the devlink param.
However, I think that it would be fine to find more suitable name and
describe this properly in the docs.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 9:41 ` Jiri Pirko
@ 2020-05-19 10:50 ` Vasundhara Volam
2020-05-19 13:25 ` Jiri Pirko
0 siblings, 1 reply; 19+ messages in thread
From: Vasundhara Volam @ 2020-05-19 10:50 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Michael Chan, David Miller, Netdev
On Tue, May 19, 2020 at 3:11 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Tue, May 19, 2020 at 10:41:44AM CEST, michael.chan@broadcom.com wrote:
> >On Tue, May 19, 2020 at 12:30 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >>
> >> Tue, May 19, 2020 at 07:43:01AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >> >On Tue, May 19, 2020 at 10:57 AM Jiri Pirko <jiri@resnulli.us> wrote:
> >> >>
> >> >> I don't follow, sorry. Could you be more verbose about what you are
> >> >> trying to achieve here?
> >> >As mentioned below, hot_fw_reset is a device capability similar to roce.
> >> >Capability can be enabled or disabled on the device, if the device supports.
> >> >When enabled and if supported firmware and driver are loaded, user can
> >> >utilise the capability to fw_reset or fw_live_patch.
> >>
> >> I don't undestand what exactly is this supposed to enable/disable. Could
> >> you be more specific?
> >
> >Let me see if I can help clarify. Here's a little background. Hot
> >reset is a feature supported by the firmware and requires the
> >coordinated support of all function drivers. The firmware will only
> >initiate this hot reset when all function drivers can support it. For
> >example, if one function is running a really old driver that doesn't
> >support it, the firmware will not support this until this old driver
> >gets unloaded or upgraded. Until then, a PCI reset is needed to reset
> >the firmware.
> >
> >Now, let's say one function driver that normally supports this
> >firmware hot reset now wants to disable this feature. For example,
> >the function is running a mission critical application and does not
> >want any hot firmware reset that may cause a hiccup during this time.
> >It will use this devlink parameter to disable it. When the critical
> >app is done, it can then re-enable the parameter. Of course other
> >functions can also disable it and it is only enabled when all
> >functions have enabled it.
> >
> >Hope this clarifies it. Thanks.
>
> Okay. So this is about the "allowing to be reseted from the outside".
> I see. For that I think it makes sense to have the devlink param.
> However, I think that it would be fine to find more suitable name and
> describe this properly in the docs.
>
I felt enable_hot_fw_reset is a self-descriptive name.
But to make it more common, is the name enable_live_fw_reset good?
or simply fw_reset?
Thanks.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 10:50 ` Vasundhara Volam
@ 2020-05-19 13:25 ` Jiri Pirko
0 siblings, 0 replies; 19+ messages in thread
From: Jiri Pirko @ 2020-05-19 13:25 UTC (permalink / raw)
To: Vasundhara Volam; +Cc: Michael Chan, David Miller, Netdev
Tue, May 19, 2020 at 12:50:14PM CEST, vasundhara-v.volam@broadcom.com wrote:
>On Tue, May 19, 2020 at 3:11 PM Jiri Pirko <jiri@resnulli.us> wrote:
>>
>> Tue, May 19, 2020 at 10:41:44AM CEST, michael.chan@broadcom.com wrote:
>> >On Tue, May 19, 2020 at 12:30 AM Jiri Pirko <jiri@resnulli.us> wrote:
>> >>
>> >> Tue, May 19, 2020 at 07:43:01AM CEST, vasundhara-v.volam@broadcom.com wrote:
>> >> >On Tue, May 19, 2020 at 10:57 AM Jiri Pirko <jiri@resnulli.us> wrote:
>> >> >>
>> >> >> I don't follow, sorry. Could you be more verbose about what you are
>> >> >> trying to achieve here?
>> >> >As mentioned below, hot_fw_reset is a device capability similar to roce.
>> >> >Capability can be enabled or disabled on the device, if the device supports.
>> >> >When enabled and if supported firmware and driver are loaded, user can
>> >> >utilise the capability to fw_reset or fw_live_patch.
>> >>
>> >> I don't undestand what exactly is this supposed to enable/disable. Could
>> >> you be more specific?
>> >
>> >Let me see if I can help clarify. Here's a little background. Hot
>> >reset is a feature supported by the firmware and requires the
>> >coordinated support of all function drivers. The firmware will only
>> >initiate this hot reset when all function drivers can support it. For
>> >example, if one function is running a really old driver that doesn't
>> >support it, the firmware will not support this until this old driver
>> >gets unloaded or upgraded. Until then, a PCI reset is needed to reset
>> >the firmware.
>> >
>> >Now, let's say one function driver that normally supports this
>> >firmware hot reset now wants to disable this feature. For example,
>> >the function is running a mission critical application and does not
>> >want any hot firmware reset that may cause a hiccup during this time.
>> >It will use this devlink parameter to disable it. When the critical
>> >app is done, it can then re-enable the parameter. Of course other
>> >functions can also disable it and it is only enabled when all
>> >functions have enabled it.
>> >
>> >Hope this clarifies it. Thanks.
>>
>> Okay. So this is about the "allowing to be reseted from the outside".
>> I see. For that I think it makes sense to have the devlink param.
>
>> However, I think that it would be fine to find more suitable name and
>> describe this properly in the docs.
>>
>I felt enable_hot_fw_reset is a self-descriptive name.
>
>But to make it more common, is the name enable_live_fw_reset good?
>or simply fw_reset?
I think it is important to emhasize that this setting is related to
"remote" reset.
>
>Thanks.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter
2020-05-19 5:24 ` Jiri Pirko
@ 2020-05-19 17:44 ` Jakub Kicinski
0 siblings, 0 replies; 19+ messages in thread
From: Jakub Kicinski @ 2020-05-19 17:44 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Vasundhara Volam, davem, netdev
On Tue, 19 May 2020 07:24:00 +0200 Jiri Pirko wrote:
> Tue, May 19, 2020 at 01:43:09AM CEST, kuba@kernel.org wrote:
> >On Mon, 18 May 2020 13:01:52 +0200 Jiri Pirko wrote:
> >> Mon, May 18, 2020 at 10:27:15AM CEST, vasundhara-v.volam@broadcom.com wrote:
> >> >This patchset adds support for a "enable_hot_fw_reset" generic devlink
> >> >parameter and use it in bnxt_en driver.
> >> >
> >> >Also, firmware spec. is updated to 1.10.1.40.
> >>
> >> Hi.
> >>
> >> We've been discussing this internally for some time.
> >> I don't like to use params for this purpose.
> >> We already have "devlink dev flash" and "devlink dev reload" commands.
> >> Combination of these two with appropriate attributes should provide what
> >> you want. The "param" you are introducing is related to either "flash"
> >> or "reload", so I don't think it is good to have separate param, when we
> >> can extend the command attributes.
> >>
> >> How does flash&reload work for mlxsw now:
> >>
> >> # devlink flash
> >> Now new version is pending, old FW is running
> >> # devlink reload
> >> Driver resets the device, new FW is loaded
> >>
> >> I propose to extend reload like this:
> >>
> >> devlink dev reload DEV [ level { driver-default | fw-reset | driver-only | fw-live-patch } ]
> >> driver-default - means one of following to, according to what is
> >> default for the driver
> >> fw-reset - does FW reset and driver entities re-instantiation
> >> driver-only - does driver entities re-instantiation only
> >> fw-live-patch - does only FW live patching - no effect on kernel
> >>
> >> Could be an enum or bitfield. Does not matter. The point is to use
> >> reload with attribute to achieve what user wants. In your usecase, user
> >> would do:
> >>
> >> # devlink flash
> >> # devlink reload level fw-live-patch
> >
> >Unfortunately for SmartNICs and MultiHost systems the reset may not be
> >initiated locally. I agree it'd be great to have a normal netlink knob
>
> I don't follow. Locally initiated or not, why what I suggested is not
> enough to cover that?
Hopefully clear now after Michael's explanation :)
> >for this instead of a param. But it has to be some form of a policy of
> >allowing the reset to happen, rather than an action/trigger kind of
> >thing.
>
> The "host" allows to reset himself by the "smartnic", right? For that, I
> can imagine a param. But that is not the case of this patchset.
>
> >Also user space notification should be generated when reset happens,
> >IMO. devlink dev info contents will likely change after reset, if
> >nothing else.
>
> I agree.
>
> >Plus this functionality will need proper documentation.
>
> Also agreed.
>
> >FWIW - I am unconvinced that applications will be happy to experience
> >network black outs, rather than being fully killed and re-spawned. For
> >a micro-service worker shutdown + re-spawn should be bread and butter.
> >But we already have ionic doing this, so seems like vendors are
> >convinced otherwise, so a common interface is probably a good step.
>
> Hmm, not sure I follow what you mean by this para in context of this
> patchset. Could you please explain? Thanks!
I'm saying I'm dubious users will actually enable the async remote
reset.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2020-05-19 17:45 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-18 8:27 [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 1/4] devlink: Add new "enable_hot_fw_reset" generic device parameter Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 2/4] bnxt_en: Update firmware spec. to 1.10.1.40 Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 3/4] bnxt_en: Use enable_hot_fw_reset generic devlink parameter Vasundhara Volam
2020-05-18 8:27 ` [PATCH net-next 4/4] bnxt_en: Check if hot_fw_reset is allowed before doing ETHTOOL_RESET Vasundhara Volam
2020-05-18 11:01 ` [PATCH net-next 0/4] bnxt_en: Add new "enable_hot_fw_reset" generic devlink parameter Jiri Pirko
2020-05-18 23:43 ` Jakub Kicinski
2020-05-19 5:24 ` Jiri Pirko
2020-05-19 17:44 ` Jakub Kicinski
2020-05-19 4:31 ` Vasundhara Volam
2020-05-19 5:27 ` Jiri Pirko
2020-05-19 5:43 ` Vasundhara Volam
2020-05-19 7:30 ` Jiri Pirko
2020-05-19 8:41 ` Michael Chan
2020-05-19 9:41 ` Jiri Pirko
2020-05-19 10:50 ` Vasundhara Volam
2020-05-19 13:25 ` Jiri Pirko
2020-05-19 7:13 ` Edwin Peer
2020-05-19 7:29 ` Jiri Pirko
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.