From: Shannon Nelson <snelson@pensando.io>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net
Subject: Re: [PATCH v2 net-next 2/2] ionic: add devlink firmware update
Date: Sat, 5 Sep 2020 15:06:07 -0700 [thread overview]
Message-ID: <328d7cc0-9bf9-3051-52d5-9f7ac2fd4075@pensando.io> (raw)
In-Reply-To: <20200905130422.36e230df@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On 9/5/20 1:04 PM, Jakub Kicinski wrote:
> On Thu, 3 Sep 2020 17:05:34 -0700 Shannon Nelson wrote:
>> +/* The worst case wait for the install activity is about 25 minutes when
>> + * installing a new CPLD, which is very seldom. Normal is about 30-35
>> + * seconds. Since the driver can't tell if a CPLD update will happen we
>> + * set the timeout for the ugly case.
> 25 minutes is really quite scary. And user will see no notification
> other than "Installing 50%" for 25 minutes? And will most likely not
> be able to do anything that'd involve talking to the FW, like setting
> port info/speed?
Yeah, it's pretty annoying, and the READMEs with the FW will need to
warn that the install time will be much longer than usual.
>
> Is it possible for the FW to inform that it's updating the CPLD?
We don't have any useful feedback mechanism for this kind of thing, but
I'll think about how it might work and see if I can get something from
the FW folks. Another option would be for the driver to learn how to
read the FW blob, but I'd really rather not go down that road.
>
> Can you release the dev_cmd_lock periodically to allow other commands
> to be executed while waiting?
I think this could be done. I suspect I'll need to give the dev_cmd the
regular timeout and have this routine manage the longer potential
timeout. I'll likely have to mess with the low-level dev_cmd_wait to
not complain about a timeout when it is a FW status command.
The status_notify messages could then be updated in order to show some
progress, but would we base the 100% on the remote possibility that it
might take 25 minutes? Or use some scaled update time, taking longer
between updates as time goes on? Hmmm...
I'll think about this over the long weekend.
Thanks,
sln
next prev parent reply other threads:[~2020-09-05 22:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 0:05 [PATCH v2 net-next 0/2] ionic: add devlink dev flash support Shannon Nelson
2020-09-04 0:05 ` [PATCH v2 net-next 1/2] ionic: update the fw update api Shannon Nelson
2020-09-04 0:05 ` [PATCH v2 net-next 2/2] ionic: add devlink firmware update Shannon Nelson
2020-09-05 19:52 ` Jakub Kicinski
2020-09-05 21:47 ` Shannon Nelson
2020-09-05 22:07 ` Jakub Kicinski
2020-09-05 20:04 ` Jakub Kicinski
2020-09-05 22:06 ` Shannon Nelson [this message]
2020-09-05 22:19 ` Jakub Kicinski
2020-09-04 15:01 ` [PATCH v2 net-next 0/2] ionic: add devlink dev flash support Jakub Kicinski
2020-09-04 18:20 ` Shannon Nelson
2020-09-04 22:47 ` Jakub Kicinski
2020-09-04 22:52 ` Shannon Nelson
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=328d7cc0-9bf9-3051-52d5-9f7ac2fd4075@pensando.io \
--to=snelson@pensando.io \
--cc=davem@davemloft.net \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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).