Message ID | 20200918234208.1060371-1-jacob.e.keller@intel.com |
---|---|
Headers | show |
Series | devlink flash update overwrite mask | expand |
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@mellanox.com> > Cc: Jakub Kicinski <kuba@kernel.org> > Cc: Jonathan Corbet <corbet@lwn.net> > Cc: Michael Chan <michael.chan@broadcom.com> > Cc: Bin Luo <luobin9@huawei.com> > Cc: Saeed Mahameed <saeedm@mellanox.com> > Cc: Leon Romanovsky <leon@kernel.org> > Cc: Ido Schimmel <idosch@mellanox.com> > Cc: Danielle Ratson <danieller@mellanox.com> > Cc: Shannon Nelson <snelson@pensando.io> Thanks Jake. For ionic: Acked-by: Shannon Nelson <snelson@pensando.io>