public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Manuel Estrada Sainz <ranty@debian.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Simon Kelley <simon@thekelleys.org.uk>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"Downing, Thomas" <Thomas.Downing@ipc.com>,
	jt@hpl.hp.com, Pavel Roskin <proski@gnu.org>
Subject: Re: request_firmware() hotplug interface, third round.
Date: Fri, 16 May 2003 16:59:58 -0700	[thread overview]
Message-ID: <20030516235958.GA17439@kroah.com> (raw)
In-Reply-To: <20030516233751.GA2045@ranty.ddts.net>

On Sat, May 17, 2003 at 01:37:52AM +0200, Manuel Estrada Sainz wrote:
> > > 	- Driver calls request_firmware()
> > 
> > Yeah, I agree with your comment in the code, I think a struct device *
> > should be passed here.  Or at least somewhere...
> 
>  To make compatibility with 2.4 kernel easier, I think that I'll add a
>  new 'struct device *' parameter to request_firmware(). On 2.4 kernels
>  it can be an unused 'void *'. Does that sound too ugly?

Yeah, don't use void * if you can ever help it.  As there will be two
different versions for two different kernels, just don't have that
paramater, or make it a char * like you have now for 2.4.  That seems to
make sense for 2.4 where you don't have a struct device.

> > > 	- 'hotplug firmware' gets called with ACCTION=add
> > 
> > I don't see why you need to add a new environment variable in your
> > firmware_class_hotplug() call.  What is the FIRMWARE variable for, if we
> > already have a device symlink back to the device that is asking for the
> > firmware?  Oh, you don't have that :)
> 
>  The same device can ask for different firmware images.

Ah, that makes more sense now.  Ok, I have no problem with it.

> > > 	- The call to request_firmware() returns with the firmware in a
> > > 	  memory buffer and the driver can finish loading.
> > 
> > request_firmware() can't use a static struct class_device, like you have
> > it, in order to work properly for multiple calls to request_firmware()
> > at the same time by different drivers.  Just create a new struct
> > class_device, and put it on a list, like I had to do for the tty class
> > code (and i2c_dev class code, but that isn't in the kernel to look at
> > yet...)
> 
>  Sorry, I don't know how that 'static' got there, I just wanted to
>  allocate it on the stack. But I guess that it should be dynamically
>  allocated anyway. Do I really need to put it on a list?

If you want to delete it later, you have to have some way to find it
again.  If you are just adding it and then removing it in the same
function, just allocate it dynamically, register it, sleep, and then
free it.  So then you would not need a list.

thanks,

greg k-h

  reply	other threads:[~2003-05-16 23:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15 20:03 request_firmware() hotplug interface, third round Manuel Estrada Sainz
2003-05-16  8:07 ` Oliver Neukum
2003-05-16  9:56   ` Manuel Estrada Sainz
2003-05-16 15:53     ` Oliver Neukum
2003-05-16 18:31       ` Manuel Estrada Sainz
2003-05-16 22:22         ` Oliver Neukum
2003-05-17  0:59           ` Manuel Estrada Sainz
2003-05-17  4:00             ` Robert White
2003-05-17 13:23           ` Alan Cox
2003-05-17 14:57             ` Manuel Estrada Sainz
2003-05-16 18:49       ` Jean Tourrilhes
2003-05-16 22:24         ` Oliver Neukum
2003-05-16 23:21         ` Greg KH
2003-05-16 16:09   ` Alan Cox
2003-05-16 22:13     ` Oliver Neukum
2003-05-17  4:50       ` David Gibson
2003-05-17  7:02         ` Oliver Neukum
2003-05-17  8:21           ` David Gibson
2003-05-16 13:13 ` Ingo Oeser
2003-05-16 17:07   ` Manuel Estrada Sainz
2003-05-16 22:36 ` Greg KH
2003-05-16 23:37   ` Manuel Estrada Sainz
2003-05-16 23:59     ` Greg KH [this message]
2003-05-17  4:47       ` David Gibson
2003-05-17  8:54         ` Manuel Estrada Sainz
2003-05-16 23:55   ` Oliver Neukum
2003-05-17  0:03     ` Greg KH
2003-05-17  2:42       ` Robert White
2003-05-17  4:44       ` David Gibson
2003-05-17  8:46         ` Manuel Estrada Sainz
2003-05-17  9:07           ` David Gibson
2003-05-17  9:50             ` Manuel Estrada Sainz
2003-05-17 10:30             ` Manuel Estrada Sainz
2003-05-20  5:21               ` David Gibson
2003-05-20  8:07                 ` Manuel Estrada Sainz
2003-05-21  4:21                   ` Greg KH
2003-05-21  7:06                     ` Manuel Estrada Sainz
2003-05-17 10:51   ` Manuel Estrada Sainz
2003-05-17 13:21   ` Ingo Oeser
2003-05-17 15:15     ` Manuel Estrada Sainz
     [not found] ` <Pine.LNX.4.55.0305151623520.2885@marabou.research.att.com>
2003-05-16  9:27   ` Manuel Estrada Sainz
2003-05-16 22:39   ` Greg KH

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=20030516235958.GA17439@kroah.com \
    --to=greg@kroah.com \
    --cc=Thomas.Downing@ipc.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=jt@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=proski@gnu.org \
    --cc=ranty@debian.org \
    --cc=simon@thekelleys.org.uk \
    /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