From: "Arend van Spriel" <arend-dY08KVG/lbpWk0Htik3J/w@public•gmane.org>
To: "Johannes Berg" <johannes-cdvu00un1VgdHxzADdlk8Q@public•gmane.org>
Cc: "Kay Sievers" <kay.sievers-tD+1rO4QERM@public•gmane.org>,
"netdev-u79uwXL29TY76Z2rM5mHXA@public•gmane.org"
<netdev-u79uwXL29TY76Z2rM5mHXA@public•gmane.org>,
"linux-wireless-u79uwXL29TY76Z2rM5mHXA@public•gmane.org"
<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public•gmane.org>,
"Tom Gundersen" <teg-B22kvLQNl6c@public•gmane.org>,
"Andy Whitcroft" <apw-Z7WLFzj8eWMS+FvcfC7Uqw@public•gmane.org>
Subject: Re: calling request_firmware() from module init will not work with recent/future udev versions
Date: Thu, 16 Feb 2012 14:09:38 +0100 [thread overview]
Message-ID: <4F3D0012.9070808@broadcom.com> (raw)
In-Reply-To: <1329395881.3915.7.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
On 02/16/2012 01:38 PM, Johannes Berg wrote:
> On Thu, 2012-02-16 at 13:04 +0100, Arend van Spriel wrote:
>> On 01/16/2012 09:57 AM, Johannes Berg wrote:
>>>> Now the problem, the pcidev event is blocking in modprobe and waits
>>>>> for the child event it has generated to finish, but udev does not
>>>>> start the event because the parent still blocks in modprobe ->
>>>>> deadlock until default firmware timeout of 60 sec. What we want here,
>>>>> for several reasons not only udev's dependency logic, is that modprobe
>>>>> never waits for userspace transactions to finish.
>>> Ok, thanks for the description. I guess to me that means nothing really
>>> changes much in the situation I'm thinking of.
>>
>> I am working on changes in brcm80211 driver and the behaviour changes
>> slightly. The async firmware request basically kicks of a kernel thread
>> to do the actual request. So the probe finishes successfully regardless
>> what the results will be of the actual firmware request. Hence the
>> driver is associated with the hardware.
>
> This is true.
>
>>>>> If userspace is not responding, the firmware request times out after
>>>>> 60 seconds and the driver is not associated with any hardware. To
>>>>> retry the firmware loading, the module needs to be unloaded and
>>>>> reloaded, or the driver needs to be asked to bind to a device again by
>>>>> writing to the 'bind' in file in the sysfs driver directory.
>>> Right.
>>>
>>
>> If my previous statement is true, what does it mean regarding retrying
>> the firmware loading?
>
> When the firmware loading fails, the driver should unbind from the
> device that it failed for, and the retrying behaviour doesn't change
> (and requires a rebind)
>
> johannes
>
>
Thanks, Johannes
That helps. My driver was happily bound to the device until unloading
the driver or unplugging the device.
Gr. AvS
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public•gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-02-16 13:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-14 15:25 calling request_firmware() from module init will not work with recent/future udev versions Kay Sievers
2012-01-14 17:58 ` John W. Linville
2012-01-14 18:20 ` Larry Finger
[not found] ` <4F11C75F.9030105-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2012-01-14 19:59 ` Arend van Spriel
[not found] ` <4F11DEB8.7010708-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2012-01-14 20:13 ` Larry Finger
[not found] ` <4F11E1CE.2050008-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2012-01-14 20:15 ` Emmanuel Grumbach
2012-01-14 18:45 ` Larry Finger
2012-01-14 19:26 ` Tom Gundersen
2012-01-15 10:02 ` Johannes Berg
[not found] ` <1326621743.3448.1.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-01-15 15:33 ` Kay Sievers
2012-01-16 8:57 ` Johannes Berg
2012-01-16 12:05 ` Kay Sievers
2012-01-16 12:16 ` Johannes Berg
2012-07-19 10:46 ` Kay Sievers
2012-07-24 14:16 ` Johannes Berg
2012-07-24 14:32 ` Tom Gundersen
2012-07-24 17:50 ` Kay Sievers
[not found] ` <1326704259.3510.3.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-02-16 12:04 ` Arend van Spriel
2012-02-16 12:38 ` Johannes Berg
[not found] ` <1329395881.3915.7.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
2012-02-16 13:09 ` Arend van Spriel [this message]
[not found] ` <4F3D0012.9070808-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2012-02-16 14:39 ` Johannes Berg
[not found] ` <CAPXgP11iT9K2KcDCJvw_druf5qdNjs0jLfrbpS7CcYh5vXrz_w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-02-20 17:43 ` Arend van Spriel
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=4F3D0012.9070808@broadcom.com \
--to=arend-dy08kvg/lbpwk0htik3j/w@public$(echo .)gmane.org \
--cc=apw-Z7WLFzj8eWMS+FvcfC7Uqw@public$(echo .)gmane.org \
--cc=johannes-cdvu00un1VgdHxzADdlk8Q@public$(echo .)gmane.org \
--cc=kay.sievers-tD+1rO4QERM@public$(echo .)gmane.org \
--cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public$(echo .)gmane.org \
--cc=teg-B22kvLQNl6c@public$(echo .)gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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