linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* request_firmware() hotplug interface.
@ 2003-05-01 19:47 Manuel Estrada Sainz
  2003-05-01 20:19 ` Greg KH
  0 siblings, 1 reply; 5+ messages in thread
From: Manuel Estrada Sainz @ 2003-05-01 19:47 UTC (permalink / raw)
  To: LKML; +Cc: Alan Cox, David Gibson, Perez-Gonzalez, Inaky

[-- Attachment #1: Type: text/plain, Size: 671 bytes --]

 Hi all,

 After the feedback on fwfs, here is my new attempt to move the firmware
 to userspace.

 This time there is working hotplug functionality including preliminary
 firmware.* hotplug scripts.

 Attached goes the README and sample driver code for easy inspection and
 a full tarball for testing.

 Have a nice day

 	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.

[-- Attachment #2: README --]
[-- Type: text/plain, Size: 3879 bytes --]


 request_firmware() hotplug interface:
 ------------------------------------

 This is not finished code, but most of the functionality is already there.

 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).

 What:
 ----

 My current plan consists on implementing two pieces:

 1) A simple interface for drivers to ask for a named piece of firmware via
    hotplug.
 2) A default way to get the firmware from user space into a [virtually]
    contiguous memory buffer for drivers to use with ease.
	- Currently fwfs

 Drivers should be able to use 1) without using 2) as shown in
 firmware_sample_driver.c. In that case arrangements should be made for
 hotplug scripts to do the firmware load by themselves either via sysfs or some
 way else.
 
 As much information as possible should be set on the environment so hotplug
 scripts can do the job when 1) is used without 2). Currently just an string
 provided by the driver is set as 'DEVICE'. Once ported to 2.5 'struct device'
 can be used instead and more information will be available.

 Notes:
 -----

 - Even though the Makefile has 2.5 support the code does not. I'll port it
   once we agree on how all this should be done.

 - Why I don't think any more that sysfs is good as "the default" for
   userspace to provide the firmware:
	- For drivers providing a sysfs entry for firmware:
		It will be trivial to use request_firmware() and arrange the
		hotplug scripts to get it copied to their sysfs firmware
		entry. They don't need any additional support for copying the
		firmware from userspace.
	- For drivers not providing a sysfs entry for firmware:
		They just want the appropriate firmware in a memory buffer. It
		doesn't make much sense to hack some code to get a sysfs entry
		for them and then tell hotplug where to copy the firmware.
		The driver won't know that the entry is there, and it won't
		make sense to write data to it unless requested via hotplug.

   If fwfs is finally not found appropriate, I think that a simpler more
   specific implementation should be better.
	
 - 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).

[-- Attachment #3: firmware_sample_driver.c --]
[-- Type: text/x-csrc, Size: 1965 bytes --]

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include "firmware.h"

#define WE_CAN_NEED_FIRMWARE_BEFORE_USERSPACE_IS_AVAILABLE
#ifdef WE_CAN_NEED_FIRMWARE_BEFORE_USERSPACE_IS_AVAILABLE
char __init inkernel_firmware[] = "let's say that this is firmware\n";
#endif

static void sample_firmware_load(char *firmware, int size)
{
	printk("firmware_sample_driver: firmware: %s\n", firmware);
}

static void sample_probe_default(void)
{
	/* uses the default method to get the firmware */
        const struct firmware *fw_entry;
	printk("firmware_sample_driver: a ghost device got inserted :)\n");

        if(request_firmware(&fw_entry, "sample_driver_fw", "ghost0")!=0)
	{
		printk(KERN_ERR
		       "firmware_sample_driver: Firmware not available\n");
		return;
	}
	
	sample_firmware_load(fw_entry->data, fw_entry->size);

	release_firmware(fw_entry);

	/* finish setting up the device */
}
static void sample_probe_specific(void)
{
	/* Uses some specific hotplug support to get the firmware from
	 * userspace  directly into the hardware, or via some sysfs file */
	printk("firmware_sample_driver: a ghost device got inserted :)\n");

        if(request_firmware(NULL, "sample_driver_fw", "ghost0")!=0)
	{
		printk(KERN_ERR
		       "firmware_sample_driver: Firmware load failed\n");
		return;
	}
	
	/* request_firmware blocks until userspace finished, so at
	 * this point the firmware should be already in the device */

	/* finish setting up the device */
}

static int __init sample_init(void)
{
#ifdef WE_CAN_NEED_FIRMWARE_BEFORE_USERSPACE_IS_AVAILABLE
	register_firmware("sample_driver_fw", inkernel_firmware,
			  sizeof(inkernel_firmware));
#endif
	/* since there is no real hardware insertion I just call the
	 * sample probe functions here */
	sample_probe_specific();
	sample_probe_default();
	return 0;
}
static void __exit sample_exit(void)
{
}

module_init (sample_init);
module_exit (sample_exit);

MODULE_LICENSE("GPL");

[-- Attachment #4: request_firmware-2003-05-01.tar.bz2 --]
[-- Type: application/octet-stream, Size: 10077 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: request_firmware() hotplug interface.
  2003-05-01 19:47 request_firmware() hotplug interface Manuel Estrada Sainz
@ 2003-05-01 20:19 ` Greg KH
  2003-05-01 23:32   ` Jeff Muizelaar
  2003-05-04 14:59   ` Manuel Estrada Sainz
  0 siblings, 2 replies; 5+ messages in thread
From: Greg KH @ 2003-05-01 20:19 UTC (permalink / raw)
  To: Manuel Estrada Sainz; +Cc: LKML, Alan Cox, David Gibson, Perez-Gonzalez, Inaky

On Thu, May 01, 2003 at 09:47:02PM +0200, Manuel Estrada Sainz wrote:
> 
>  - Why I don't think any more that sysfs is good as "the default" for
>    userspace to provide the firmware:
> 	- For drivers providing a sysfs entry for firmware:
> 		It will be trivial to use request_firmware() and arrange the
> 		hotplug scripts to get it copied to their sysfs firmware
> 		entry. They don't need any additional support for copying the
> 		firmware from userspace.

With the code in the latest -bk tree, if you simply create a struct
class and name it "firmware", and then just create a struct class_device
for any struct device that wants firmware to be loaded, you will get a
hotplug event generated for you (with the name "firmware")
automatically.  That is a lot simpler than the firmware.c code you
posted.

> 	- For drivers not providing a sysfs entry for firmware:
> 		They just want the appropriate firmware in a memory buffer. It
> 		doesn't make much sense to hack some code to get a sysfs entry
> 		for them and then tell hotplug where to copy the firmware.
> 		The driver won't know that the entry is there, and it won't
> 		make sense to write data to it unless requested via hotplug.

As all devices in the kernel should now be in sysfs (if not, please let
me know what busses haven't been converted yet), I think the firmware
class is a much simpler way to go.  You get the hotplug call for free,
and a sysfs entry where the firmware can be dumped to, if you want to do
it that way.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: request_firmware() hotplug interface.
  2003-05-01 20:19 ` Greg KH
@ 2003-05-01 23:32   ` Jeff Muizelaar
  2003-05-02  0:11     ` Greg KH
  2003-05-04 14:59   ` Manuel Estrada Sainz
  1 sibling, 1 reply; 5+ messages in thread
From: Jeff Muizelaar @ 2003-05-01 23:32 UTC (permalink / raw)
  To: Greg KH; +Cc: LKML

Greg KH wrote:

>As all devices in the kernel should now be in sysfs (if not, please let
>me know what busses haven't been converted yet), 
>
How about plain old isa?

-Jeff


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: request_firmware() hotplug interface.
  2003-05-01 23:32   ` Jeff Muizelaar
@ 2003-05-02  0:11     ` Greg KH
  0 siblings, 0 replies; 5+ messages in thread
From: Greg KH @ 2003-05-02  0:11 UTC (permalink / raw)
  To: Jeff Muizelaar; +Cc: LKML

On Thu, May 01, 2003 at 07:32:03PM -0400, Jeff Muizelaar wrote:
> Greg KH wrote:
> 
> >As all devices in the kernel should now be in sysfs (if not, please let
> >me know what busses haven't been converted yet), 
> >
> How about plain old isa?

ISA PnP is converted, I don't think plain isa is.  I think a lack of
hardware and usage is probably keeping this one from being converted.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: request_firmware() hotplug interface.
  2003-05-01 20:19 ` Greg KH
  2003-05-01 23:32   ` Jeff Muizelaar
@ 2003-05-04 14:59   ` Manuel Estrada Sainz
  1 sibling, 0 replies; 5+ messages in thread
From: Manuel Estrada Sainz @ 2003-05-04 14:59 UTC (permalink / raw)
  To: Greg KH; +Cc: LKML

 Hi Greg,

 Sorry, for the delay, I wanted to answer already with some code, but I
 am too outdated on 2.5 development :(, so it will take a while.

On Thu, May 01, 2003 at 01:19:43PM -0700, Greg KH wrote:
> On Thu, May 01, 2003 at 09:47:02PM +0200, Manuel Estrada Sainz wrote:
> > 
> >  - Why I don't think any more that sysfs is good as "the default" for
> >    userspace to provide the firmware:
> > 	- For drivers providing a sysfs entry for firmware:
> > 		It will be trivial to use request_firmware() and arrange the
> > 		hotplug scripts to get it copied to their sysfs firmware
> > 		entry. They don't need any additional support for copying the
> > 		firmware from userspace.
> 
> With the code in the latest -bk tree, if you simply create a struct
> class and name it "firmware", and then just create a struct class_device
> for any struct device that wants firmware to be loaded, you will get a
> hotplug event generated for you (with the name "firmware")
> automatically.  That is a lot simpler than the firmware.c code you
> posted.

 Sounds promising, I'll try to code something on top of that.

> > 	- For drivers not providing a sysfs entry for firmware:
> > 		They just want the appropriate firmware in a memory buffer. It
> > 		doesn't make much sense to hack some code to get a sysfs entry
> > 		for them and then tell hotplug where to copy the firmware.
> > 		The driver won't know that the entry is there, and it won't
> > 		make sense to write data to it unless requested via hotplug.
> 
> As all devices in the kernel should now be in sysfs (if not, please let
> me know what busses haven't been converted yet),

 As said, I am outdated on 2.5 development, if I find any while I look at
 it, I promise to complain.

> I think the firmware class is a much simpler way to go.  You get the
> hotplug call for free, and a sysfs entry where the firmware can be
> dumped to, if you want to do it that way.

 Sounds good.

 Thanks

 	Manuel

 PS: Not much new, mainly proving that I'm not ignoring you :), I'm
 working on it.

-- 
--- 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-05-04 14:47 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-01 19:47 request_firmware() hotplug interface Manuel Estrada Sainz
2003-05-01 20:19 ` Greg KH
2003-05-01 23:32   ` Jeff Muizelaar
2003-05-02  0:11     ` Greg KH
2003-05-04 14:59   ` Manuel Estrada Sainz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).