From: Manuel Estrada Sainz <email@example.com> To: Marcel Holtmann <firstname.lastname@example.org> Cc: Andrea Arcangeli <email@example.com>, Marcelo Tosatti <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com> Subject: Re: request_firmware() backport to 2.4 kernels Date: Sat, 26 Jul 2003 23:15:22 +0200 [thread overview] Message-ID: <20030726211522.GA16316@ranty.pantax.net> (raw) In-Reply-To: <1059253473.922.18.camel@pegasus> On Sat, Jul 26, 2003 at 11:04:27PM +0200, Marcel Holtmann wrote: > Hi Manuel, > > > 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, but Marcelo didn't answer emails relating to it (there where > > probably other more important matters back then). > > > > Since then, the 2.4 backport has been deployed and tested with > > orinoco_usb driver variant (http://orinoco-usb.alioth.debian.org/), > > as you can see in the download statistics in alioth, there has been > > more than 400 downloads of the request_firmware enabled version > > (0.2.1). And drivers on the 2.5/2.6 series are being ported to use > > request_firmware() interface. > > I've tested your patch with 2.4.22-pre8 and a modified version of my > bfusb driver. It is working fine, but I get these log entries: > > hub.c: new USB device 02:0c.0-2, assigned address 2 > firmware_class.c:call_helper: firmware: /sbin/hotplug firmware add > remove_proc_entry: bfusb003002/loading busy, count=1 > remove_proc_entry: firmware/bfusb003002 busy, count=1 > BlueFRITZ! USB loading firmware > de_put: deferred delete of loading > de_put: deferred delete of bfusb003002 > BlueFRITZ! USB device ready > > Is this a problem of your patch or is it a general /proc problem? I don't know if I can get around it, but it is a /proc issue, it dumps those messages when the kernel removes a file that is being used from userspace. Those messages should probably be changed into KERN_DEBUG. > I already ported drivers/bluetooth/bfusb.c to use the request_firmware() > interface and I will port drivers/bluetooth/bt3c_cs.c after this patch > gets merged. Great. Have a nice day Manuel -- --- Manuel Estrada Sainz <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> ------------------------ <email@example.com> ------------------- 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.
prev parent reply other threads:[~2003-07-26 21:01 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-07-26 12:16 Manuel Estrada Sainz 2003-07-26 18:55 ` Andrea Arcangeli 2003-07-26 21:04 ` Marcel Holtmann 2003-07-26 21:15 ` Manuel Estrada Sainz [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030726211522.GA16316@ranty.pantax.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: request_firmware() backport to 2.4 kernels' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
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).