From: Jacob Keller <jacob.e.keller@intel.com>
To: netdev@vger.kernel.org, Jiri Pirko <jiri@resnulli.us>,
Jakub Kicinski <kuba@kernel.org>
Cc: Jakub Kicinski <kubakici@wp.pl>, Jiri Pirko <jiri@resnulli.us>,
Tom Herbert <tom@herbertland.com>
Subject: Re: [RFC PATCH net-next v2 5/6] ice: implement device flash update via devlink
Date: Thu, 23 Jul 2020 16:33:12 -0700 [thread overview]
Message-ID: <45bd606f-e0bf-de8b-7e1f-5bd01aa07618@intel.com> (raw)
In-Reply-To: <20200717183541.797878-6-jacob.e.keller@intel.com>
On 7/17/2020 11:35 AM, Jacob Keller wrote:
> + devlink_flash_update_begin_notify(devlink);
> + devlink_flash_update_status_notify(devlink, "Preparing to flash",
> + component, 0, 0);
> + err = ice_flash_pldm_image(pf, fw, extack);
> + devlink_flash_update_end_notify(devlink);
> +
> + release_firmware(fw);
> +
> + return err;
> +}
> +
Hi Jakub, Jiri,
I noticed something interesting recently in regards to the
devlink_flash_update_end_notify.
The way that iproute2/devlink works is that if
DEVLINK_CMD_FLASH_UPDATE_END is sent, then it will stop waiting for the
error response from DEVLINK_CMD_FLASH_UPDATE.
This means that if a driver sends DEVLINK_CMD_FLASH_UPDATE_END on a
failed update, the devlink program doesn't report the error or the
netlink status message.
Is it expected to send DEVLINK_CMD_FLASH_UPDATE_END on failures? All
current drivers appear to do so.
Perhaps its a bug in the devlink application on not waiting for the
flash command to properly complete?
Would it make sense to extend DEVLINK_FLASH_UPDATE_END to include an
attribute which specified the error code? But then would that include
the netlink extended status message?
It's not a huge deal but it seemed weird that if we detect any errors
during the main flash update process we will not properly report them.
I wasn't quite sure where the bug actually lies, so help here is
appreciated on figuring out what the best fix is.
Regards,
Jake
next prev parent reply other threads:[~2020-07-23 23:33 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 18:35 [RFC PATCH net-next v2 0/6] introduce PLDM firmware update library Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 1/6] ice: Add support for unified NVM update flow capability Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 2/6] ice: Add AdminQ commands for FW update Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 3/6] ice: add flags indicating pending update of firmware module Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 4/6] Add pldmfw library for PLDM firmware update Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 5/6] ice: implement device flash update via devlink Jacob Keller
2020-07-20 5:26 ` kernel test robot
2020-07-23 23:33 ` Jacob Keller [this message]
2020-07-17 18:35 ` [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash update Jacob Keller
2020-07-20 10:09 ` Jiri Pirko
2020-07-20 15:51 ` Jakub Kicinski
2020-07-20 18:52 ` Jacob Keller
2020-07-21 13:56 ` Jiri Pirko
2020-07-21 17:28 ` Jacob Keller
2020-07-21 13:53 ` Jiri Pirko
2020-07-21 17:04 ` Jakub Kicinski
2020-07-21 17:31 ` Jacob Keller
2020-07-22 10:51 ` Jiri Pirko
2020-07-22 15:30 ` Keller, Jacob E
2020-07-22 16:52 ` Jakub Kicinski
2020-07-22 18:21 ` Jacob Keller
2020-07-26 7:18 ` Jiri Pirko
2020-07-27 18:11 ` Jacob Keller
2020-07-29 22:49 ` Jacob Keller
2020-07-29 23:16 ` Jakub Kicinski
2020-07-29 23:59 ` Jacob Keller
2020-07-26 7:16 ` Jiri Pirko
2020-07-27 18:13 ` Jacob Keller
2020-07-28 11:19 ` Jiri Pirko
2020-07-28 16:58 ` Jacob Keller
2020-07-28 17:09 ` Jakub Kicinski
2020-07-28 17:43 ` Jacob Keller
2020-07-28 22:59 ` Jacob Keller
2020-07-17 19:58 ` [RFC PATCH net-next v2 0/6] introduce PLDM firmware update library Jakub Kicinski
2020-07-17 21:00 ` Keller, Jacob E
2020-07-17 21:08 ` Keller, Jacob E
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45bd606f-e0bf-de8b-7e1f-5bd01aa07618@intel.com \
--to=jacob.e.keller@intel.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=kubakici@wp.pl \
--cc=netdev@vger.kernel.org \
--cc=tom@herbertland.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.