On Fri, Aug 24, 2012 at 12:46 AM, Alan Cox <a...@lxorguk.ukuu.org.uk> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
