On 7/29/2020 11:57 PM, Jakub Kicinski wrote:
On Wed, 29 Jul 2020 17:42:12 +0300 Moshe Shemesh wrote:
On 7/28/2020 3:59 AM, Jakub Kicinski wrote:
On Mon, 27 Jul 2020 14:02:29 +0300 Moshe Shemesh wrote:
The enable_remote_dev_reset devlink param flags that the host admin
allows device resets that can be initiated by other hosts. This
parameter is useful for setups where a device is shared by different
hosts, such as multi-host setup. Once the user set this parameter to
false, the driver should NACK any attempt to reset the device while the
driver is loaded.
Signed-off-by: Moshe Shemesh <mo...@mellanox.com>
There needs to be a devlink event generated when reset is triggered
(remotely or not).
You're also missing failure reasons. Users need to know if the reset
request was clearly nacked by some host, not supported, etc. vs
unexpected failure.
I will fix and send extack message to the user accordingly.
I'd suggest the reason codes to be somewhat standard.
The groups I can think of:
- timeout - device did not respond to the reset request
- device reject - FW or else has nacked the activation req
- host incapable - one of the participating hosts (in MH) is not
capable of handling live activation
- host denied - one of the participating hosts has NACKed
- host timeout - one of the p. hosts did not ack or done the procedure
in time (e.g. has not toggled the link)
- failed reset - the activation itself had failed
- failed reinit - one of p. hosts was not able to cleanly come back up
Sounds good, that seems to cover all options of fw_reset process to fail.