linux-kernel - Re: in-kernel drivers and firmware loader

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 11 May 2012 14:38:33 +0200
From:	Kay Sievers <kay@...y.org>
To:	Arend van Spriel <arend@...adcom.com>
Cc:	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: in-kernel drivers and firmware loader

On Fri, May 11, 2012 at 2:16 PM, Arend van Spriel <arend@...adcom.com> wrote:
> On 05/11/2012 01:03 PM, Kay Sievers wrote:

>> It's probably sent, but nothing see it because there is no userspace
>> that would have subscribed.
>>
>> If udev is started later during bootup, and the coldplug triggers all
>> events again, the firmware request should be found and be fulfilled by
>> userspace -- at least that's the theory.
>>
>> Can you reach the box with a login before the 60 seconds are reached?
>>
>> Do you see a firmware request (directory) still hanging around in
>> /sys/class/firmware/ ?

> # cd /sys/class/firmware/mmc1\:0001\:2/
> # ls
> data       device     loading    power      subsystem  uevent
> # cat uevent
> FIRMWARE=brcm/brcmfmac-sdio.bin
> TIMEOUT=60
> ASYNC=1
> # cat loading
> 0
>
> Not sure if loading content means anything or it presence is indicating
> it is in progress. Below also the dmesg output.

Yeah, that looks good. The request is still around and waits for
userspace to get handled.

> [   11.448059] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex,
> [   67.573059] brcmfmac: brcmf_sdbrcm_fw_callback: enter

Seems userspace is not doing anything here, it's just the kernel
timeout that we run into.

If you can manage to do this before the timeout triggers, it should
show if things *can* work:

Start:
  udevd --daemon
if it's not already running.

Trigger 'fake' events for all devices in the system, so that udev
'thinks' the firmware request just came in:
  udevadm trigger --action=add

Normally, all that should be handled by the base system, and not need
any custom setup.

Kay
--
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/