From: "Arend van Spriel" <arend@broadcom.com>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
driverdevel <devel@driverdev.osuosl.org>,
wireless <linux-wireless@vger.kernel.org>,
"linux-hotplug@vger.kernel.org" <linux-hotplug@vger.kernel.org>,
Kay Sievers <kay.sievers@vrfy.org>
Subject: Re: will these methods work with firmware loading?
Date: Mon, 20 Feb 2012 10:01:50 +0000 [thread overview]
Message-ID: <4F421A0E.8030805@broadcom.com> (raw)
In-Reply-To: <4F414230.5040506@lwfinger.net>
On 02/19/2012 07:40 PM, Larry Finger wrote:
> I sent a previous messages to most of these lists, but got no answer, thus a
> second try.
>
> When a driver loads firmware synchronously in the module_init() path using
> request_firmware(), then there is trouble with timeouts when booting.
>
> I know that changing the request_firmware() call to request_firmware_nowait()
> solves the problem; however, that gives some trouble for driver b43legacy as it
> loads 3 or 4 firmware files depending on the hardware version. When I launch the
> 3 or 4 nowait requests, I get an error because the system is trying to start
> several tasks with the same name.
Yep, the nowait api just kicks off a kernel thread for the firmware request.
> Would it be OK to load the first file with the nowait version, and issue a
> request_firmware() for the others from the callback routine? I think that would
> not cause any problems, but I would like to get confirmation from an expert.
No expert, but that is what I did although the chaining of firmware
requests does not feel great. Especially for handling error flows.
Johannes Berg and Kay Sievers mentioned need to unbind/rebind the driver
upon failed firmware load, but I don't like the idea of building a
timer-controlled retry mechanism.
> Similarly, if I were to create a work queue, init and schedule it from
> module_init(), and then use synchronous loads to get the firmware from the work
> queue callback, would that get around the boot problem? I know it works as I
> have trial patches; however, my version of udev is not one affected. This method
> is very easy to implement, but again I would like confirmation from an expert.
What boot problem are you referring to? The blocking modprobe? For that
problem I would say yes. Also here the problem of handling error flows
exist. If the driver is kicked of during boot with a initramfs missing
the firmware, should we retry until the real root is mounted?
Gr. AvS
WARNING: multiple messages have this Message-ID (diff)
From: "Arend van Spriel" <arend@broadcom.com>
To: "Larry Finger" <Larry.Finger@lwfinger.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
driverdevel <devel@driverdev.osuosl.org>,
wireless <linux-wireless@vger.kernel.org>,
"linux-hotplug@vger.kernel.org" <linux-hotplug@vger.kernel.org>,
"Kay Sievers" <kay.sievers@vrfy.org>
Subject: Re: will these methods work with firmware loading?
Date: Mon, 20 Feb 2012 11:01:50 +0100 [thread overview]
Message-ID: <4F421A0E.8030805@broadcom.com> (raw)
In-Reply-To: <4F414230.5040506@lwfinger.net>
On 02/19/2012 07:40 PM, Larry Finger wrote:
> I sent a previous messages to most of these lists, but got no answer, thus a
> second try.
>
> When a driver loads firmware synchronously in the module_init() path using
> request_firmware(), then there is trouble with timeouts when booting.
>
> I know that changing the request_firmware() call to request_firmware_nowait()
> solves the problem; however, that gives some trouble for driver b43legacy as it
> loads 3 or 4 firmware files depending on the hardware version. When I launch the
> 3 or 4 nowait requests, I get an error because the system is trying to start
> several tasks with the same name.
Yep, the nowait api just kicks off a kernel thread for the firmware request.
> Would it be OK to load the first file with the nowait version, and issue a
> request_firmware() for the others from the callback routine? I think that would
> not cause any problems, but I would like to get confirmation from an expert.
No expert, but that is what I did although the chaining of firmware
requests does not feel great. Especially for handling error flows.
Johannes Berg and Kay Sievers mentioned need to unbind/rebind the driver
upon failed firmware load, but I don't like the idea of building a
timer-controlled retry mechanism.
> Similarly, if I were to create a work queue, init and schedule it from
> module_init(), and then use synchronous loads to get the firmware from the work
> queue callback, would that get around the boot problem? I know it works as I
> have trial patches; however, my version of udev is not one affected. This method
> is very easy to implement, but again I would like confirmation from an expert.
What boot problem are you referring to? The blocking modprobe? For that
problem I would say yes. Also here the problem of handling error flows
exist. If the driver is kicked of during boot with a initramfs missing
the firmware, should we retry until the real root is mounted?
Gr. AvS
next prev parent reply other threads:[~2012-02-20 10:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-19 18:40 will these methods work with firmware loading? Larry Finger
2012-02-19 18:40 ` Larry Finger
2012-02-20 9:46 ` Johannes Berg
2012-02-20 9:46 ` Johannes Berg
2012-02-20 10:01 ` Arend van Spriel [this message]
2012-02-20 10:01 ` Arend van Spriel
2012-02-20 10:19 ` Kay Sievers
2012-02-20 10:19 ` Kay Sievers
2012-02-20 10:32 ` Arend van Spriel
2012-02-20 10:32 ` Arend van Spriel
2012-02-20 20:12 ` Larry Finger
2012-02-20 20:12 ` 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=4F421A0E.8030805@broadcom.com \
--to=arend@broadcom.com \
--cc=Larry.Finger@lwfinger.net \
--cc=devel@driverdev.osuosl.org \
--cc=kay.sievers@vrfy.org \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@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 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.