request_firmware() backport to 2.4

request_firmware() backport to 2.4

[Marcel Holtmann]

Hi Marcelo,

I have collected the patches for the request_firmware() interface
backport for 2.4 done by Manuel Estrada Sainz. It is now in -ac for a
while and I have used it in my -mh patches. It works fine and seems to
be clean and very stable. Karsten Keil has tested it together with my
ported bfusb.o Bluetooth driver on AMD64.

Regards

Marcel


Please do a

        bk pull http://linux-mh.bkbits.net/fw-loader-2.4

This will update the following files:

 drivers/bluetooth/bfusb.h                             |52261 ------------------
 Documentation/Configure.help                          |    6 
 Documentation/firmware_class/README                   |   58 
 Documentation/firmware_class/firmware_sample_driver.c |  121 
 Documentation/firmware_class/hotplug-script           |   16 
 drivers/bluetooth/Makefile.lib                        |    1 
 drivers/bluetooth/bfusb.c                             |   38 
 include/linux/firmware.h                              |   20 
 lib/Config.in                                         |    7 
 lib/Makefile                                          |    4 
 lib/firmware_class.c                                  |  581 
 11 files changed, 830 insertions(+), 52283 deletions(-)

through these ChangeSets:

<marcel@holtmann.org> (03/08/19 1.1078.1.5)
   [PATCH] Make request_firmware() compile cleanly
   
   This patch makes the request_firmware() compile on other platforms
   than i386. It adds the missing include <linux/init.h> and replaces
   some ssize_t with int.

<marcel@holtmann.org> (03/08/16 1.1078.1.4)
   [Bluetooth] Make use of request_firmware() for the BlueFRITZ! USB driver
   
   The BlueFRITZ! USB devices need a firmware download every time they are
   plugged in. With request_firmware() the file bfubase.frm is now loaded
   from the userspace and the included firmware is removed.

<marcel@holtmann.org> (03/08/15 1.1078.1.3)
   [PATCH] Firmware loading depends on hotplug support
   
   This patch makes the firmware loading support only selectable if the
   hotplug support is also enabled.

<marcel@holtmann.org> (03/08/11 1.1078.1.2)
   [PATCH] Make request_firmware() compile if hotplug support is disabled
   
   This patch fixes the problem, where hotplug support is disabled and an
   internal kernel driver uses request_firmware(). The driver will compile
   and load now, but it must handle the case where the firmware loading
   fails, because the kernel is build without hotplug support, by itself.

<ranty@debian.org> (03/08/11 1.1078.1.1)
   [PATCH] request_firmware() backport to 2.4 kernels
   
   A while back request_firmware() was added to the 2.5 kernel series
   to support firmware needing drivers keeping the firmware images in
   userspace. And I also backported it to the 2.4 kernel series on top
   of procfs.

Re: request_firmware() backport to 2.4

[Marcelo Tosatti]

On 25 Aug 2003, Marcel Holtmann wrote:

> Hi Marcelo,
> 
> I have collected the patches for the request_firmware() interface
> backport for 2.4 done by Manuel Estrada Sainz. It is now in -ac for a
> while and I have used it in my -mh patches. It works fine and seems to
> be clean and very stable. Karsten Keil has tested it together with my
> ported bfusb.o Bluetooth driver on AMD64.
> 
> Regards
> 
> Marcel
> 
> 
> Please do a
> 
>         bk pull http://linux-mh.bkbits.net/fw-loader-2.4
> 
> This will update the following files:
> 
>  drivers/bluetooth/bfusb.h                             |52261 ------------------

Now bfusb loads "bfubase.frm", but stock kernel has no such thing. 

I assume that breaks bfusb?

Re: request_firmware() backport to 2.4

[Marcel Holtmann]

Hi Marcelo,

> > I have collected the patches for the request_firmware() interface
> > backport for 2.4 done by Manuel Estrada Sainz. It is now in -ac for a
> > while and I have used it in my -mh patches. It works fine and seems to
> > be clean and very stable. Karsten Keil has tested it together with my
> > ported bfusb.o Bluetooth driver on AMD64.
> > 
> > Please do a
> > 
> >         bk pull http://linux-mh.bkbits.net/fw-loader-2.4
> > 
> > This will update the following files:
> > 
> >  drivers/bluetooth/bfusb.h                             |52261 ------------------
> 
> Now bfusb loads "bfubase.frm", but stock kernel has no such thing. 
> 
> I assume that breaks bfusb?

no, the bfubase.frm is the original firmware file from AVM. This file
have to be placed somewhere on the filesystem. And if you call
request_firmware() this will call the firmware.agent hotplug script,
which loads it into the kernel through the /proc interface. This is the
big advantage of the request_firmware() architecture, because we don't
have to place the firmware as header file in the kernel source. The
firmware can be replaced with a newer version without recompiling the
kernel, because the only thing you have to do is to unplug and replug
the device. This also solves some legal problems with firmwares from
companies who are not so Linux friendly like AVM.

I have some short infos about the driver itself under

	http://www.holtmann.org/linux/bluetooth/bfusb.html

Another driver which makes use of request_firmware() interface at the
moment is the orinoco_usb.o wireless lan driver:

	http://orinoco-usb.alioth.debian.org

Regards

Marcel

Re: request_firmware() backport to 2.4

[Marcelo Tosatti]

On 1 Sep 2003, Marcel Holtmann wrote:

> Hi Marcelo,
> 
> > > I have collected the patches for the request_firmware() interface
> > > backport for 2.4 done by Manuel Estrada Sainz. It is now in -ac for a
> > > while and I have used it in my -mh patches. It works fine and seems to
> > > be clean and very stable. Karsten Keil has tested it together with my
> > > ported bfusb.o Bluetooth driver on AMD64.
> > > 
> > > Please do a
> > > 
> > >         bk pull http://linux-mh.bkbits.net/fw-loader-2.4
> > > 
> > > This will update the following files:
> > > 
> > >  drivers/bluetooth/bfusb.h                             |52261 ------------------
> > 
> > Now bfusb loads "bfubase.frm", but stock kernel has no such thing. 
> > 
> > I assume that breaks bfusb?
> 
> no, the bfubase.frm is the original firmware file from AVM. This file
> have to be placed somewhere on the filesystem. 

Right, and without placing the file somewhere on the filesystem bfusb
2.4.22 users wont have 2.4.23 working without "issues".

But well, I dont know if I should care that much. 

Re: request_firmware() backport to 2.4

[Marcel Holtmann]

Hi Marcelo,

> > > Now bfusb loads "bfubase.frm", but stock kernel has no such thing. 
> > > 
> > > I assume that breaks bfusb?
> > 
> > no, the bfubase.frm is the original firmware file from AVM. This file
> > have to be placed somewhere on the filesystem. 
> 
> Right, and without placing the file somewhere on the filesystem bfusb
> 2.4.22 users wont have 2.4.23 working without "issues".

this is correct, but the firmware in bfusb.h of 2.4.22 is outdated and
it have some problems which are fixed in the newer firmware versions.

The development progress in Bluetooth is very fast at the moment and the
companies are fixing the problems with their own schedule. The driver
interface of the bfusb.o is clean and stable and in the most cases we
have no chance to workaround any problems in the Bluetooth firmware,
because we don't have access to the link manager. A new firmware means
recompile and pushing you a new bfusb.h (after I got the permission from
AVM) and this can happen very often in a 2.4.x release cycle.

> But well, I dont know if I should care that much. 

I already thought about it, because the request_firmware() can report
back if a firmware file is not found and in this case it can load the
included firmware. But as stated above the firmware is outdated and so I
decided to remove it completly.

Regards

Marcel

Re: request_firmware() backport to 2.4

[Jeff Garzik]

Jean Tourrilhes wrote:
> Marcelo wrote :
> 
>>On 1 Sep 2003, Marcel Holtmann wrote:
>>
>>
>>>no, the bfubase.frm is the original firmware file from AVM. This file
>>>have to be placed somewhere on the filesystem. 
>>
>>Right, and without placing the file somewhere on the filesystem bfusb
>>2.4.22 users wont have 2.4.23 working without "issues".
> 
> 
> 	But various high level kernel people, such as Jeff, have
> decided that binary firmwares *must* be removed from the kernel
> because of legal "issues" (GPL == source available). In 2.6.X, it
> seems that the tolerance towards this "issue" will end, so all those
> nasty details will have to work.

Well, I wouldn't put it that strongly.

It's more like, at least in my own case, the Debian people make a stink 
about the legality of non-GPL'd firmwares.  And certain people, and at 
certain times, have refused patches related to legality of firmwares. 
AND, on top of all that, as a programmer I hate seeing these ugly BLOBs 
embedded in C code, and would much rather see them removed from the C 
source code.

So, I "prefer" that firmware leaves the kernel, but that's just my 
personal opinion.  There has been no decision made AFAIK, and I don't 
recall Marcelo or Linus speaking definitively on the subject.


> 	Of course, 2.4.X is more "don't rock the boat".

Agreed...

	Jeff

Re: request_firmware() backport to 2.4

[Jean Tourrilhes]

Marcelo wrote :
> On 1 Sep 2003, Marcel Holtmann wrote:
> 
> > no, the bfubase.frm is the original firmware file from AVM. This file
> > have to be placed somewhere on the filesystem. 
> 
> Right, and without placing the file somewhere on the filesystem bfusb
> 2.4.22 users wont have 2.4.23 working without "issues".

	But various high level kernel people, such as Jeff, have
decided that binary firmwares *must* be removed from the kernel
because of legal "issues" (GPL == source available). In 2.6.X, it
seems that the tolerance towards this "issue" will end, so all those
nasty details will have to work.
	Of course, 2.4.X is more "don't rock the boat".

	Have fun...

	Jean