On 02/16/2012 01:38 PM, Johannes Berg wrote:

On Thu, 2012-02-16 at 13:04 +0100, Arend van Spriel wrote:

quoted

On 01/16/2012 09:57 AM, Johannes Berg wrote:

quoted

quoted

Now the problem, the pcidev event is blocking in modprobe and waits

quoted

  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.

quoted

quoted

quoted

quoted

  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