linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
Subject: Re: [RFC/RFT 0/5] Firmware load change for various wireless drivers
Date: Tue, 14 Feb 2012 11:56:55 +0100	[thread overview]
Message-ID: <1329217015.3941.8.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <1329161826-11135-1-git-send-email-Larry.Finger@lwfinger.net> (sfid-20120213_203726_939695_C63C1EE3)

On Mon, 2012-02-13 at 13:37 -0600, Larry Finger wrote:
> These patches change 5 drivers that are now loading firmware from the probe
> routine. As each of them has the possibility of loading more than one
> file, the method of using request_firmware_nowait() has some difficulty,
> as it gets duplicate names in sysfs when the requests are launched in
> parallel.

Why not simply start off with one, and then when that returns
successfully request the other ones?

> When the callback routine is used to launch a second request,
> the structure gets messy, particularly with b43legacy, which loads 4
> firmware files for some hardware. My solution is to create a delayed work
> queue that is started in the probe routine with a delay of one second. The
> routine that is triggered does the normal request_firmware() calls
> and starts mac80211 when the firmware is available.

I suppose this works, but I'd be a little worried that when the driver
is built into the kernel it doesn't help much. I'm asking the udev
people to not answer async loads while in initramfs, but they'd still
give you a negative answer here, and they won't be able to tell the
difference between a synchronous request from a work item (which doesn't
block boot) and a synchronous request from probe (which does block
booting).

johannes


  parent reply	other threads:[~2012-02-14 10:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-13 19:37 [RFC/RFT 0/5] Firmware load change for various wireless drivers Larry Finger
2012-02-13 19:37 ` [RFC/RFT 1/5] b43legacy: Load firmware from work queue instead of from probe routine Larry Finger
2012-02-13 19:37 ` [RFC/RFT 2/5] b43: Load firmware from a work queue and not from the " Larry Finger
2012-02-13 23:06   ` Julian Calaby
2012-02-13 23:28     ` Larry Finger
2012-02-13 23:41       ` Julian Calaby
2012-02-13 23:51         ` Larry Finger
2012-02-13 19:37 ` [RFC/RFT 3/5] p54usb: Load firmware from work queue and not from " Larry Finger
2012-02-13 19:37 ` [PATCH 4/5] p54pci: " Larry Finger
2012-02-29 15:59   ` Larry Finger
2012-02-29 17:43     ` Christian Lamparter
2012-02-29 18:15       ` Larry Finger
2012-02-29 18:27         ` Christian Lamparter
2012-02-13 19:37 ` [RFC/RFT 5/5] p54spi: " Larry Finger
2012-02-13 21:57   ` Michael Büsch
2012-02-29 16:00   ` Larry Finger
2012-02-29 19:54     ` Max Filippov
2012-02-29 20:01       ` Larry Finger
2012-02-14 10:56 ` Johannes Berg [this message]
2012-02-14 16:34   ` [RFC/RFT 0/5] Firmware load change for various wireless drivers Larry Finger
2012-02-14 16:37     ` Johannes Berg
2012-02-14 16:57       ` Larry Finger

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=1329217015.3941.8.camel@jlt3.sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=Larry.Finger@lwfinger.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.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).