Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752215AbbH2EJI (ORCPT ); Sat, 29 Aug 2015 00:09:08 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:35791 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750825AbbH2EJF (ORCPT ); Sat, 29 Aug 2015 00:09:05 -0400 MIME-Version: 1.0 In-Reply-To: <20150829011130.GK8051@wotan.suse.de> References: <20150825193408.GR8051@wotan.suse.de> <1440576394.2443.17.camel@loki> <20150829011130.GK8051@wotan.suse.de> Date: Sat, 29 Aug 2015 12:09:01 +0800 Message-ID: Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. From: Ming Lei To: "Luis R. Rodriguez" Cc: Linus Torvalds , Liam Girdwood , "Jie, Yang" , Takashi Iwai , Dmitry Torokhov , "joonas.lahtinen@linux.intel.com" , Tom Gundersen , Al Viro , Greg Kroah-Hartman , Kay Sievers , David Woodhouse , Luis Rodriguez , lkml , yalin wang 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: 3014 Lines: 65 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. > 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. > > We should instead strive to be clear about expectations and requirements both > through documentation and when possible through APIs. I'll send out an RFC > which adds some grammar rules which can help us police this. I currently only > spot two drivers that require fixing. > > Luis -- 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/