On Tue, Jul 28, 2020 at 10:13 PM Jacob Keller <jacob.e.keller@xxxxxxxxx> wrote:
This seems similar to flashing the firmware and does not reset anything.
On 7/27/2020 10:25 PM, Vasundhara Volam wrote:
On Mon, Jul 27, 2020 at 4:36 PM Moshe Shemesh <moshe@xxxxxxxxxxxx> wrote:So, I think the differentiation here is that "live_patch" doesn't reset
Introduce new option on devlink reload API to enable the user to select theThe Name is a little confusing. I think it should be renamed to
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.
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).
Yes, I got the "reload_down" and "reload_up". Similar to the deviceIn the "reload_down" handler, they would trigger the appropriate reset,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?
and quiesce anything that needs to be done. Then on reload up, it would
restore and bring up anything quiesced in the first stage.
"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