From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sun, 20 Mar 2005 17:16:58 +0000 Subject: Re: Rework of request firmware Message-Id: <1111339018.21516.51.camel@localhost.localdomain> List-Id: References: <9e473391050319200625032789@mail.gmail.com> In-Reply-To: <9e473391050319200625032789@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Sun, 2005-03-20 at 10:35 -0500, Jon Smirl wrote: > On Sun, 20 Mar 2005 14:37:16 +0100, Kay Sievers wrote: > > What is the concept of a "post"? Does it receive data for the kernel to > > use? What is the overlap with firmware loading here? You just need to > > run a program from userspace, right? > > Post is the commonly used term for what you do to hardware when it is > first turned on to get it running. For example the system BIOS posts > all the devices in the system. Ok, the Power On Self Test. That sounds a bit specfic for something that is a generic configuration request. > The system BIOS does not post secondary video cards. For these cards > when the driver is first loaded I have to run a program that takes the > video BIOS ROM on the card and runs it in vm86/emu86. The ROM contents > are already exposed in sysfs. If I don't do this the hardware will not > respond. The system BIOS does this for you in real mode on the primary > card during the boot process. Another time the video BIOS needs to be > run is when graphics cards are being resumed. The posting program > needs to run in user space and be triggered from the probe function. Ah, ok. Sounds reasonable and like a nice trick too, to run x86 hardware on other platforms. :) > I initially started to add support for post as a standalone service > but received complaints on lkml that the code needed was almost > identical to request_firmware(). Well running a configuration program is just a very small subset compared to copying data into the kernel, but anyway... > BenH has also pointed out that the > synchronous request_firmware() will deadlock in many cases during the > resume process. I believe that and events may get lost too in such situations. Thanks, Kay ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel