Mon, Sep 14, 2020 at 09:08:58AM CEST, vasundhara-v.vo...@broadcom.com wrote: >On Mon, Sep 14, 2020 at 11:39 AM Moshe Shemesh <mo...@mellanox.com> wrote:
[...] >> @@ -1126,15 +1126,24 @@ mlxsw_devlink_core_bus_device_reload_down(struct >> devlink *devlink, >> } >> >> static int >> -mlxsw_devlink_core_bus_device_reload_up(struct devlink *devlink, >> - struct netlink_ext_ack *extack) >> +mlxsw_devlink_core_bus_device_reload_up(struct devlink *devlink, enum >> devlink_reload_action action, >> + struct netlink_ext_ack *extack, >> + unsigned long *actions_performed) >Sorry for repeating again, for fw_activate action on our device, all >the driver entities undergo reset asynchronously once user initiates >"devlink dev reload action fw_activate" and reload_up does not have >much to do except reporting actions that will be/being performed. > >Once reset is complete, the health reporter will be notified using Hmm, how is the fw reset related to health reporter recovery? Recovery happens after some error event. I don't believe it is wise to mix it. Instead, why don't you block in reload_up() until the reset is complete? >devlink_health_reporter_recovery_done(). Returning from reload_up does >not guarantee successful activation of firmware. Status of reset will >be notified to the health reporter via >devlink_health_reporter_state_update(). > >I am just repeating this, so I want to know if I am on the same page. > >Thanks. [...]
