Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756203AbbHYT6S (ORCPT ); Tue, 25 Aug 2015 15:58:18 -0400 Received: from mail-oi0-f50.google.com ([209.85.218.50]:35234 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752059AbbHYT6O (ORCPT ); Tue, 25 Aug 2015 15:58:14 -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 12:58:13 -0700 Message-ID: Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. From: Dmitry Torokhov To: Takashi Iwai Cc: "Luis R. Rodriguez" , Liam Girdwood , "Jie, Yang" , joonas.lahtinen@linux.intel.com, Tom Gundersen , Ming Lei , Al Viro , Greg Kroah-Hartman , Kay Sievers , Linus Torvalds , 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 Content-Length: 1832 Lines: 40 On Tue, Aug 25, 2015 at 12:46 PM, Takashi Iwai wrote: > On Tue, 25 Aug 2015 21:34:08 +0200, > Luis R. Rodriguez wrote: >> >> On Tue, Aug 25, 2015 at 10:17:00AM +0100, David Woodhouse wrote: >> > Luis, did you tell me the other day that you made the kernel get firmware >> > directly from the file system? This regression would be yours then? >> >> I didn't implement that, Linus did in 2012 (see commit abb139e75c2c titled >> "firmware: teach the kernel to load firmware files directly from the >> filesystem"). But we used to fallback to a userspace helper when the fw was >> not present and then Takashi made this optional via commit 7b1269f778782d >> titled "firmware: Make user-mode helper optional". Takashi noted in the >> Kconfig "The user-mode helper is no longer required unless you have a >> special firmware file that resides in a non-standard path". It was not >> clarified why that's true though, or what you'd need to do to ensure >> that the fw would be available. It would be good for us to elaborate >> on that. > > The recent udev already dropped the firmware loading feature. Note that even when we had udev helper to load the firmware it was not always reliable depending on the exact point where we requested firmware. If request happened in probe() path before we mounted root fs then we'd never get it loaded because we'd be waiting for devices settle before mounting rootfs. 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. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/