Tue, Jun 02, 2020 at 01:24:16AM CEST, k...@kernel.org wrote: >On Mon, 1 Jun 2020 21:01:42 +0530 Vasundhara Volam wrote: >> > I think that the legacy ethtool should stick with the "ordinary fw reset", >> > becase that is what user expects. You should add an attribute to >> > "devlink dev reload" to trigger the "live fw reset" >> >> Okay. >> >> I am planning to add a type field with "driver-only | fw-reset | >> live-fw-reset | live-fw-patch" to "devlink dev reload" command. >> >> driver-only - Resets host driver instance of the 'devlink dev' >> (current behaviour). This will be default, if the user does not >> provide the type option. >> fw-reset - Initiate the reset command for the currently running >> firmware and wait for the driver reload for completing the reset. >> (This is similar to the legacy "ethtool --reset all" command). >> live-fw-reset - Resets the currently running firmware and driver entities. >> live-fw-patch - Loads the currently pending flashed firmware and >> reloads all driver entities. If no pending flashed firmware, resets >> currently loaded firmware. > >FWIW I'd prefer to extend the ethtool semantics. Ethtool reset has two >reset "depths" already - single port, entire adapter, we could just add >"entire sled" here. IOW we'd have reset which can affect only given >port, then reset which can affect multiple ports, and reset which may >affect multiple systems.
Hmm, I think that one way or another, we need to implement this in devlink and have compat fallback from ethtool there (as we have for other things too). > >The mechanism of the reset and whether old or new version of FW is >activated is a detail, which I believe will be entirely uninteresting >to the user. Whether other systems or ports are affected is _very_ >important, OTOH. Wait. So you say that user is not interested if the reset is fw "live" or not? There might be all sorts of issues when the reset happens under working driver instance. I think that user should be able to indicate if he is willing to take the risk.
