From: Casey Leedom <leedom@chelsio.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>, hariprasad@chelsio.com
Cc: poswald@suse.com, santosh@chelsio.com, jcheung@suse.com,
dchang@suse.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, mcgrof@suse.com
Subject: Re: [RFT 0/3] cxgb4: use request_firmware_nowait()
Date: Mon, 23 Jun 2014 12:06:48 -0700 [thread overview]
Message-ID: <53A87AC8.7010305@chelsio.com> (raw)
In-Reply-To: <1403311181-9328-1-git-send-email-mcgrof@do-not-panic.com>
I've looked through the patch and I might be wrong, but it appears
that all the uses of the asynchronous request_firmware_nowait() are
followed immediately by wait_for_completion() calls which essentially
would be the same as the previous code with an added layer of
mechanism. Am I missing something?
We do have a problem with initialization of multiple adapters with
external PHYs since, for each adapter we can check to see if the main
adapter firmware needs updating, and then load the PHY firmware. If the
main firmware needs updating on more than one adapter, the combined time
to update each adapter's main firmware plus load the PHY firmware can
exceed some Distribution's default limits for a driver module's load
time (since the kernel seems to be processing the PCI Probe of each
device sequentially).
It seems to me that it's unfortunate that the limit isn't on a per
device basis since a system could have an arbitrary number of devices
managed by a driver module. Also, it might be useful if there was a way
for the driver module to "tell" the timeout mechanism that forward
progress _is_ being made so it doesn't blow away the driver module
load. And maybe, if I'm right regarding the sequential nature of the
introduction of devices to driver modules, it might make sense for a
driver module to be able to "tell" the kernel that it has no per-device
dependencies and multiple devices may be probed simultaneously ...
Casey
On 06/20/14 17:39, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Its reported that loading the cxgb4 can take over 1 minute,
> use the more sane request_firmware_nowait() API call just
> in case this amount of time is causing issues. The driver
> uses the firmware API 3 times, one for the firmware, one
> for configuration and another one for flash, this provides
> the port for all cases.
>
> I don't have the hardware so please test. I did verify we
> can use this during pci probe and also during the ethtool
> flash callback.
>
> Luis R. Rodriguez (3):
> cxgb4: make ethtool set_flash use request_firmware_nowait()
> cxgb4: make configuration load use request_firmware_nowait()
> cxgb4: make device firmware load use request_firmware_nowait()
>
> drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 13 ++
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 258 +++++++++++++++---------
> 2 files changed, 176 insertions(+), 95 deletions(-)
>
next prev parent reply other threads:[~2014-06-23 19:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-21 0:39 [RFT 0/3] cxgb4: use request_firmware_nowait() Luis R. Rodriguez
2014-06-21 0:39 ` [RFT 1/3] cxgb4: make ethtool set_flash " Luis R. Rodriguez
2014-06-21 0:39 ` [RFT 2/3] cxgb4: make configuration load " Luis R. Rodriguez
2014-06-21 0:39 ` [RFT 3/3] cxgb4: make device firmware " Luis R. Rodriguez
2014-06-23 19:06 ` Casey Leedom [this message]
2014-06-24 0:29 ` [RFT 0/3] cxgb4: " Luis R. Rodriguez
2014-06-24 15:55 ` Casey Leedom
2014-06-24 16:34 ` Casey Leedom
2014-06-24 23:39 ` Luis R. Rodriguez
2014-06-25 2:00 ` Luis R. Rodriguez
2014-06-25 21:51 ` Luis R. Rodriguez
2014-06-26 0:08 ` Luis R. Rodriguez
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=53A87AC8.7010305@chelsio.com \
--to=leedom@chelsio.com \
--cc=dchang@suse.com \
--cc=hariprasad@chelsio.com \
--cc=jcheung@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.com \
--cc=netdev@vger.kernel.org \
--cc=poswald@suse.com \
--cc=santosh@chelsio.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