Re: in-kernel drivers and firmware loader
From: Kay Sievers
Date: Fri May 11 2012 - 08:38:51 EST
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
> # cat loading
> 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:
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.
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/