Re: [PATCH net-next 02/16] devlink: Add reload action option to devlink reload command

[Jacob Keller <jacob.e.keller@intel.com>]

On 10/1/2020 6:59 AM, Moshe Shemesh wrote:
> Add devlink reload action to allow the user to request a specific reload
> action. The action parameter is optional, if not specified then devlink
> driver re-init action is used (backward compatible).
> Note that when required to do firmware activation some drivers may need
> to reload the driver. On the other hand some drivers may need to reset
> the firmware to reinitialize the driver entities. Therefore, the devlink
> reload command returns the actions which were actually performed.
> Reload actions supported are:
> driver_reinit: driver entities re-initialization, applying devlink-param
>                and devlink-resource values.
> fw_activate: firmware activate.
> 
> command examples:
> $devlink dev reload pci/0000:82:00.0 action driver_reinit
> reload_actions_performed:
>   driver_reinit
> 
> $devlink dev reload pci/0000:82:00.0 action fw_activate
> reload_actions_performed:
>   driver_reinit fw_activate
> 
> Signed-off-by: Moshe Shemesh <moshe@mellanox.com>

Looks straight forward.

Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>

> ---
> RFCv5 -> v1:
> - Rename supported_reload_actions to reload_actions.
> - Rename devlink_nl_reload_actions_performed_fill() to
> devlink_nl_reload_actions_performed_snd() and add genlmsg_reply() to it
> - Actions_performed sent to user space as a mask
> - Driver can initialize actions_performed before done as devlink ignores
> in case of failure
> - Use nla_poilcy range validation and remove the range check in
> devlink_nl_cmd_reload
> RFCv4 -> RFCv5:
> - Always pass actions_performed to unload_up() instead of checking in
>   each driver
> - Verify returned actions_performed includes the requested action
> - Changed  devlink_reload_actions_verify(devlink) to get ops
> - Changed  devlink_reload_actions_verify() to return bool and rename to
>   devlink_reload_actions_valid()
> -  Only generate the reply if request uses new attributes
> RFCv3 -> RFCv4:
> - Removed fw_activate_no_reset as an action (next patch adds limit
>   levels instead).
> - Renamed actions_done to actions_performed
> RFCv2 -> RFCv3:
> - Replace fw_live_patch action by fw_activate_no_reset
> - Devlink reload returns the actions done over netlink reply
> RFCv1 -> RFCv2:
> - Instead of reload levels driver,fw_reset,fw_live_patch have reload
>   actions driver_reinit,fw_activate,fw_live_patch
> - Remove driver default level, the action driver_reinit is the default
>   action for all drivers
> ---
>  drivers/net/ethernet/mellanox/mlx4/main.c     |   7 +-
>  .../net/ethernet/mellanox/mlx5/core/devlink.c |   7 +-
>  drivers/net/ethernet/mellanox/mlxsw/core.c    |  11 +-
>  drivers/net/netdevsim/dev.c                   |   8 +-
>  include/net/devlink.h                         |   7 +-
>  include/uapi/linux/devlink.h                  |  18 ++++
>  net/core/devlink.c                            | 101 ++++++++++++++++--
>  7 files changed, 139 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
> index 70cf24ba71e4..a44d8b733db3 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/main.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/main.c
> @@ -3946,6 +3946,7 @@ static int mlx4_restart_one_up(struct pci_dev *pdev, bool reload,
>  			       struct devlink *devlink);
>  
>  static int mlx4_devlink_reload_down(struct devlink *devlink, bool netns_change,
> +				    enum devlink_reload_action action,
>  				    struct netlink_ext_ack *extack)
>  {

I might have opted to convert reload_down to take a structure of
parameters, given that we're about to add 2 parameters. Not really that
significant either way.