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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 May 2012 14:16:04 +0200
From:	"Arend van Spriel" <arend@...adcom.com>
To:	"Kay Sievers" <kay@...y.org>
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 05/11/2012 01:03 PM, Kay Sievers wrote:
> On Fri, May 11, 2012 at 12:55 PM, Arend van Spriel <arend@...adcom.com> wrote:
>> To my memory (which fails from time to time) you posted a message on
>> using the asynchronous API for firmware loading as some drivers were
>> blocking on it in the module initialization. So for our driver we
>> decoupled the initialization from probe and subsequently the firmware
>> request. Assuming this solves the udev issue, but I am currently looking
>> into a somewhat related issue with our driver built-in.
>>
>> I am testing on a PandaBoard which boots a linux kernel without a initrd
>> and our device is detected before the root filesystem is mounted. I was
>> expecting the async firmware request to get called back immediatly with
>> firmware pointer being NULL. The behaviour is slightly different as this
>> callback is coming after 60 seconds, which is the timeout. I guess the
>> uevent just gets lost without the kernel knowing it. Is that correct?
> 
> 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/ ?
> 
> Kay
> 

Thanks, Kay

Here is the

# 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.

Gr. AvS

[    6.801452] brcmfmac: brcmf_sdbrcm_probe: completed!!
[    6.801483] brcmfmac: brcmf_sdbrcm_probe: request firmware
"brcm/brcmfmac-sdio.bin"
[    6.802703] brcmfmac: brcmf_ops_sdio_probe: Enter
[    6.802703] brcmfmac: brcmf_ops_sdio_probe: func->class=2
[    6.802734] brcmfmac: brcmf_ops_sdio_probe: sdio_vendor: 0x02d0
[    6.802734] brcmfmac: brcmf_ops_sdio_probe: sdio_device: 0x4329
[    6.802734] brcmfmac: brcmf_ops_sdio_probe: Function#: 0x0003
[    6.895507] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at
usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, ca:2a:a4:72:d9:6b
[    6.908111] drivers/usb/core/inode.c: creating file '003'
[    6.921234] mmc2: card claims to support voltages below the defined
range. These will be ignored.
[    6.940582] mmc2: queuing unknown CIS tuple 0x91 (3 bytes)
[    6.947418] mmc2: new SDIO card at address 0001
[    7.001281] kjournald starting.  Commit interval 5 seconds
[    7.014190] EXT3-fs (mmcblk0p2): using internal journal
[    7.019714] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data
mode
[    7.027038] VFS: Mounted root (ext3 filesystem) on device 179:2.
[    7.036437] devtmpfs: mounted
[    7.039764] Freeing init memory: 236K
[    8.119812] hub 2-0:1.0: hub_suspend
[    8.120025] usb usb2: bus auto-suspend, wakeup 1
[    8.120056] ohci-omap3 ohci-omap3.0: suspend root hub
[    9.666809] usb 1-1.1: link qh8-0001/ee2cc700 start 2 [1/0 us]
[   11.448059] smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex,
lpa 0xCDE1
[   67.573059] brcmfmac: brcmf_sdbrcm_fw_callback: enter
[   67.573059] brcmfmac: brcmf_sdbrcm_fw_callback: firmware not found
[   67.573059] brcmfmac: brcmf_sdbrcm_release: Enter

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