From patchwork Mon Jul 25 20:56:26 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jacob Keller X-Patchwork-Id: 12928409 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42EE2CCA48D for ; Mon, 25 Jul 2022 20:56:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233717AbiGYU4k (ORCPT ); Mon, 25 Jul 2022 16:56:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230297AbiGYU4i (ORCPT ); Mon, 25 Jul 2022 16:56:38 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E98222BF2; Mon, 25 Jul 2022 13:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658782597; x=1690318597; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=9xVSixPsZx3n7XPRlkOSZ8exLMudRDJcJEqe18N/3Vc=; b=cx+Q47YGhgDUPLZYU+X2RfJArCc5OnDsWWDCOC0q8LFg9jtSx7tzeH2a uxhUJiolfM4C6S6kz6JKx47o79yZnYBjPOtdW5J/x8nAPlXjUfCPp/ZT/ n5citEmgebI1UtdE1EQ+mMlwEnd6ImfBRfdzIkvj3MoO5Hv78+36oImtU LTicPMiVNwxfyWE650vx51qTMeIQBHR5UafbBQueI9jnXuKNo/uS0FKC2 RMKeE1oouPz7r+6at77QxVO2+wQnqlDES1zUrZh5GyxF3JRl1AlbsKBD0 SX0C6ZKaFIw3UZx+3O1KtW+iYwA8DpJnqDu/wpR2AniU9BYIoS3A3XseJ A==; X-IronPort-AV: E=McAfee;i="6400,9594,10419"; a="267564331" X-IronPort-AV: E=Sophos;i="5.93,193,1654585200"; d="scan'208";a="267564331" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2022 13:56:36 -0700 X-IronPort-AV: E=Sophos;i="5.93,193,1654585200"; d="scan'208";a="689191014" Received: from jekeller-desk.amr.corp.intel.com ([10.166.241.7]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2022 13:56:36 -0700 From: Jacob Keller To: netdev@vger.kernel.org Cc: Jacob Keller , Jonathan Corbet , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Tony Nguyen , David Ahern , Stephen Hemminger , linux-doc@vger.kernel.org Subject: [net-next v3 1/4] devlink: add missing kdoc for overwrite mask Date: Mon, 25 Jul 2022 13:56:26 -0700 Message-Id: <20220725205629.3993766-2-jacob.e.keller@intel.com> X-Mailer: git-send-email 2.37.1.208.ge72d93e88cb2 In-Reply-To: <20220725205629.3993766-1-jacob.e.keller@intel.com> References: <20220725205629.3993766-1-jacob.e.keller@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org commit 5d5b4128c4ca ("devlink: introduce flash update overwrite mask") failed to document the overwrite_mask parameter of the devlink_flash_update_params structure. Fix this. Signed-off-by: Jacob Keller Fixes: 5d5b4128c4ca ("devlink: introduce flash update overwrite mask") --- Changes since v2 * Split this change out to its own patch include/net/devlink.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/net/devlink.h b/include/net/devlink.h index 780744b550b8..e2c530b2b67d 100644 --- a/include/net/devlink.h +++ b/include/net/devlink.h @@ -613,6 +613,7 @@ enum devlink_param_generic_id { * struct devlink_flash_update_params - Flash Update parameters * @fw: pointer to the firmware data to update from * @component: the flash component to update + * @overwrite_mask: what sections of flash can be overwritten * * With the exception of fw, drivers must opt-in to parameters by * setting the appropriate bit in the supported_flash_update_params field in From patchwork Mon Jul 25 20:56:27 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jacob Keller X-Patchwork-Id: 12928411 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 96C21C433EF for ; Mon, 25 Jul 2022 20:56:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237138AbiGYU4l (ORCPT ); Mon, 25 Jul 2022 16:56:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233504AbiGYU4k (ORCPT ); Mon, 25 Jul 2022 16:56:40 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 004CD22BEC; Mon, 25 Jul 2022 13:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658782599; x=1690318599; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=zX78jJ7CR7XGyz+paTLOcWWaKnEyAc+elyGYirbq5sw=; b=RW3w6FzeWDuqTDugBXgssT7hIIquqP6c83Oyztw50bWdmEtUixCJVLLE DN40LRBPT+Wx36xog7+t8Ip0Q0RnLoP3cepsLyzLWYmdDDbJz6kUHb56A JAjmHQUkGraRBVj+azqfSQE9GyE3b/AZVD9fodZRybqq3ariWhhyLKQY8 X/TuYPzjqaABU5DY40iHBQWujGLhRdI8tEcy80JSqnBwjdF+qSfUleZvQ dX+O/9AMedRHfVd+mIoWLvU6HfvuDwVYMAitNNsSbZ9besgBz5UWvwkFi 1V1OoWtIAy6N7zCJU9qswqGycg1cGgzJyjEB0D93Ll/+1SZ9BX9ljr5mc A==; X-IronPort-AV: E=McAfee;i="6400,9594,10419"; a="267564332" X-IronPort-AV: E=Sophos;i="5.93,193,1654585200"; d="scan'208";a="267564332" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2022 13:56:37 -0700 X-IronPort-AV: E=Sophos;i="5.93,193,1654585200"; d="scan'208";a="689191017" Received: from jekeller-desk.amr.corp.intel.com ([10.166.241.7]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2022 13:56:36 -0700 From: Jacob Keller To: netdev@vger.kernel.org Cc: Jacob Keller , Jonathan Corbet , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Tony Nguyen , David Ahern , Stephen Hemminger , linux-doc@vger.kernel.org Subject: [net-next v3 2/4] devlink: add dry run attribute to flash update Date: Mon, 25 Jul 2022 13:56:27 -0700 Message-Id: <20220725205629.3993766-3-jacob.e.keller@intel.com> X-Mailer: git-send-email 2.37.1.208.ge72d93e88cb2 In-Reply-To: <20220725205629.3993766-1-jacob.e.keller@intel.com> References: <20220725205629.3993766-1-jacob.e.keller@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org Users use the devlink flash interface to request a device driver program or update the device flash chip. In some cases, a user (or script) may want to verify that a given flash update command is supported without actually committing to immediately updating the device. For example, a system administrator may want to validate that a particular flash binary image will be accepted by the device, or simply validate a command before finally committing to it. The current flash update interface lacks a method to support such a dry run. Add a new DEVLINK_ATTR_DRY_RUN attribute which shall be used by a devlink command to indicate that a request is a dry run which should not perform device configuration. Instead, the command should report whether the command or configuration request is valid. While we can validate the initial arguments of the devlink command, a proper dry run must be processed by the device driver. This is required because only the driver can perform validation of the flash binary file. Add a new dry_run parameter to the devlink_flash_update_params struct, along with the associated bit to indicate if a driver supports verifying a dry run. We always check the dry run attribute last in order to allow as much verification of other parameters as possible. For example, even if a driver does not support the dry_run option, we can still validate the other optional parameters such as the overwrite_mask and per-component update name. Document that userspace should take care when issuing a dry run to older kernels, as the flash update command is not strictly verified. Thus, unknown attributes will be ignored and this could cause a request for a dry run to perform an actual update. We can't fix old kernels to verify unknown attributes, but userspace can check the maximum attribute and reject the dry run request if it is not supported by the kernel. Signed-off-by: Jacob Keller --- Changes since v2 * dropped the comment since this applies to all attributes and is not a new problem. We can discuss what a transition to proper validation looks like on the list and see if we can find a path forward on that. .../networking/devlink/devlink-flash.rst | 23 +++++++++++++++++++ include/net/devlink.h | 3 +++ include/uapi/linux/devlink.h | 2 ++ net/core/devlink.c | 17 +++++++++++++- 4 files changed, 44 insertions(+), 1 deletion(-) diff --git a/Documentation/networking/devlink/devlink-flash.rst b/Documentation/networking/devlink/devlink-flash.rst index 603e732f00cc..1dc373229a54 100644 --- a/Documentation/networking/devlink/devlink-flash.rst +++ b/Documentation/networking/devlink/devlink-flash.rst @@ -44,6 +44,29 @@ preserved across the update. A device may not support every combination and the driver for such a device must reject any combination which cannot be faithfully implemented. +Dry run +======= + +Users can request a "dry run" of a flash update by adding the +``DEVLINK_ATTR_DRY_RUN`` attribute to the ``DEVLINK_CMD_FLASH_UPDATE`` +command. If the attribute is present, the kernel will only verify that the +provided command is valid. During a dry run, an update is not performed. + +If supported by the driver, the flash image contents are also validated and +the driver may indicate whether the file is a valid flash image for the +device. + +.. code:: shell + + $ devlink dev flash pci/0000:af:00.0 file image.bin dry-run + Validating flash binary + +Note that user space should take care when adding this attribute. Older +kernels which do not recognize the attribute may accept the command with an +unknown attribute. This could lead to a request for a dry run which performs +an unexpected update. To avoid this, user space should check the policy dump +and verify that the attribute is recognized before adding it to the command. + Firmware Loading ================ diff --git a/include/net/devlink.h b/include/net/devlink.h index e2c530b2b67d..47b86ccb85b0 100644 --- a/include/net/devlink.h +++ b/include/net/devlink.h @@ -614,6 +614,7 @@ enum devlink_param_generic_id { * @fw: pointer to the firmware data to update from * @component: the flash component to update * @overwrite_mask: what sections of flash can be overwritten + * @dry_run: if true, do not actually update the flash * * With the exception of fw, drivers must opt-in to parameters by * setting the appropriate bit in the supported_flash_update_params field in @@ -623,10 +624,12 @@ struct devlink_flash_update_params { const struct firmware *fw; const char *component; u32 overwrite_mask; + bool dry_run; }; #define DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT BIT(0) #define DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK BIT(1) +#define DEVLINK_SUPPORT_FLASH_UPDATE_DRY_RUN BIT(2) struct devlink_region; struct devlink_info_req; diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h index b3d40a5d72ff..721369ade9d0 100644 --- a/include/uapi/linux/devlink.h +++ b/include/uapi/linux/devlink.h @@ -576,6 +576,8 @@ enum devlink_attr { DEVLINK_ATTR_LINECARD_TYPE, /* string */ DEVLINK_ATTR_LINECARD_SUPPORTED_TYPES, /* nested */ + DEVLINK_ATTR_DRY_RUN, /* flag */ + /* add new attributes above here, update the policy in devlink.c */ __DEVLINK_ATTR_MAX, diff --git a/net/core/devlink.c b/net/core/devlink.c index 98d79feeb3dc..1cff636c9b2b 100644 --- a/net/core/devlink.c +++ b/net/core/devlink.c @@ -4743,7 +4743,8 @@ EXPORT_SYMBOL_GPL(devlink_flash_update_timeout_notify); static int devlink_nl_cmd_flash_update(struct sk_buff *skb, struct genl_info *info) { - struct nlattr *nla_component, *nla_overwrite_mask, *nla_file_name; + struct nlattr *nla_component, *nla_overwrite_mask, *nla_file_name, + *nla_dry_run; struct devlink_flash_update_params params = {}; struct devlink *devlink = info->user_ptr[0]; const char *file_name; @@ -4789,6 +4790,19 @@ static int devlink_nl_cmd_flash_update(struct sk_buff *skb, return ret; } + /* Always check dry run last, in order to allow verification of other + * parameter support even if the particular driver does not yet + * support a full dry-run + */ + params.dry_run = nla_get_flag(info->attrs[DEVLINK_ATTR_DRY_RUN]); + if (params.dry_run && + !(supported_params & DEVLINK_SUPPORT_FLASH_UPDATE_DRY_RUN)) { + NL_SET_ERR_MSG_ATTR(info->extack, nla_dry_run, + "flash update is supported, but dry run is not supported for this device"); + release_firmware(params.fw); + return -EOPNOTSUPP; + } + devlink_flash_update_begin_notify(devlink); ret = devlink->ops->flash_update(devlink, ¶ms, info->extack); devlink_flash_update_end_notify(devlink); @@ -9004,6 +9018,7 @@ static const struct nla_policy devlink_nl_policy[DEVLINK_ATTR_MAX + 1] = { [DEVLINK_ATTR_RATE_PARENT_NODE_NAME] = { .type = NLA_NUL_STRING }, [DEVLINK_ATTR_LINECARD_INDEX] = { .type = NLA_U32 }, [DEVLINK_ATTR_LINECARD_TYPE] = { .type = NLA_NUL_STRING }, + [DEVLINK_ATTR_DRY_RUN] = { .type = NLA_FLAG }, }; static const struct genl_small_ops devlink_nl_ops[] = { From patchwork Mon Jul 25 20:56:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jacob Keller X-Patchwork-Id: 12928412 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82426CCA48A for ; Mon, 25 Jul 2022 20:56:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237222AbiGYU4p (ORCPT ); Mon, 25 Jul 2022 16:56:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237133AbiGYU4l (ORCPT ); Mon, 25 Jul 2022 16:56:41 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 154C522BF2; Mon, 25 Jul 2022 13:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658782600; x=1690318600; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=BNyLVfo5PrO3cul85/39OZl8ZcDQ0DIDuqEiBoEFH+0=; b=axwYOnFqDB6nQAl6QEIrOO0mHqK7d78yGpBsExn5li0uYvdbeb/+qPVe dYLKS5y1RrCrzw8EGiN6xm7QVgPJToJsVpLpEaju4Zcb66jISWOqPhJ09 A2MiwXgx1x83sbW1nwHpM85C76+3MtfDO8xFkQwzSxxrb6Vpekv9Oih+9 B4Jf0guJ/0CliUUUX6cfcRYkWK0nxFlA1Th+XIlh5zJV9fvCLUxnvMQ8f /dRucYwIZj3b4FLk3YvAabtwk23lVeTjpXk6hGoQ7aY4be+kMuSo8cYQG CS0hcd1uD6xYw/SoBu6D2nZucnZD0uuBVauS/KO0pChQvAh52UJNxAoG+ Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10419"; a="267564333" X-IronPort-AV: E=Sophos;i="5.93,193,1654585200"; d="scan'208";a="267564333" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2022 13:56:37 -0700 X-IronPort-AV: E=Sophos;i="5.93,193,1654585200"; d="scan'208";a="689191020" Received: from jekeller-desk.amr.corp.intel.com ([10.166.241.7]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2022 13:56:37 -0700 From: Jacob Keller To: netdev@vger.kernel.org Cc: Jacob Keller , Jonathan Corbet , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Tony Nguyen , David Ahern , Stephen Hemminger , linux-doc@vger.kernel.org Subject: [net-next v3 3/4] pldmfw: offer option to only validate in image but not update Date: Mon, 25 Jul 2022 13:56:28 -0700 Message-Id: <20220725205629.3993766-4-jacob.e.keller@intel.com> X-Mailer: git-send-email 2.37.1.208.ge72d93e88cb2 In-Reply-To: <20220725205629.3993766-1-jacob.e.keller@intel.com> References: <20220725205629.3993766-1-jacob.e.keller@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org Add an "only_validate" bit in the PLDM firmware context configuration to allow requesting validation of a PLDM image. Setting this bit causes the PLDMFW library to stop after finishing validation of the image. No actual update will be performed. Signed-off-by: Jacob Keller --- Changes since v2 * Split PLDMFW changes to their own patch * Fix code and comments still referring to dry_run * Name the parameter "only_validate" instead of validate for clarity Documentation/driver-api/pldmfw/index.rst | 11 +++++++++++ include/linux/pldmfw.h | 5 +++++ lib/pldmfw/pldmfw.c | 12 ++++++++++++ 3 files changed, 28 insertions(+) diff --git a/Documentation/driver-api/pldmfw/index.rst b/Documentation/driver-api/pldmfw/index.rst index ad2c33ece30f..1eca98f642eb 100644 --- a/Documentation/driver-api/pldmfw/index.rst +++ b/Documentation/driver-api/pldmfw/index.rst @@ -51,6 +51,17 @@ unaligned access of multi-byte fields, and to properly convert from Little Endian to CPU host format. Additionally the records, descriptors, and components are stored in linked lists. +Validating a PLDM firmware file +=============================== + +To simply validate a PLDM firmware file, and verify whether it applies to +the device, set the ``only_validate`` flag in the ``pldmfw`` context +structure. If this flag is set, the library will parse the file, validating +its UUID and checking if any record matches the device. Note that in this +mode, the library will *not* issue any ops besides ``match_record``. It will +not attempt to send the component table or package data to the device +firmware. + Performing a flash update ========================= diff --git a/include/linux/pldmfw.h b/include/linux/pldmfw.h index 0fc831338226..820c0e812989 100644 --- a/include/linux/pldmfw.h +++ b/include/linux/pldmfw.h @@ -124,10 +124,15 @@ struct pldmfw_ops; * should embed this in a private structure and use container_of to obtain * a pointer to their own data, used to implement the device specific * operations. + * + * @ops: function pointers used as callbacks from the PLDMFW library + * @dev: pointer to the device being updated + * @only_validate: if true, only validate the file, do not perform an update. */ struct pldmfw { const struct pldmfw_ops *ops; struct device *dev; + u8 only_validate : 1; }; bool pldmfw_op_pci_match_record(struct pldmfw *context, struct pldmfw_record *record); diff --git a/lib/pldmfw/pldmfw.c b/lib/pldmfw/pldmfw.c index 6e77eb6d8e72..cb4a105487bd 100644 --- a/lib/pldmfw/pldmfw.c +++ b/lib/pldmfw/pldmfw.c @@ -827,6 +827,10 @@ static int pldm_finalize_update(struct pldmfw_priv *data) * to the device firmware. Extract and write the flash data for each of the * components indicated in the firmware file. * + * If the context->only_validate bit is set, this is a request to stop after + * validating the image, and do not actually attempt to update the device. If + * this is set, stop and exit after we find a valid matching record. + * * Returns: zero on success, or a negative error code on failure. */ int pldmfw_flash_image(struct pldmfw *context, const struct firmware *fw) @@ -844,14 +848,22 @@ int pldmfw_flash_image(struct pldmfw *context, const struct firmware *fw) data->fw = fw; data->context = context; + /* Parse the image and make sure it is a valid PLDM firmware binary */ err = pldm_parse_image(data); if (err) goto out_release_data; + /* Search for a record matching the device */ err = pldm_find_matching_record(data); if (err) goto out_release_data; + /* If this is only to validate the file, do not perform an update */ + if (context->only_validate) + goto out_release_data; + + /* Perform the device update */ + err = pldm_send_package_data(data); if (err) goto out_release_data; From patchwork Mon Jul 25 20:56:29 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jacob Keller X-Patchwork-Id: 12928413 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0BB36C43334 for ; Mon, 25 Jul 2022 20:56:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233504AbiGYU4q (ORCPT ); Mon, 25 Jul 2022 16:56:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55406 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237162AbiGYU4l (ORCPT ); Mon, 25 Jul 2022 16:56:41 -0400 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54E6D22BEC; Mon, 25 Jul 2022 13:56:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658782600; x=1690318600; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=A96Kbpm3i0SigVaYwn2kdkSZyp9EZD3uB6hgozO9nPQ=; b=DgDzUx97k7VNG41N8xTs5DnGUN3qmoYlAr3BE7HT8yMSrn9+Ox2fxBrx zKtjAjygMsGmaiNM31Axe2rDjLvzNBqR8FEM4uGxW0dzDQtiX+jNr33Tm jszGDF+JKEHJ/yFQf2gfu/MNJFI8KVMHtn56joudC9Lr7fXE8ZjXWVO5c +diuTqF9p20B/qBUBUBSSWLGolUPNZLOLpvJdOg57pjJ2aPksLaWAEL/N HpX8TYIu5bQZ7HOYpynSOpb2sxDNGoyhcbJDlKJAhHE3OMBEunKxOjcTX FkYnSNPwLJ1WQ9IcMob0RoCQbqqKN6cG/e4yBfT6LUmCjlfpzhqBd95Vs g==; X-IronPort-AV: E=McAfee;i="6400,9594,10419"; a="267564335" X-IronPort-AV: E=Sophos;i="5.93,193,1654585200"; d="scan'208";a="267564335" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2022 13:56:37 -0700 X-IronPort-AV: E=Sophos;i="5.93,193,1654585200"; d="scan'208";a="689191024" Received: from jekeller-desk.amr.corp.intel.com ([10.166.241.7]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jul 2022 13:56:37 -0700 From: Jacob Keller To: netdev@vger.kernel.org Cc: Jacob Keller , Jonathan Corbet , Jiri Pirko , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Tony Nguyen , David Ahern , Stephen Hemminger , linux-doc@vger.kernel.org Subject: [net-next v3 4/4] ice: support dry run of a flash update to validate firmware file Date: Mon, 25 Jul 2022 13:56:29 -0700 Message-Id: <20220725205629.3993766-5-jacob.e.keller@intel.com> X-Mailer: git-send-email 2.37.1.208.ge72d93e88cb2 In-Reply-To: <20220725205629.3993766-1-jacob.e.keller@intel.com> References: <20220725205629.3993766-1-jacob.e.keller@intel.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org The devlink core flash update and the PLDMFW library can now handle dry run requests. Update the ice driver to support this feature. Indicate that we support dry runs in the .supported_flash_update_params field. If the dry run is requested, notify the PLDM firmware library by setting the context bit appropriately. Don't cancel a pending update during a dry run. Signed-off-by: Jacob Keller --- Changes since v2 * Move the PLDMFW changes to their own patch drivers/net/ethernet/intel/ice/ice_devlink.c | 3 ++- drivers/net/ethernet/intel/ice/ice_fw_update.c | 14 ++++++++++---- 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_devlink.c b/drivers/net/ethernet/intel/ice/ice_devlink.c index 3337314a7b35..18214ea33e2d 100644 --- a/drivers/net/ethernet/intel/ice/ice_devlink.c +++ b/drivers/net/ethernet/intel/ice/ice_devlink.c @@ -467,7 +467,8 @@ ice_devlink_reload_empr_finish(struct devlink *devlink, } static const struct devlink_ops ice_devlink_ops = { - .supported_flash_update_params = DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK, + .supported_flash_update_params = DEVLINK_SUPPORT_FLASH_UPDATE_OVERWRITE_MASK | + DEVLINK_SUPPORT_FLASH_UPDATE_DRY_RUN, .reload_actions = BIT(DEVLINK_RELOAD_ACTION_FW_ACTIVATE), /* The ice driver currently does not support driver reinit */ .reload_down = ice_devlink_reload_empr_start, diff --git a/drivers/net/ethernet/intel/ice/ice_fw_update.c b/drivers/net/ethernet/intel/ice/ice_fw_update.c index 3dc5662d62a6..51b352bc26a2 100644 --- a/drivers/net/ethernet/intel/ice/ice_fw_update.c +++ b/drivers/net/ethernet/intel/ice/ice_fw_update.c @@ -1015,15 +1015,21 @@ int ice_devlink_flash_update(struct devlink *devlink, else priv.context.ops = &ice_fwu_ops_e810; priv.context.dev = dev; + priv.context.only_validate = params->dry_run; priv.extack = extack; priv.pf = pf; priv.activate_flags = preservation; - devlink_flash_update_status_notify(devlink, "Preparing to flash", NULL, 0, 0); + if (params->dry_run) + devlink_flash_update_status_notify(devlink, "Validating flash binary", NULL, 0, 0); + else + devlink_flash_update_status_notify(devlink, "Preparing to flash", NULL, 0, 0); - err = ice_cancel_pending_update(pf, NULL, extack); - if (err) - return err; + if (!params->dry_run) { + err = ice_cancel_pending_update(pf, NULL, extack); + if (err) + return err; + } err = ice_acquire_nvm(hw, ICE_RES_WRITE); if (err) {