All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Jakub Kicinski <kubakici@wp.pl>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Tom Herbert <tom@herbertland.com>, Jiri Pirko <jiri@mellanox.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Michael Chan <michael.chan@broadcom.com>,
	Bin Luo <luobin9@huawei.com>,
	Saeed Mahameed <saeedm@mellanox.com>,
	Leon Romanovsky <leon@kernel.org>,
	Ido Schimmel <idosch@mellanox.com>,
	Danielle Ratson <danieller@mellanox.com>
Subject: Re: [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash update
Date: Tue, 28 Jul 2020 09:58:44 -0700	[thread overview]
Message-ID: <a41db4d7-e3f3-ecbb-0876-4ccb7da0339f@intel.com> (raw)
In-Reply-To: <20200728111950.GB2207@nanopsycho>



On 7/28/2020 4:19 AM, Jiri Pirko wrote:
> Yes. Documentation is very easy to ignore unfortunatelly. The driver
> developer has to be tight up by the core code and api, I believe.
> 

So I'm not sure what the best proposal here is. We do have a list of
generic components, but given that each piece of HW has different
elements, it's not always feasible to have fully generic names. Some of
the names are driver specific.

I guess we could use some system where components are "registered" when
loading the devlink, so that they can be verified by the stack when used
as a parameter for flash update? Perhaps take something like the
table-driven approach used for infos and extend that into devlink core
so that drivers basically register a table of the components which
includes both a function callback that gets the version string as well
as an indication of whether that component can be updated via flash_update?

I know it would also be useful for ice to have a sort of "pre-info"
callback that generates a context structure that is passed to each of
the info callbacks. (that way a single up-front step could be to lookup
the relevant information, and this is then forwarded to each of the
formatter functions for each component).

Am I on the right track here or just over-engineering?

  reply	other threads:[~2020-07-28 16:58 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-17 18:35 [RFC PATCH net-next v2 0/6] introduce PLDM firmware update library Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 1/6] ice: Add support for unified NVM update flow capability Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 2/6] ice: Add AdminQ commands for FW update Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 3/6] ice: add flags indicating pending update of firmware module Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 4/6] Add pldmfw library for PLDM firmware update Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 5/6] ice: implement device flash update via devlink Jacob Keller
2020-07-20  5:26   ` kernel test robot
2020-07-23 23:33   ` Jacob Keller
2020-07-17 18:35 ` [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash update Jacob Keller
2020-07-20 10:09   ` Jiri Pirko
2020-07-20 15:51     ` Jakub Kicinski
2020-07-20 18:52       ` Jacob Keller
2020-07-21 13:56         ` Jiri Pirko
2020-07-21 17:28           ` Jacob Keller
2020-07-21 13:53       ` Jiri Pirko
2020-07-21 17:04         ` Jakub Kicinski
2020-07-21 17:31           ` Jacob Keller
2020-07-22 10:51           ` Jiri Pirko
2020-07-22 15:30             ` Keller, Jacob E
2020-07-22 16:52               ` Jakub Kicinski
2020-07-22 18:21                 ` Jacob Keller
2020-07-26  7:18                   ` Jiri Pirko
2020-07-27 18:11                     ` Jacob Keller
2020-07-29 22:49                 ` Jacob Keller
2020-07-29 23:16                   ` Jakub Kicinski
2020-07-29 23:59                     ` Jacob Keller
2020-07-26  7:16               ` Jiri Pirko
2020-07-27 18:13                 ` Jacob Keller
2020-07-28 11:19                   ` Jiri Pirko
2020-07-28 16:58                     ` Jacob Keller [this message]
2020-07-28 17:09                       ` Jakub Kicinski
2020-07-28 17:43                         ` Jacob Keller
2020-07-28 22:59                         ` Jacob Keller
2020-07-17 19:58 ` [RFC PATCH net-next v2 0/6] introduce PLDM firmware update library Jakub Kicinski
2020-07-17 21:00   ` Keller, Jacob E
2020-07-17 21:08   ` Keller, Jacob E

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a41db4d7-e3f3-ecbb-0876-4ccb7da0339f@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=corbet@lwn.net \
    --cc=danieller@mellanox.com \
    --cc=idosch@mellanox.com \
    --cc=jiri@mellanox.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=kubakici@wp.pl \
    --cc=leon@kernel.org \
    --cc=luobin9@huawei.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    --cc=tom@herbertland.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.