On Fri, Jul 10, 2020 at 5:56 AM Jakub Kicinski <kubak...@wp.pl> wrote: > > On Thu, 9 Jul 2020 14:26:52 -0700 Jacob Keller wrote: > > The flash update for the ice hardware currently supports a single fixed > > configuration: > > > > * Firmware is always asked to preserve all changeable fields > > * The driver never allows downgrades > > * The driver will not allow canceling a previous update that never > > completed (for example because an EMP reset never occurred) > > * The driver does not attempt to trigger an EMP reset immediately. > > > > This default mode of operation is reasonable. However, it is often > > useful to allow system administrators more control over the update > > process. To enable this, implement devlink parameters that allow the > > system administrator to specify the desired behaviors: > > > > * 'reset_after_flash_update' > > If enabled, the driver will request that the firmware immediately > > trigger an EMP reset when completing the device update. This will > > result in the device switching active banks immediately and > > re-initializing with the new firmware. > > This should probably be handled through a reset API like what > Vasundhara is already working on. Yes, please go through the discussions happening on "[RFC v2 net-next] devlink: Add reset subcommand." mail thread. I am waiting for Moshe pachset for 'devlink dev reload' before further efforts.
> > > * 'allow_downgrade_on_flash_update' > > If enabled, the driver will attempt to update device flash even when > > firmware indicates that such an update would be a downgrade. > > * 'ignore_pending_flash_update' > > If enabled, the device driver will cancel a previous pending update. > > A pending update is one where the steps to write the update to the NVM > > bank has finished, but the device never reset, as the system had not > > yet been rebooted. > > These can be implemented in user space based on the values of running > and stored versions from devlink info. > > > * 'flash_update_preservation_level' > > The value determines the preservation mode to request from firmware, > > among the following 4 choices: > > * PRESERVE_ALL (0) > > Preserve all settings and fields in the NVM configuration > > * PRESERVE_LIMITED (1) > > Preserve only a limited set of fields, including the VPD, PCI serial > > ID, MAC address, etc. This results in permanent settings being > > reset, including changes to the port configuration, such as the > > number of physical functions created. > > * PRESERVE_FACTORY_SETTINGS (2) > > Reset all configuration fields to the factory default settings > > stored within the NVM. > > * PRESERVE_NONE (3) > > Do not perform any preservation. > > Could this also be handled in a separate reset API? It seems useful to > be able to reset to factory defaults at any time, not just FW upgrade..
