Message-ID: <CAPXgP13b0uu3DgOGRL-_WKx-aSQN-f0xL6OmjNPBGf9fg0satA@mail.gmail.com>
Date:	Sun, 15 Jan 2012 16:33:18 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
	Tom Gundersen <teg@...m.no>, Andy Whitcroft <apw@...onical.com>
Subject: Re: calling request_firmware() from module init will not work with
 recent/future udev versions

On Sun, Jan 15, 2012 at 11:02, Johannes Berg <johannes@...solutions.net> wrote:
>> These drivers need to be fixed to load their firmware during ifup,
>> which would be the most flexible solution. That way, it should also
>> work if the driver is built-in, or is loaded from initramfs and no
>> firmware is available.
>> Alternatively, the firmware request should be able to use the aync
>> firmware_request API and not the blocking one.
>
> Will udev now also return the async load only after root is booted if it
> can't be satisfied earlier?

Not sure, let me explain what happens here, maybe it contains the answer:

Udev gets an event for a pci device:
  /devices/pci0000:00/0000:00:1c.1/0000:03:00.0

This device has a modalias, which let's udev load the matching module
into the kernel. The module_init() syscall triggers the firmware
loading request, which causes another event:
  /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/0000:03:00.0

This event is a direct child of the pci device and udev delays the
execution of child devices until the parent devices return from
handling. This dependency logic is needed for many things to ensure a
proper operation, like partitions which need to make sure the events
for the disk devices are handled before the partition events are
started.

Now the problem, the pcidev event is blocking in modprobe and waits
for the child event it has generated to finish, but udev does not
start the event because the parent still blocks in modprobe ->
deadlock until default firmware timeout of 60 sec. What we want here,
for several reasons not only udev's dependency logic, is that modprobe
never waits for userspace transactions to finish.

> There are a number of devices, particularly
> wireless, that need firmware before they can register with mac80211 for
> capability advertisement reasons.

Right, ideally all firmware loading would be delayed until the netif
is brought up, and that's what we shoudl use if possible. In all other
cases, I think what iwlwifi is doing here looks fine from the
userspace side. It does not register any netdev/mac80211 device, the
firmware request is the only thing that it issued, and modprobe
returns immediately, regardless of the firmware request handling.

If userspace is not responding, the firmware request times out after
60 seconds and the driver is not associated with any hardware. To
retry the firmware loading, the module needs to be unloaded and
reloaded, or the driver needs to be asked to bind to a device again by
writing to the 'bind' in file in the sysfs driver directory.

Firmware requests stay around in the system for by default 60 seconds.
If the driver would be built-in the request would be issued long
before userspace is ready, but udev's coldplug step during bootup will
cause all events to be replayed, so it would catch also the
outstanding firmware requests, and would be able to handle them.

Kay
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists