Re: in-kernel drivers and firmware loader

[Kay Sievers]

On Fri, May 11, 2012 at 2:16 PM, Arend van Spriel <arend@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/