On Wed July 2 2008 16:25:07 John Kasunich wrote: > paul_c wrote: > > Tried sending to the list, but it bounces... Can't be a&%$ to fix it. > > > > > Here's some things we want from the firmware loading solution: > > > > > > 1. Developers and users who compile from source and Run-In-Place > > > must have a convenient way to choose which firmware gets sent to > > > each board. > > > > module_param(firmware, charp, 0444); > > request_firmware(&fw, firmware, dev); > > I tried to find out how this would work. Google found > http://lwn.net/Articles/32997/ which is ancient, but it is the only "in > plain english" explanation of how request_firmware works that I could > find in a quick search. If the current reality is different, please > point me to better docs.
The kernel docs are pretty good: /usr/src/$LINUX/Documentation/firmware_class/README <http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=blob;f=Documentation/firmware_class/README;h=c3480aa66ba8048bf46483544ed6fb3ebb7151eb;hb=HEAD> Also this: <http://lwn.net/Articles/242046/> > This call will create a directory with the given name under > /sys/class/firmware and populate it with two files called > loading and data. A hotplug event is then generated which, > presumably, will inspire user space to find some firmware > to feed the device. > > So we need hooks into the hotplug system. More documentation to read, > more code in our drivers, more connections to Linux APIs that have > little or nothing to do with machine control. (I sure hope nobody is > hotplugging machine control components.) The hostmot2 drivers already use the PCI hotplug system. The entire kernel device model is transitioning to that. For firmware loading in particular, it's literally just request_firmware(). > The resulting user-space process starts by setting the loading > sysfs attribute to a value of one. The actual firmware can then > be written to the data file; when the process is complete, the > loading file should be set back to zero. > > Is this user space process already provided by the hotplug system, or do > we have to write it? If the latter, how is it any better than bfload, > which is already a user space process? It already exists, it's udev and its associated helpers (firmware.sh or firmware_helper or similar). -- Sebastian Kuzminsky my brothers are protons / my sisters are neurons I stir it twice, it's instant family! -- Gogol Bordello ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
