From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753191AbbIBBTS (ORCPT ); Tue, 1 Sep 2015 21:19:18 -0400 Received: from mx2.suse.de ([195.135.220.15]:39516 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751233AbbIBBTR (ORCPT ); Tue, 1 Sep 2015 21:19:17 -0400 Date: Wed, 2 Sep 2015 03:19:12 +0200 From: "Luis R. Rodriguez" To: Ming Lei Cc: Arend van Spriel , Takashi Iwai , 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. Message-ID: <20150902011912.GY8051@wotan.suse.de> References: <1440576394.2443.17.camel@loki> <20150829011130.GK8051@wotan.suse.de> <55E1724E.6040303@broadcom.com> <20150829183802.480b1425@tom-T450> <55E2BE0E.1070907@broadcom.com> 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 Mon, Aug 31, 2015 at 10:21:34PM +0800, Ming Lei wrote: > On Sun, Aug 30, 2015 at 4:25 PM, Arend van Spriel wrote: > > Does this mean a built-in driver can not get firmware from initramfs or > > built in the kernel early. Seems a bit too aggressive. The problem stated in > > this thread is when the firmware is not on initramfs but only on the rootfs. > > Yes, strictly speaking, user mode request can't be handled with defer probe > during booting because we don't know how the user helper handles the > request, FWIW I have a strategy in mind to help us compartamentalize the user mode helper only to the dell-rbu driver, and as such phase out that code eventually completely. Its part of the goals I have with the extensible firmware API I've been proposing. > that said even checking if the firmware exists in current path doesn't > make sense for user mode request. > > So the patch should have used defer proble for direct load only > during booting. What exact guarantees would we be giving to callers if they follow up on probe with -EDEFER_PROBE ? I'd much prefer to try to avoid such uses in init / probe (note that unless you're using async probe since we batch both so it doesn't really matter where you place your code) all together and then for the few remaining stragglers understand the requirements and provide an interface that lets them claim their requirements and try to meets them. A grammatical hunt for drivers who call fw API on init / probe can be completed, although I know the hunt needs a bit more fine tuning it surely can be completed. If we don't have many callers the compexity added for only a few callers with rather loose criteria seems rather unnecessary, specially if we can change the drivers and make these driver sthe exception rather than a norm. Then as for drivers *needing* the fw at probe why not have a proper interface that does guarantee they get the requirements they ask for first ? For instance a new probe type specified by the driver could enable the core to wait for say an event and then tirgger a probe, kind of how we ended up defining the async probe type preference: static struct some_bus_driver some_driver = { .probe = some_probe, .id_table = some_id, .driver = { .name = DEVICE_NAME, .pm = &some_pm_ops, .probe_type = PROBE_PREFER_POST_FOO, }, }; Then we just don't try just hoping for completion but rather can do something about the criteria passed. Luis