Re: request_firmware() hotplug interface, third round.

David Gibson (david@gibson.dropbear.id.au)
Sat, 17 May 2003 14:47:44 +1000


On Fri, May 16, 2003 at 04:59:58PM -0700, Greg Kroah-Hartman wrote:
> 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.

Given this, would it be better to make the sysfs node name depend on
which firmware we're loading - rather than "data" always. I realise
we could just require firmware requests for a particular device
instance to be serialised, however my instinct says using different
nodes would be more robust: it will be easier to figure out what's
gone wrong if a script error or a kernel bug has resulted in
attempting to load two images at once.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/