Sebastian Kuzminsky wrote: > 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). > > Gotta go away for a few hours - I'll look at some of those docs when I get back. Hopefully we can talk about this later this evening on IRC.
Regards, John Kasunich ------------------------------------------------------------------------- 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
