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]
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)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ