From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755924AbbHZFag (ORCPT ); Wed, 26 Aug 2015 01:30:36 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:35513 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754097AbbHZFaf convert rfc822-to-8bit (ORCPT ); Wed, 26 Aug 2015 01:30:35 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. From: yalin wang In-Reply-To: Date: Wed, 26 Aug 2015 13:30:21 +0800 Cc: Dmitry Torokhov , Takashi Iwai , "Luis R. Rodriguez" , Liam Girdwood , "Jie, Yang" , joonas.lahtinen@linux.intel.com, Tom Gundersen , Ming Lei , Al Viro , Greg Kroah-Hartman , Kay Sievers , David Woodhouse , Luis Rodriguez , lkml Content-Transfer-Encoding: 8BIT Message-Id: <2B38A5C9-8940-464D-B473-CF62E8BD84C4@gmail.com> References: <1440449403.2469.35.camel@loki> <1440489900.2419.4.camel@loki> <20150825193408.GR8051@wotan.suse.de> To: Linus Torvalds X-Mailer: Apple Mail (2.2104) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Aug 26, 2015, at 04:26, Linus Torvalds wrote: > > On Tue, Aug 25, 2015 at 12:58 PM, Dmitry Torokhov > 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