[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <08a7e6ef-ab23-9718-5fce-cdc53191197e@pensando.io>
Date: Fri, 18 Sep 2020 17:13:24 -0700
From: Shannon Nelson <snelson@...sando.io>
To: Jacob Keller <jacob.e.keller@...el.com>, netdev@...r.kernel.org
Cc: Jiri Pirko <jiri@...lanox.com>, Jakub Kicinski <kuba@...nel.org>,
Jonathan Corbet <corbet@....net>,
Michael Chan <michael.chan@...adcom.com>,
Bin Luo <luobin9@...wei.com>,
Saeed Mahameed <saeedm@...lanox.com>,
Leon Romanovsky <leon@...nel.org>,
Ido Schimmel <idosch@...lanox.com>,
Danielle Ratson <danieller@...lanox.com>
Subject: Re: [net-next v7 0/5] devlink flash update overwrite mask
On 9/18/20 4:42 PM, Jacob Keller wrote:
> This series introduces support for a new attribute to the flash update
> command: DEVLINK_ATTR_FLASH_UPDATE_OVERWRITE_MASK.
>
> This attribute is a bitfield which allows userspace to specify what set of
> subfields to overwrite when performing a flash update for a device.
>
> The intention is to support the ability to control the behavior of
> overwriting the configuration and identifying fields in the Intel ice device
> flash update process. This is necessary as the firmware layout for the ice
> device includes some settings and configuration within the same flash
> section as the main firmware binary.
>
> This series, and the accompanying iproute2 series, introduce support for the
> attribute. Once applied, the overwrite support can be be invoked via
> devlink:
>
> # overwrite settings
> devlink dev flash pci/0000:af:00.0 file firmware.bin overwrite settings
>
> # overwrite identifiers and settings
> devlink dev flash pci/0000:af:00.0 file firmware.bin overwrite settings overwrite identifiers
>
> To aid in the safe addition of new parameters, first some refactoring is
> done to the .flash_update function: its parameters are converted from a
> series of function arguments into a structure. This makes it easier to add
> the new parameter without changing the signature of the .flash_update
> handler in the future. Additionally, a "supported_flash_update_params" field
> is added to devlink_ops. This field is similar to the ethtool
> "supported_coalesc_params" field. The devlink core will now check that the
> DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT bit is set before forwarding the
> component attribute. Similarly, the new overwrite attribute will also
> require a supported bit.
>
> Doing these refactors will aid in adding any other attributes in the future,
> and creates a good pattern for other interfaces to use in the future. By
> requiring drivers to opt-in, we reduce the risk of accidentally breaking
> drivers when ever we add an additional parameter. We also reduce boiler
> plate code in drivers which do not support the parameters.
>
> Cc: Jiri Pirko <jiri@...lanox.com>
> Cc: Jakub Kicinski <kuba@...nel.org>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: Michael Chan <michael.chan@...adcom.com>
> Cc: Bin Luo <luobin9@...wei.com>
> Cc: Saeed Mahameed <saeedm@...lanox.com>
> Cc: Leon Romanovsky <leon@...nel.org>
> Cc: Ido Schimmel <idosch@...lanox.com>
> Cc: Danielle Ratson <danieller@...lanox.com>
> Cc: Shannon Nelson <snelson@...sando.io>
Thanks Jake. For ionic:
Acked-by: Shannon Nelson <snelson@...sando.io>
Powered by blists - more mailing lists