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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
