From: Jacob Keller <jacob.e.keller@intel.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Jiri Pirko <jiri@resnulli.us>,
Vasundhara Volam <vasundhara-v.volam@broadcom.com>,
David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>,
Michael Chan <michael.chan@broadcom.com>,
Jiri Pirko <jiri@mellanox.com>, Michal Kubecek <mkubecek@suse.cz>,
moshe@mellanox.com
Subject: Re: [RFC v2 net-next] devlink: Add reset subcommand.
Date: Fri, 10 Jul 2020 13:55:09 -0700 [thread overview]
Message-ID: <1ca4c809-b696-3f83-54ca-0c635a66e5db@intel.com> (raw)
In-Reply-To: <20200710133929.389f1aba@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On 7/10/2020 1:39 PM, Jakub Kicinski wrote:
> On Fri, 10 Jul 2020 11:16:51 -0700 Jacob Keller wrote:
>>> We already have notion of "a component" in "devlink dev flash". I think
>>> that the reset component name should be in-sync with the flash.
>>
>> Right. We should re-use the component names from devlink dev info here
>> (just as we do in devlink dev flash).
>
> Let's remember that the SW did not eat the entire world just yet ;)
>
> There are still HW components which don't have FW (and therefore FW
> component to flash) that folks may want to reset.. that's what the
> ethtool reset API was cut to.
>
True enough. I was thinking only in terms of resetting to load new
firmware, which is a different but related problem.
Thanks,
Jake
next prev parent reply other threads:[~2020-07-10 20:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 11:34 [RFC v2 net-next] devlink: Add reset subcommand Vasundhara Volam
2020-06-30 12:53 ` Jiri Pirko
2020-06-30 15:15 ` Vasundhara Volam
2020-07-01 5:51 ` Jiri Pirko
2020-07-01 9:25 ` Vasundhara Volam
2020-07-01 9:47 ` Jiri Pirko
2020-07-01 11:59 ` Vasundhara Volam
2020-07-01 12:45 ` Jiri Pirko
2020-07-10 18:16 ` Jacob Keller
2020-07-10 20:39 ` Jakub Kicinski
2020-07-10 20:55 ` Jacob Keller [this message]
2020-07-21 9:51 ` Vasundhara Volam
2020-07-21 12:19 ` Jiri Pirko
2020-07-22 19:32 ` Moshe Shemesh
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=1ca4c809-b696-3f83-54ca-0c635a66e5db@intel.com \
--to=jacob.e.keller@intel.com \
--cc=davem@davemloft.net \
--cc=jiri@mellanox.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=michael.chan@broadcom.com \
--cc=mkubecek@suse.cz \
--cc=moshe@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=vasundhara-v.volam@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 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.