Messages in this thread |  | | Date | Sat, 17 May 2003 14:47:44 +1000 | From | David Gibson <> | Subject | Re: request_firmware() hotplug interface, third round. |
| |
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/
|  |