Subject: Re: calling request_firmware() from module init will not work with recent/future udev versions

From: "Arend van Spriel" <arend-dY08KVG/lbpWk0Htik3J/[email-masked]>
Date: Thu, 16 Feb 2012 14:09:38 +0100

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 [email-masked]
More majordomo info at  http://vger.kernel.org/majordomo-info.html