Re: [RFC PATCH net-next 6/6] ice: implement devlink parameters to control flash update

From: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
To: Jakub Kicinski <kubakici@wp.pl>
Cc: Jacob Keller <jacob.e.keller@intel.com>,
	Netdev <netdev@vger.kernel.org>, Jiri Pirko <jiri@resnulli.us>,
	Jesse Brandeburg <jesse.brandeburg@intel.com>,
	Tom Herbert <tom@herbertland.com>
Subject: Re: [RFC PATCH net-next 6/6] ice: implement devlink parameters to control flash update
Date: Fri, 10 Jul 2020 11:55:05 +0530	[thread overview]
Message-ID: <CAACQVJoRcxtLTL_sTfh-tE4peTA58aK+xKic4BwaP-F3n8nfmg@mail.gmail.com> (raw)
In-Reply-To: <20200709171913.5b779cc7@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Fri, Jul 10, 2020 at 5:56 AM Jakub Kicinski <kubakici@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..