[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200918095350.346c018b@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Fri, 18 Sep 2020 09:53:50 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: netdev@...r.kernel.org, Jiri Pirko <jiri@...lanox.com>,
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 v6 1/5] devlink: check flash_update parameter support
in net core
On Thu, 17 Sep 2020 17:45:25 -0700 Jacob Keller wrote:
> When implementing .flash_update, drivers which do not support
> per-component update are manually checking the component parameter to
> verify that it is NULL. Without this check, the driver might accept an
> update request with a component specified even though it will not honor
> such a request.
>
> Instead of having each driver check this, move the logic into
> net/core/devlink.c, and use a new `supported_flash_update_params` field
> in the devlink_ops. Drivers which will support per-component update must
> now specify this by setting DEVLINK_SUPPORT_FLASH_UPDATE_COMPONENT in
> the supported_flash_update_params in their devlink_ops.
>
> This helps ensure that drivers do not forget to check for a NULL
> component if they do not support per-component update. This also enables
> a slightly better error message by enabling the core stack to set the
> netlink bad attribute message to indicate precisely the unsupported
> attribute in the message.
>
> Going forward, any new additional parameter to flash update will require
> a bit in the supported_flash_update_params bitfield.
Reviewed-by: Jakub Kicinski <kuba@...nel.org>
Powered by blists - more mailing lists