public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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(-)
>


  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