From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755520AbbHYTeO (ORCPT ); Tue, 25 Aug 2015 15:34:14 -0400 Received: from mx2.suse.de ([195.135.220.15]:56924 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751210AbbHYTeN (ORCPT ); Tue, 25 Aug 2015 15:34:13 -0400 Date: Tue, 25 Aug 2015 21:34:08 +0200 From: "Luis R. Rodriguez" To: Liam Girdwood , "Jie, Yang" , joonas.lahtinen@linux.intel.com Cc: Takashi Iwai , Dmitry Torokhov , Tom Gundersen , Ming Lei , Al Viro , Greg Kroah-Hartman , Kay Sievers , Linus Torvalds , David Woodhouse , mcgrof@do-not-panic.com, linux-kernel@vger.kernel.org Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. Message-ID: <20150825193408.GR8051@wotan.suse.de> References: <1440449403.2469.35.camel@loki> <1440489900.2419.4.camel@loki> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. More on this below. > I can also take a look next week when I'm home from vacation. No worries, I'll look at it. > From:Liam Girdwood > Sent:Tue, 25 Aug 2015 09:05:00 +0100 > To:"Jie, Yang" ,dwmw2@infradead.org,"joonas.lahtinen " > Subject:Re: Problems loading firmware using built-in drivers with kernels that use initramfs. > > >On Mon, 2015-08-24 at 21:50 +0100, Liam Girdwood wrote: > >> Currently firmware loading with built-in drivers is failing on systems > >> that mount an initramfs before the root FS is mounted (that contains the > >> firmware file). Modular drivers work fine. > >> > >> Keyon (Jie, Yang) has done some testing with the Intel audio DSP driver > >> and found that the built-in firmware loading only works if the firmware > >> is included as part of the initramfs. Note that works. > >> The same has been seen with other > >> Intel drivers that use firmware. > >> > >> In this case it looks like userspace (udevd ?) is checking initramfs for > >> pending firmware requests and returning not found if it cant find the > >> files, but it's not re-checking for any pending firmware requests once > >> the real FS is mounted. Is it possible to have udevd re-check the > >> pending firmware requests after the real FS is mounted ? We are phasing out CONFIG_FW_LOADER_USER_HELPER support in the kernel, support for udev helper firmware loading was removed from systemd, the only requirement for it now is the dell rbu driver. Without CONFIG_FW_LOADER_USER_HELPER it its up to userspace or system integrators to do the right thing and you have a few options if you are enabling drivers as built-in: * stuff firmware in initramfs * built firmware into the kernel We don't do anything special for pivot_root for built-in, I am not sure if we should, I don't think we should... can you not do any of the above two options? Since folks can stuff firmware into initramfs and that's outside the scope of how we build the kernel we can't always ensure folks will do one of the above two options at build time for built-in drivers. If we don't want to do something for pivot_root the only thing I think we can do is document the expecations clearly, unless there are other ideas of course. Luis