From: Jakub Kicinski <kuba@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, davem@davemloft.net, idosch@nvidia.com,
pabeni@redhat.com, edumazet@google.com, saeedm@nvidia.com,
jacob.e.keller@intel.com, vikas.gupta@broadcom.com,
gospo@broadcom.com
Subject: Re: [patch net-next 4/4] net: devlink: expose default flash update target
Date: Sat, 20 Aug 2022 13:11:15 -0700 [thread overview]
Message-ID: <20220820131115.35dc83ee@kernel.org> (raw)
In-Reply-To: <YwB0yeXEDxHm5Sxx@nanopsycho>
On Sat, 20 Aug 2022 07:44:41 +0200 Jiri Pirko wrote:
> >The entire dev info / dev flash interface was driven by practical needs
> >of the fleet management team @Facebook / Meta.
> >
> >What would make the changes you're making more useful here would be if
> >instead of declaring the "default" component, we declared "overall"
> >component. I.e. the component which is guaranteed to encompass all the
> >other versions in "stored", and coincidentally is also the default
> >flashed one.
>
> It is just semantics.
You say that like it's a synonym for irrelevance. Semantics are
*everything* for the uAPI :)
> Default is what we have now and drivers are using
> it. How, that is up to the driver. I see no way how to enforce this, do
> you?
Not sure I understand. We document the thing clearly as "this is the
overall and must include all parts of stored FW", name it appropriately.
If someone sneaks in code which abuses the value for something else,
nothing we can do, like with every driver API we have.
The "default" gives user information but to interpret that information
user is presupposed to know the semantics of the components. Of what
use is knowing that default is component A if I don't know that it's
the component I want to flash. And if so why don't I just say
"component A"?
> But anyway, I can split the patchset in 2:
> 1) sanitize components
> 2) default/overall/whatever
> If that would help.
Sure thing, seems like a practical approach.
On second thought the overall may not be practical, there are sometimes
critical components on the board you don't really want to flash unless
you really have to. CPLDs and stuff. So perhaps we should scratch (2)
altogether until we have a clear need...
next prev parent reply other threads:[~2022-08-20 20:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 13:00 [patch net-next 0/4] net: devlink: sync flash and dev info commands Jiri Pirko
2022-08-18 13:00 ` [patch net-next 1/4] net: devlink: extend info_get() version put to indicate a flash component Jiri Pirko
2022-08-18 21:23 ` Keller, Jacob E
2022-08-19 8:10 ` Jiri Pirko
2022-08-18 13:00 ` [patch net-next 2/4] net: devlink: expose the info about version representing a component Jiri Pirko
2022-08-18 13:00 ` [patch net-next 3/4] netdevsim: expose version of default flash target Jiri Pirko
2022-08-18 13:00 ` [patch net-next 4/4] net: devlink: expose default flash update target Jiri Pirko
2022-08-19 2:53 ` Jakub Kicinski
2022-08-19 8:12 ` Jiri Pirko
2022-08-19 21:54 ` Jakub Kicinski
2022-08-20 5:44 ` Jiri Pirko
2022-08-20 20:11 ` Jakub Kicinski [this message]
2022-08-19 20:59 ` Keller, Jacob E
2022-08-19 21:45 ` Jakub Kicinski
2022-08-19 22:07 ` Keller, Jacob E
2022-08-20 5:46 ` Jiri Pirko
2022-08-22 17:09 ` Keller, Jacob E
2022-08-23 6:38 ` Jiri Pirko
2022-08-18 21:16 ` [patch net-next 0/4] net: devlink: sync flash and dev info commands Keller, Jacob E
2022-08-19 2:49 ` Jakub Kicinski
2022-08-19 8:25 ` [patch net-next 0/4] net: devlink: sync flash and dev info command Jiri Pirko
2022-08-23 10:09 ` Kumar, M Chetan
2022-08-23 12:20 ` Jiri Pirko
2022-08-23 16:29 ` Kumar, M Chetan
2022-08-24 8:47 ` Jiri Pirko
2022-08-26 8:54 ` Kumar, M Chetan
2022-08-26 11:01 ` Jiri Pirko
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=20220820131115.35dc83ee@kernel.org \
--to=kuba@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gospo@broadcom.com \
--cc=idosch@nvidia.com \
--cc=jacob.e.keller@intel.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=vikas.gupta@broadcom.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).