On Wed, 16 Sep 2020 20:02:00 -0700 Shannon Nelson wrote:
> Add a timeout element to the DEVLINK_CMD_FLASH_UPDATE_STATUS
> netlink message for use by a userland utility to show that
> a particular firmware flash activity may take a long but
> bounded time to finish. Also add a handy helper for drivers
> to make use of the new timeout value.
>
> UI usage hints:
> - if non-zero, add timeout display to the end of the status line
> [component] status_msg ( Xm Ys : Am Bs )
> using the timeout value for Am Bs and updating the Xm Ys
> every second
> - if the timeout expires while awaiting the next update,
> display something like
> [component] status_msg ( timeout reached : Am Bs )
> - if new status notify messages are received, remove
> the timeout and start over
>
> Signed-off-by: Shannon Nelson <snel...@pensando.io>
Minor nits, otherwise LGTM:
Reviewed-by: Jakub Kicinski <k...@kernel.org>
> @@ -3052,6 +3054,9 @@ static int devlink_nl_flash_update_fill(struct sk_buff
> *msg,
> if (nla_put_u64_64bit(msg, DEVLINK_ATTR_FLASH_UPDATE_STATUS_TOTAL,
> total, DEVLINK_ATTR_PAD))
> goto nla_put_failure;
> + if (nla_put_u64_64bit(msg, DEVLINK_ATTR_FLASH_UPDATE_STATUS_TIMEOUT,
> + timeout, DEVLINK_ATTR_PAD))
> + goto nla_put_failure;
nit: since old kernels don't report this user space has to deal with it
not being present so I'd be tempted to only report it if timeout
is not 0
> +void devlink_flash_update_timeout_notify(struct devlink *devlink,
> + const char *status_msg,
> + const char *component,
> + unsigned long timeout)
> +{
> + __devlink_flash_update_notify(devlink,
> + DEVLINK_CMD_FLASH_UPDATE_STATUS,
> + status_msg, component, 0, 0, timeout);
nit: did we ever report cmd == UPDATE_STATUS and total == 0?
could this cause a division by zero in some unsuspecting
implementation? Perhaps we should pass 1 here?
> +}
> +EXPORT_SYMBOL_GPL(devlink_flash_update_timeout_notify);
