linux-kernel - Re: Problems loading firmware using built-in drivers with kernels that use initramfs.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Sep 2015 19:23:18 +0200
From:	Arend van Spriel <arend@...adcom.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ming Lei <ming.lei@...onical.com>,
	Takashi Iwai <tiwai@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Liam Girdwood <liam.r.girdwood@...ux.intel.com>,
	"Jie, Yang" <yang.jie@...el.com>,
	"joonas.lahtinen@...ux.intel.com" <joonas.lahtinen@...ux.intel.com>,
	Al Viro <viro@...iv.linux.org.uk>, Kay Sievers <kay@...y.org>,
	David Woodhouse <dwmw2@...radead.org>,
	lkml <linux-kernel@...r.kernel.org>,
	yalin wang <yalin.wang2010@...il.com>,
	Tom Gundersen <teg@...m.no>
Subject: Re: Problems loading firmware using built-in drivers with kernels
 that use initramfs.

On 09/03/2015 01:46 AM, Luis R. Rodriguez wrote:
> On Wed, Sep 2, 2015 at 4:29 PM, Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
>> On Wed, Sep 2, 2015 at 4:22 PM, Luis R. Rodriguez <mcgrof@...e.com> 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 <arend@...adcom.com> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/