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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.