Re: [RFC] binary firmware and modules

Hi Duncan,

in order to not fall in the naming-policy trap: do we need a translation
layer here? eg the module asks for firmware-<modulename>
and userspace then somehow maps that to a full filename via a lookup
table?

since the same module can handle different devices which need
different firmware, firmware-<modulename> is not sufficient. An example
is the speedtouch USB modems, which need different firmware depending on
the modem revision. In fact each modem needs two blobs uploaded, a small
one (stage 1 blob) followed by a large one (stage 2 blob). These blobs
are fairly independant, for example a given stage 1 blob can work for a
wider range of modem revisions than a given stage 2 blob. Also, the
manufacturer made a bunch of exotic variations on the modem (all with
the same product ids, but different revisions); I don't have a complete
list, and I don't know which ones require special firmware. That means
that the driver does not have a complete list of different firmware names.
It could always use the same names "stage1" and "stage2", regardless of
the revision, and expect the user to place the right firmware there; but
then what about people who have multiple modems with different revisions
(like me)? As a result of all this, the driver needs to export the following
to userspace, to let user-space find the right firmware:

(0) module name
(1) stage 1 or stage 2
(2) modem major revision number
(3) modem minor revision number (I don't know if this is really needed,
but I heard a rumour that it was: ISDN modems needing special firmware
but only varying in their minor revision from non-ISDN modems IIRC).

This is all exported in the hotplug environment. However, current hotplug
scripts don't have any cleverness in them for handling this kind of thing
(I don't know about udev).

we don't really have hotplug anymore. Now it is all handled by udev or
the udev helper programs.

For my drivers, I don't have this problem of different firmware images
for different versions and I personally don't really like abusing the
firmware name for some kind of revision control. However initially the
idea behind request_firmware() was that the userspace is totally dumb
and its only job is to copy a binary image from the filesystem into the
kernel memory, so it can be used by the driver. Another idea was that we
can reuse the firmware filenames from the Windows driver if they are
separate from the driver. This allowed us in most cases to tell the end
users to simply extract that file and copy it to /lib/firmware/ and
everything was working.

So for the fist step, I think a MODULE_FIRMWARE() extension (with maybe
and additional comment per firmware name) will be a good think to feed
back the information of firmware files to the userspace. After that we
might need to look into messed up devices and drivers. I also expect
that some WiFi drivers might have the same problem.

Regards

Marcel


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

Relevant Pages