lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 16 Feb 2012 14:09:38 +0100
From:	"Arend van Spriel" <>
To:	"Johannes Berg" <>
cc:	"Kay Sievers" <>,
	"" <>,
	"" <>,
	"Tom Gundersen" <>, "Andy Whitcroft" <>
Subject: Re: calling request_firmware() from module init will not work
 with recent/future udev versions

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 netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists