From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754472AbbIBMNz (ORCPT ); Wed, 2 Sep 2015 08:13:55 -0400 Received: from mail-gw3-out.broadcom.com ([216.31.210.64]:62787 "EHLO mail-gw3-out.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753687AbbIBMNy (ORCPT ); Wed, 2 Sep 2015 08:13:54 -0400 X-IronPort-AV: E=Sophos;i="5.17,453,1437462000"; d="scan'208";a="73895896" Message-ID: <55E6E7FD.8030401@broadcom.com> Date: Wed, 2 Sep 2015 14:13:49 +0200 From: Arend van Spriel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Luis R. Rodriguez" , Ming Lei CC: 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. References: <1440576394.2443.17.camel@loki> <20150829011130.GK8051@wotan.suse.de> <55E1724E.6040303@broadcom.com> <20150829183802.480b1425@tom-T450> <55E2BE0E.1070907@broadcom.com> <20150902011912.GY8051@wotan.suse.de> <55E6E70F.80907@broadcom.com> In-Reply-To: <55E6E70F.80907@broadcom.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/02/2015 02:09 PM, Arend van Spriel wrote: > On 09/02/2015 03:19 AM, Luis R. Rodriguez wrote: >> 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. So should the probe type indicate some event or should it just indicate what the driver needs, ie. .probe_type = PROBE_TYPE_NEED_FW. Regards, Arend > That sounds good to me and learning about the async probe type. We do a > schedule work in our module_init to avoid the probe being done in init > context. Guess we can change that using the async probe type :-p > > Regards, > Arend > -- > 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/