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. > * '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..
