Hi all,
This time, as Greg suggested, it is implemented on top of 'struct
class' and 'struct class_device' but the driver interface is the same
as last time.
Attached:
firmware.h
firmware_class.c:
The firmware support itself.
firmware_sample_driver.c:
Sample code on how to use from drivers.
hotplug:
A simple hotplug replacement for testing.
Makefile:
The obvious.
README:
Still pertinent pieces from the previous round.
How it works:
- Driver calls request_firmware()
- 'hotplug firmware' gets called with ACCTION=add
- /sysfs/class/firmware/dev_name/{data,loading} show up.
- echo 1 > /sysfs/class/firmware/dev_name/loading
- cat whatever_fw > /sysfs/class/firmware/dev_name/data
- echo 0 > /sysfs/class/firmware/dev_name/loading
- The call to request_firmware() returns with the firmware in a
memory buffer and the driver can finish loading.
- Driver loads the firmware.
- Driver calls release_firmware().
Notes:
- Drivers can use request_firmware() or register their own
'firmware' class_device and implement the same interface for
themselfs. If this code has better acceptance I'll also
provide a sample of the later, and make it actually possible.
- There is a race, the hotplug event gets generated on
class_device_register and before 'data' and 'loading' creation
takes place. Maybe the hotplug support could wait for
'loading' to show up.
- register_firmware can not be implemented without some form of
in-kernel firmware caching. And that is not implemented.
- fwfs could be used for firmware caching behind the scene
allowing register_firmware to be implemented and the other
uses. I could call it blobfs and make a subdirectory within
for firmware purposes.
Hope you like it
Manuel
--
--- Manuel Estrada Sainz <ranty@debian.org>
<ranty@bigfoot.com>
<ranty@users.sourceforge.net>
------------------------ <manuel.estrada@hispalinux.es> -------------------
Let us have the serenity to accept the things we cannot change, courage to
change the things we can, and wisdom to know the difference.
request_firmware() hotplug interface: ------------------------------------
Why: ---
Today, the most extended way to use firmware in the Linux kernel is linking it statically in a header file. Which has political and technical issues:
1) Some firmware is not legal to redistribute. 2) The firmware occupies memory permanently, even though it often is just used once. 3) Some people, like the Debian crowd, don't consider some firmware free enough and remove entire drivers (e.g.: keyspan).
Notes: -----
- Why OPTIONALLY caching the firmware in-kernel may be a good idea sometimes: - If the device that needs the firmware is needed to access the filesystem. When upon some error the device has to be reset and the firmware reloaded, it won't be possible to get it from userspace. e.g.: - A diskless client with a network card that needs firmware. - The filesystem is stored in a disk behind an scsi device that needs firmware. - On embedded systems (like install floppies) where there is no userspace hotplug support, 'cp firmware_file /firmware/' can be handy. And the same device can be needed to access the filesystem or not depending on the setup, so I think that the choice on what firmware to cache should be left to userspace.
- Why register_firmware()+__init can be useful: - For boot devices needing firmware. - To make the transition easier: The firmware can be declared __init and register_firmware() called on module_init. Then the firmware is warranted to be there even if "firmware hotplug userspace" is not there jet or it doesn't jet provide the needed firmware. Once the firmware is widely available in userspace, it can be removed from the kernel. Or made optional (CONFIG_.*_FIRMWARE).
In either case, if firmware hotplug support is there, it can move the firmware out of kernel memory into the real filesystem for later usage (like the provided hotplug scripts do).
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:58 EST