Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752343AbbH2HLe (ORCPT ); Sat, 29 Aug 2015 03:11:34 -0400 Received: from mx2.suse.de ([195.135.220.15]:35452 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752173AbbH2HLd (ORCPT ); Sat, 29 Aug 2015 03:11:33 -0400 Date: Sat, 29 Aug 2015 09:11:27 +0200 Message-ID: From: Takashi Iwai To: Ming Lei Cc: "Luis R. Rodriguez" , Linus Torvalds , Liam Girdwood , "Jie, Yang" , Dmitry Torokhov , "joonas.lahtinen@linux.intel.com" , Tom Gundersen , Al Viro , Greg Kroah-Hartman , Kay Sievers , David Woodhouse , Luis Rodriguez , lkml , yalin wang Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. In-Reply-To: References: <20150825193408.GR8051@wotan.suse.de> <1440576394.2443.17.camel@loki> <20150829011130.GK8051@wotan.suse.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.5 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3148 Lines: 70 On Sat, 29 Aug 2015 06:09:01 +0200, Ming Lei wrote: > > On Sat, Aug 29, 2015 at 9:11 AM, Luis R. Rodriguez wrote: > > On Thu, Aug 27, 2015 at 08:55:13AM +0800, Ming Lei wrote: > >> On Thu, Aug 27, 2015 at 2:07 AM, Linus Torvalds > >> wrote: > >> > On Wed, Aug 26, 2015 at 1:06 AM, Liam Girdwood > >> > wrote: > >> >> > >> >> I think the options are to either :- > >> >> > >> >> 1) Don not support audio DSP drivers using topology data as built-in > >> >> drivers. Audio is not really a critical system required for booting > >> >> anyway. > >> > > >> > Yes, forcing it to be a module and not letting people compile it in by > >> > mistake (and then not have it work) is an option. > >> > > >> > That said, there are situations where people don't want to use > >> > modules. I used to eschew them for security reasons, for example - now > >> > I instead just do a one-time temporary key. But others may have other > >> > reasons to try to avoid modules. > >> > > >> >> 2) Create a default PCM for every driver that has topology data on the > >> >> assumption that every sound card will at least 1 PCM. This PCM can then > >> >> be re-configured when the FW is loaded. > >> > > >> > That would seem to be the better option if it is reasonably implementable. > >> > > >> > Of course, some kind of timer-based retry (limited *somehow*) of the > >> > fw loading could work too, but smells really really hacky. > >> > >> Yeah, years ago, we discussed to use -EPROBE_DEFER for the situation, > >> which should be one kind of fix, but looks there were objections at that time. > > > > That would still be a hack. I'll note there is also asynchronous probe support > > now but to use that would also be a hack for this issue. We don't want to > > If we think firmware as one kind of resources like regulators, gpio and others, > PROBE_DEFER is one good match for firmware loading case, and > it has been used by lots of drivers, so why can't it be used for > firmware loading? > > One problem is that we need to convert drivers into returning -EPROBE_DEFER > in case of request failure, and that may involve some work, but which > should be mechanical. I find such a delaying mechanism not so bad, too. It's very straightforward, at least, no big pain in the transition in the driver side. > > encourage folks to go down that road. They'd be hacks for this issue as you > > are simply delaying the driver probe for a later time and there is no guarantee > > that any pivot_root() might have already been completed later to ensure your > > driver's fw file is present. So it may work or it may not. > > We can trigger defer probe explicitly once root fs is setup or other condition > is met. Right, how to trigger the reprobe (and relevant optimization) needs to be considered on top of the current mechanism. Takashi -- 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/