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:
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (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.
<[email protected]> (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.
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?
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
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.
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
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
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