Re: in-kernel drivers and firmware loader
From: Arend van Spriel
Date: Fri May 11 2012 - 08:16:13 EST
On 05/11/2012 01:03 PM, Kay Sievers wrote:
> On Fri, May 11, 2012 at 12:55 PM, Arend van Spriel <arend@xxxxxxxxxxxx> 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/ ?
Here is the
# cd /sys/class/firmware/mmc1\:0001\:2/
data device loading power subsystem uevent
# cat uevent
# cat loading
Not sure if loading content means anything or it presence is indicating
it is in progress. Below also the dmesg output.
[ 6.801452] brcmfmac: brcmf_sdbrcm_probe: completed!!
[ 6.801483] brcmfmac: brcmf_sdbrcm_probe: request firmware
[ 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
[ 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,
[ 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/