1、request_firmware在内核使用，需要文件系统支持，就是说，启动的时候如果在驱动里面的probe函数调用 request_firmware ，那么系统将等待30s左右，因为文件系统还没有挂载，当然找不到固件了，所以最好在中断里面启动tasklet，然后request_firmware 。如果不想等待，就用request_firmware_nowait，好像是这样写的。
2、那么用户层怎么用？
实际上这个分x86和嵌入式，比如arm，平台。x86的用到了udev，
比如你要请求固件 fw.hex，那么必须在文件系统中导出环境变量，比如 export FIRMWARE=/lib/firmware，而且目录/lib/firmware不能少，因为busybox要用到。然后把固件fw.hex放到 /lib/firmware目录下即可。内核request_firmware的时候，busybox就知道去FIRMWARE找了。
3、对linux来讲，所谓的固件什么也不是，他只是按fopen()返回二进制文件给你，看看busybox的处理就知道了。所以你的文件随便定 义，比如一个mp3文件，你也可以称为固件：request_firmware(“xxx.mp3″)，那么你文件系统里面也要有这个xxx.mp3文 件，只不过系统给你返回二进制数据，具体的处理要在内核进行。
request_firmware 返回二进制firmware文件的地址和大小
//firmware->data和firmware->size来读取有uevent处理程序init加载进来的firmware数据了
request_firmware( & priv- > firmware, fw_name, priv- > hotplug_device) ; 给priv- > hotplug_device设备申请名字为fw_name的firmware 数据, 然后将结果放到& priv- > firmware中,
struct firmware {
size_t size;
u8 * data;
} ;
可以看到, 如果应用层的程序成功load了firmware固件文件, 那么firmware. data将指向固件数据, firmware. size为固件大小.
前段时间移植 wifi 驱动到 android 的内核上，发现 firmware 的加载始终出错，问了几个人，都不是很了解，没办法，只好自己研究一下。
原理分析从本质上来说， firmware 需要做的事情包括两件：
1， 通知用户态程序，我需要下载 firmware 了；
2， 用户态程序把用户态的数据 copy 到内核层；
3， 内核把内核态的数据写到设备上，比如 wifi 模块里；
其中第三步应该不难，关键是看看， linux 里面是如何实现第一、二步的；
实现机制简单的说，它的机制分成以下几部分：
1， 通过一定的方式，通知用户态程序，比如 init 程序，如图所示：
显然是通过 kobject_uevent 的方式通知的 应用层，它的机制我有空再详细解释，简单的说，就是往一个 socket 广播一个消息，只需要在应用层打开 socket 监听 NETLINK_KOBJECT_UEVENT 组的消息，就可以收到了。
用户态的 init 是如何做的？
可以看到 init 程序打开了一个 socket ，然后绑定它， 最后通过 select 来监听 socket 上来的数据，最后调用 handle_device_fd 来处理收到的消息；当内核发送一个 KOBJ_ADD 的消息上来的时候，经过过 滤，判断是否是 firmware 要被加载的消息，然后调用
handle_firmware_event 来处理；
2， 用户态的数据如何下载到内核；
本质上它是内核创建了两个文件，一个文件 A 用来标志下载的开始和结 束，另外一个文件 B 用来接收用户层传下来的数据，当用户态的程序往 A 文件写入 1 的时候，标志用户态程序已经往里面写程序来，而往里面写入 0 的时候，就标志下载成功结束，如果写入 -1 就表示下载失败了；下面 看看这两个文件是如何被创建的 , 以及数据是如何写到内核的，请看图：
这个图基本上就是两个文件被创立的过程，以及当这两个文 件被用户态程序访问的时候将要被调用的函数，比如对于标志文件，如果往里面写入数据，将会触发函数 firmware_loading_store 函数，如果往 bin 文件里面写入数据将会触发 bin 文件类型的 write 函数；
用户态写数据的过程大约是这样的：当用户态收到 KOBJ_ADD 消息的时候 最终将会调用 handle_firmware_event 的函数；
它的过程就是：
a, 先往标志文件里面写 1 ；
b, 从用户空间读取数据；
c, 往内核创建的文件里面写数据；
d, 如果成功写入 0 ，否则写入 -1 ；
下面看看内核是如何接受这些文件的，前面提到内核创建了一个 bin 文件，用来接收用户态的数据，下面看 看这个过程：
对于 SYSFS_KOBJ_BIN_ATTR 属 性的文件，在 inode 初始化的时候，将会被赋予 bin_fops 的文件操作函数集，于是当上层调用 write 的时候，将会走到内核的 bin_fops.write 函数；这个函数干的事情很简单，就是把用户态的数据 copyright 到 bb->buffer ，而 bb->buffer 其 实是在 open 的 时候分配的空间，这样的话，就实现了用户态的数据到内核的 copy ；过程是不是完了？
还有一个步骤，这个 bb->buffer 本身是如何与 wifi 驱动交互的呢？这只是一个中间层，它的数据必须要写到 wifi 的驱动才应该算完整，而这一步其实 就是通过 flush_write 来完成的，下面看看这个过程：
这里可以清楚的看到， flush_write 做的事情就是把 bb->buffer 的内容 copy 到 wifi driver 分配的空间 fw->data 里面去了，至此，用户态的数据已经完整的写到了 wifi 的 driver 空间了；
3， 内核态的数据到 wifi 模块
这个就比较简单了，通过函数 sdio_writesb 利用 sdio 总线把数据写到模块 里面去了；
总结
Firmware 的加载主要是利用了 uevent 的通讯机制实现用户态和内核 态的交互，另外还涉及了 sys 文件系统里的文件创建 , 我加载 wifi firmware 始终出错的原因是 android 的文件系统要求把 wifi 的 firmware helper 放到 /etc/firmware 里面，而把真正 的 firmware sd8686.bin 放到 /etc/firmware/mrvl 里面，估计是 marvel 修改后的结果，结论就是，这个设计真丑；
获取固件的正确方法是当需要时从用户空间获取它。一定不要试图从内核空间直接打开包含固件的文件，那是一个易出错的操作, 因为它把策略(以文件名的形式)包含进了内核。正确的方法是使用固件接口:
| #include int request_firmware(const struct firmware **fw, const char *name, /* name 为固件文件名*/ struct device *device); /*因为 request_firmware 需要用户空间的操作, 所以返回前将保持休眠。若驱动必须使用固件而不能进入休眠时,可使用以下异步函数:*/ /* fw 参数指向以下结构体:*/ /*当固件已经发送到设备后，应当释放 firmware 结构体, 使用:*/ |
注意：要使用firmware，必须要在配置内核时选上：
Device Drivers --->
Generic Driver Options --->
<*> Userspace firmware loading support
否则会出现: Unknown symbol release_firmware 和: Unknown symbol request_firmware 的错误。
当调用 request_firmware时, 函数将在 /sys/class/firmware 下创建一个以设备名为目录名的新目录，其中包含 3 个属性:
loading ：这个属性应当被加载固件的用户空间进程设置为 1。当加载完毕, 它将被设为 0。被设为 -1 时，将中止固件加载。
data ：一个用来接收固件数据的二进制属性。在设置 loading 为1后, 用户空间进程将固件写入这个属性。
device ：一个链接到 /sys/devices 下相关入口项的符号链接。
一旦创建了 sysfs 入口项, 内核将为设备产生一个热插拔事件，并传递包括变量 FIRMWARE 的环境变量给处理热插拔的用户空间程序。FIRMWARE 被设置为提供给 request_firmware 的固件文件名。
用户空间程序定位固件文件, 并将其拷贝到内核提供的二进制属性；若无法定位文件, 用户空间程序设置 loading 属性为 -1。
若固件请求在 10 秒内没有被服务, 内核就放弃并返回一个失败状态给驱动。超时周期可通过 sysfs 属性 /sys/class/firmware/timeout 属性改变。
request_firmware 接口允许使用驱动发布设备固件。当正确地集成进热插拔机制后, 固件加载子系统允许设备不受干扰地工作。显然这是处理问题的最好方法，但固件受版权保护，小心违反版权法。
这里主要介绍硬件驱动使用 Linux kernel 提供Firmware load 功能的方法;
(1) kernel source code :
drivers/base/firmware_class.c // linux 2.6.11
(2) header file:
(3) document
Document/firmware/
(4) 使用例子
Documentation/firmware_class/firmware_sample_driver.c
1 /*
2 * firmware_sample_driver.c -
3 *
4 * Copyright (c) 2003 Manuel Estrada Sainz <>
5 *
6 * Sample code on how to use request_firmware() from drivers.
7 *
8 * Note that register_firmware() is currently useless.
9 *
10 */
11
12 #include
13 #include
14 #include
15 #include
16
17 #include “linux/firmware.h”
18
19 #define WE_CAN_NEED_FIRMWARE_BEFORE_USERSPACE_IS_AVAILABLE
20 #ifdef WE_CAN_NEED_FIRMWARE_BEFORE_USERSPACE_IS_AVAILABLE
21 char __init inkernel_firmware[] = “let’s say that this is firmware\n”;
22 #endif
23
24 static struct device ghost_device = {
25 .name = “Ghost Device”,
26 .bus_id = “ghost0″,
27 };
28
29
30 static void sample_firmware_load(char *firmware, int size)
31 {
32 u8 buf[size+1];
33 memcpy(buf, firmware, size);
34 buf[size] = ‘\0′;
35 printk(“firmware_sample_driver: firmware: %s\n”, buf);
36 }
37
38 static void sample_probe_default(void)
39 {
40 /* uses the default method to get the firmware */
41 const struct firmware *fw_entry;
42 printk(“firmware_sample_driver: a ghost device got inserted 
\n”);
43
44 if(request_firmware(&fw_entry, “sample_driver_fw”, &ghost_device)!=0)
45 {
46 printk(KERN_ERR
47 “firmware_sample_driver: Firmware not available\n”);
48 return;
49 }
50
51 sample_firmware_load(fw_entry->data, fw_entry->size);
52
53 release_firmware(fw_entry);
54
55 /* finish setting up the device */
56 }
57 static void sample_probe_specific(void)
58 {
59 /* Uses some specific hotplug support to get the firmware from
60 * userspace directly into the hardware, or via some sysfs file */
61
62 /* NOTE: This currently doesn’t work */
63
64 printk(“firmware_sample_driver: a ghost device got inserted \n”);
65
66 if(request_firmware(NULL, “sample_driver_fw”, &ghost_device)!=0)
67 {
68 printk(KERN_ERR
69 “firmware_sample_driver: Firmware load failed\n”);
70 return;
71 }
72
73 /* request_firmware blocks until userspace finished, so at
74 * this point the firmware should be already in the device */
75
76 /* finish setting up the device */
77 }
78 static void sample_probe_async_cont(const struct firmware *fw, void *context)
79 {
80 if(!fw){
81 printk(KERN_ERR
82 “firmware_sample_driver: firmware load failed\n”);
83 return;
84 }
85
86 printk(“firmware_sample_driver: device pointer \”%s\”\n”,
87 (char *)context);
88 sample_firmware_load(fw->data, fw->size);
89 }
90 static void sample_probe_async(void)
91 {
92 /* Let’s say that I can’t sleep */
93 int error;
94 error = request_firmware_nowait (THIS_MODULE,
95 “sample_driver_fw”, &ghost_device,
96 “my device pointer”,
97 sample_probe_async_cont);
98 if(error){
99 printk(KERN_ERR
100 “firmware_sample_driver:”
101 ” request_firmware_nowait failed\n”);
102 }
103 }
104
105 static int sample_init(void)
106 {
107 #ifdef WE_CAN_NEED_FIRMWARE_BEFORE_USERSPACE_IS_AVAILABLE
108 register_firmware(“sample_driver_fw”, inkernel_firmware,
109 sizeof(inkernel_firmware));
110 #endif
111 device_initialize(&ghost_device);
112 /* since there is no real hardware insertion I just call the
113 * sample probe functions here */
114 sample_probe_specific();
115 sample_probe_default();
116 sample_probe_async();
117 return 0;
118 }
119 static void __exit sample_exit(void)
120 {
121 }
122
123 module_init (sample_init);
124 module_exit (sample_exit);
125
126 MODULE_LICENSE(“GPL”);
The kernel doesn’t actually load any firmware at all. It simply informs userspace, “I want a firmware by the name of xxx“, and waits for userspace to pipe the firmware image back to the kernel.
udev is configured to run firmware_helper when the kernel asks for firmware
If you read the source, you’ll find that Ubuntu wrote a firmware_helper which is hard-coded to first look for /lib/modules/$(uname -r)/$FIRMWARE, then /lib/modules/$FIRMWARE, and no other locations. Translating it to sh, it does approximately this:
echo -n 1 > /sys/$DEVPATH/loading
cat /lib/firmware/$(uname -r)/$FIRMWARE > /sys/$DEVPATH/data \
|| cat /lib/firmware/$FIRMWARE > /sys/$DEVPATH/data
if [ $? = 0 ]; then
echo -n 1 > /sys/$DEVPATH/loading
echo -n -1 > /sys/$DEVPATH/loading
fi
which is exactly the format the kernel expects.