From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753078AbbIBXq6 (ORCPT ); Wed, 2 Sep 2015 19:46:58 -0400 Received: from mail-oi0-f44.google.com ([209.85.218.44]:33374 "EHLO mail-oi0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752522AbbIBXq4 (ORCPT ); Wed, 2 Sep 2015 19:46:56 -0400 MIME-Version: 1.0 In-Reply-To: References: <55E1724E.6040303@broadcom.com> <20150829183802.480b1425@tom-T450> <55E2BE0E.1070907@broadcom.com> <20150902011912.GY8051@wotan.suse.de> <55E6E70F.80907@broadcom.com> <55E6E7FD.8030401@broadcom.com> <20150902185842.GC8051@wotan.suse.de> <55E76418.7070006@broadcom.com> <20150902232249.GK8051@wotan.suse.de> From: "Luis R. Rodriguez" Date: Wed, 2 Sep 2015 16:46:36 -0700 X-Google-Sender-Auth: pzbj5gCRSRb_Plhsu3VezrMGkr8 Message-ID: Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. To: Dmitry Torokhov Cc: Arend van Spriel , Greg Kroah-Hartman , Ming Lei , Takashi Iwai , Linus Torvalds , Liam Girdwood , "Jie, Yang" , "joonas.lahtinen@linux.intel.com" , Al Viro , Kay Sievers , David Woodhouse , lkml , yalin wang , Tom Gundersen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov wrote: > On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez wrote: >> On Wed, Sep 02, 2015 at 04:13:51PM -0700, Dmitry Torokhov wrote: >>> On Wed, Sep 2, 2015 at 2:03 PM, Arend van Spriel wrote: >>> > Ok. So some background why we need it in brcm80211 drivers. So as a wireless >>> > network device driver the answer we got when asking for an event to load >>> > firware is upon IF_UP for a registered net device. Because we try to do >>> > things smart we query the firmware running on the device for capabilities >>> > before we can register the net device hence we request the firmware during >>> > probe. This may be specific to wireless drivers (Intel has same approach if >>> > not mistaken) but I suspect there may be more. >>> >>> We have the same issue with input devices: before we can register one >>> we need to set their capabilities and to know their capabilities we >>> quite often need to load their firmware/config and query the device. >> >> Should Arend's driver use async probe then? > > What has async probe have to do with anything? We will still be > waiting for async probes to finish before we mount rootfs so it will > not change absolutely anything. :) Right, its what I was alluding to as well. >> IMHO its just as hacky as using -EPROBE_DEFER too, but its at least >> preemptively hacky. Sadly I can't think of clear and clever way for the kernel >> to know when firmware will be ready either... Would userspace know? Should the >> kernel learn this from userspace ? > > Yes. Given only userspace knows when firmware is available (I could > have it on a separate device and mount it at some time). So maybe > userpsace should simply try and scan busses for unbound devices and > tell them to re-probe when it decides that firmware is finally > available. OK, the folks wanting this mechanism can implement it then. Short of that we only have hacks. Luis