From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757683AbbICRX2 (ORCPT ); Thu, 3 Sep 2015 13:23:28 -0400 Received: from mail-gw1-out.broadcom.com ([216.31.210.62]:43620 "EHLO mail-gw1-out.broadcom.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757665AbbICRXZ (ORCPT ); Thu, 3 Sep 2015 13:23:25 -0400 X-IronPort-AV: E=Sophos;i="5.17,463,1437462000"; d="scan'208";a="74254654" Message-ID: <55E88206.5050106@broadcom.com> Date: Thu, 3 Sep 2015 19:23:18 +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" , Dmitry Torokhov CC: 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 Subject: Re: Problems loading firmware using built-in drivers with kernels that use initramfs. 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> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; 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/03/2015 01:46 AM, Luis R. Rodriguez wrote: > 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. Indeed. However, upon module_init we schedule a worker in which the driver are registered. We do that to make sure the probe is not done within module_init context. That could now be done with async probe. This is not the problem discussed here so let's not spend more time on this. >>> 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. So what does "userspace knows when firmware is available" mean here. The specific firmware file the driver wants or the collection of firmware files which may or may not have the specific firmware file the driver wants. I assume the latter and re-probe will fail as expected. Regards, Arend