From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756141AbbHYU0m (ORCPT ); Tue, 25 Aug 2015 16:26:42 -0400 Received: from mail-io0-f173.google.com ([209.85.223.173]:35661 "EHLO mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752291AbbHYU0l (ORCPT ); Tue, 25 Aug 2015 16:26:41 -0400 MIME-Version: 1.0 In-Reply-To: References: <1440449403.2469.35.camel@loki> <1440489900.2419.4.camel@loki> <20150825193408.GR8051@wotan.suse.de> Date: Tue, 25 Aug 2015 13:26:40 -0700 X-Google-Sender-Auth: l3O62zbL2KDlPN4fOnHKazV4V5I Message-ID: Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. From: Linus Torvalds To: Dmitry Torokhov Cc: 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-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Linus