On Fri, Aug 24, 2012 at 12:46 AM, Alan Cox <[email protected]> wrote: >> IMO, the driver probing path is allowed to sleep, so looks request firmware >> should be allowed inside .probe(). > > I'm not convinced about that. It can sleep but its holding various locks > in most cases, and it looks like that can end up in a complete heap.
Currently, only wait_for_completion() pends in the path of request_firmware without holding other locks. > > By all means *request* the firmware asynchronously in the probe, but > there needs to be a seperate method somewhere after the probe to finish > the job once the firmware appears. Yes, request asynchronously will work and introduce a bit complexity (but it is not a big deal) Looks the focus is that why request_firmware can't be used in driver .probe(). IMO, we should consider that most of drivers call request_firmware inside its .probe(), and maybe udev need to support the usage. Thanks, -- Ming Lei _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
