From: Manuel Estrada Sainz <ranty@debian.org>
To: Greg KH <greg@kroah.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: request_firmware() hotplug interface.
Date: Sun, 4 May 2003 16:59:59 +0200 [thread overview]
Message-ID: <20030504145959.GA9216@ranty.ddts.net> (raw)
In-Reply-To: <20030501201943.GA3498@kroah.com>
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.
prev parent reply other threads:[~2003-05-04 14:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 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=20030504145959.GA9216@ranty.ddts.net \
--to=ranty@debian.org \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox