-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'devlink-flash-update-overwrite-mask'
Jacob Keller says: ==================== devlink flash update overwrite mask 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. Changes since v9: * rebased to current net-next, no other changes Changes since v7 * resend, hopefully avoiding the SMTP server issues I experienced on Friday Changes since v6 * Rebased to current net-next to resolve conflicts * Added changes to the ionic driver that recently merged flash update support * Fixed the changes for mlxsw to apply to core instead of spectrum.c after the recent refactor. * Picked up the review tags from Jakub Changes since v5 * Fix *all* of the BIT usage to use _BITUL() (thanks Jakub!) Changes since v4 * Renamed nla_overwrite to nla_overwrite_mask at Jiri's suggestion * Added "by this device" to the netlink error messages for unsupported attributes * Removed use of BIT() in the uapi header * Fixed the commit message for the netdevsim patch * Picked up Jakub's reviewed ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
- Loading branch information
Showing
17 changed files
with
247 additions
and
73 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.