linux-kernel - [PATCH][RFC] request_firmware examples and MODULE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20060904084505.30467.qmail@web415.biz.mail.mud.yahoo.com>
Date:	Mon, 4 Sep 2006 01:45:05 -0700 (PDT)
From:	Victor Hugo <victor@...go.net>
To:	linux-kernel@...r.kernel.org
Cc:	greg@...ah.com, alan@...rguk.ukuu.org.uk
Subject: [PATCH][RFC] request_firmware examples and MODULE_FIRMWARE

Hi Everyone,

I'm trying to become the firmware loader maintainer
(request_firmware) and I felt the first thing I should
do is update the incomplete example driver under
Documentaion/firmware_class/.  The example
(firmware_sample_driver.c) doesn't work out of box and
needs tweaking just to get it to compile.  I've added
two files which use request_firmware and the
asynchronous request_firmware_nowait.

The next step would be to update the documentation to
make hotplug/udev functionality a little more clear. 
Hopefully I can get this in the next couple of days.

Also, I'd like to comment on Jon Masters push to
include the MODULE_FIRMWARE api addition.  I strongly
believe that policy should not be included in driver
code, in this case it's in the form of a filename. 

The firmware loader currently needs a filename passed
to it so it can then pass the $FIRMWARE environment
variable to the hotplug script.  This is ok if you
provide a generic filename like "firmware.bin" and
then let the hotplug script worry about version
numbers, i.e. "firmware-x.y.z.bin"

MODULE_FIRMWARE should be used to provide the generic
filenames and which order the files should be loaded
(request_firmware can be called various times), but I
think its bad to have to change the driver everytime a
new firmware version is released.

That said, here's the patch...
View attachment "firmware_examples.patch" of type "text/x-patch" (7495 bytes)