On Tue, Jul 28, 2020 at 10:13 PM Jacob Keller <jacob.e.kel...@intel.com> wrote: > > > > On 7/27/2020 10:25 PM, Vasundhara Volam wrote: > > On Mon, Jul 27, 2020 at 4:36 PM Moshe Shemesh <mo...@mellanox.com> wrote: > >> > >> Introduce new option on devlink reload API to enable the user to select the > >> reload level required. Complete support for all levels in mlx5. > >> The following reload levels are supported: > >> driver: Driver entities re-instantiation only. > >> fw_reset: Firmware reset and driver entities re-instantiation. > > The Name is a little confusing. I think it should be renamed to > > fw_live_reset (in which both firmware and driver entities are > > re-instantiated). For only fw_reset, the driver should not undergo > > reset (it requires a driver reload for firmware to undergo reset). > > > > So, I think the differentiation here is that "live_patch" doesn't reset > anything. This seems similar to flashing the firmware and does not reset anything.
> > >> fw_live_patch: Firmware live patching only. > > This level is not clear. Is this similar to flashing?? > > > > Also I have a basic query. The reload command is split into > > reload_up/reload_down handlers (Please correct me if this behaviour is > > changed with this patchset). What if the vendor specific driver does > > not support up/down and needs only a single handler to fire a firmware > > reset or firmware live reset command? > > In the "reload_down" handler, they would trigger the appropriate reset, > and quiesce anything that needs to be done. Then on reload up, it would > restore and bring up anything quiesced in the first stage. Yes, I got the "reload_down" and "reload_up". Similar to the device "remove" and "re-probe" respectively. But our requirement is a similar "ethtool reset" command, where ethtool calls a single callback in driver and driver just sends a firmware command for doing the reset. Once firmware receives the command, it will initiate the reset of driver and firmware entities asynchronously.
