> On Aug 26, 2015, at 04:26, Linus Torvalds <torva...@linux-foundation.org> > wrote: > > On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov > <dmitry.torok...@gmail.com> wrote: >> >> Either build firmware in the kernel or ramdisk (so it is always >> available), or make sure request_firmware() calls are not in driver's >> probe() paths. > > The correct answer is almost always that second one. > > Drivers that load firmware in their probe parts are generally doign > things wrong. > > It's very occasionally the right thing to do - there are a few pieces > of hardware where just about _everything_ about the device is in the > firmware, and you simply can't even problem them before that, because > you don't know what they *are* before the firmware has been loaded. > The extreme case of that might be something like the base hardware > being an FPGA that has a USB interface, but before the FPGA has been > loaded, it basically has no identity. So there are probably valid > cases in theory for loading firmware at probe time, but pretty much > every single case I've ever actually seen, the probe knows what the > actual hardware is from some identifiable piece, and the actual > firmware loading should be delayed until the piece of hardware is > actually opened. > > So the "load firmware in probe routine" happens, and we shouldn't > disallow it, but it should be considered a "last resort" kind of > thing. > > In general, things like sound drivers should *not* need to have their > firmware in the initrd, even if you build them into the kernel. A disk > driver? Yes. Maybe the root filesystem is on that disk, and you need > the firmware for the disk driver to load it. But a sound device? > Please just make sure that you load the firmware as late as possible. > i remember lots of drivers load their firmware when some user space process open the device node, that is to say, they load the firmware in ->open() function, at this time , you can make sure the real filesystem is ready in most time.
i think your dsp firmware can also do like this. you can refer to msm gnu driver: static void load_gpu(struct drm_device *dev) { static DEFINE_MUTEX(init_lock); struct msm_drm_private *priv = dev->dev_private; mutex_lock(&init_lock); if (!priv->gpu) priv->gpu = adreno_load_gpu(dev); mutex_unlock(&init_lock); } static int msm_open(struct drm_device *dev, struct drm_file *file) { struct msm_file_private *ctx; /* For now, load gpu on open.. to avoid the requirement of having * firmware in the initrd. */ load_gpu(dev); ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) return -ENOMEM; file->driver_priv = ctx; return 0; } it load the firmware in open() function. Thanks -- 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/