Re: [PATCH][RFC] request_firmware examples and MODULE_FIRMWARE

[Jon Masters <jonathan@jonmasters.org>]

On Mon, 2006-09-04 at 14:02 -0700, Andrew Morton wrote:

> > Also, I'd like to comment on Jon Masters push to include the  
> > MODULE_FIRMWARE api addition.  I strongly believe that policy should  
> > not be included in driver code, in this case it's in the form of a  
> > filename.
> 
> You should have cc'ed him!  Some people are not subscribed, and few read
> it all.

Thanks. My lkml subscription bounced last week after I decided to
overhaul my home email (moving country in a couple of weeks...).

I disagree that MODULE_FIRMWARE encodes policy in the driver. It encodes
a reference - nothing more. We need to know what firmware we're going to
be asked for if we have any hope of being able to package up drivers for
use in distro initrds and the like. I think we can agree on that much.

Some alternatives:

* The firmware API get hacked yet again to use static strings we can
parse (ugly) or otherwise somehow provide this information.

* We add hacks in userspace "if it's this driver and someone used
MODULE_VERSION correctly, and we can determine the right firmware...".

> > The firmware loader currently needs a filename passed to it so it can  
> > then pass the $FIRMWARE environment variable to the hotplug script.   
> > This is ok if you provide a generic filename like "firmware.bin" and  
> > then let the hotplug script worry about version numbers, i.e.  
> > "firmware-x.y.z.bin"

> > MODULE_FIRMWARE should be used to provide the generic filenames and  
> > which order the files should be loaded (request_firmware can be  
> > called various times), but I think its bad to have to change the  
> > driver everytime a new firmware version is released.
> 
> Yes, that does sound bad, but what would I know ;)

I'm ok with the idea of having a generic name, but it does add more
processing in userspace. Frankly, I don't care what is adopted but
something needs to be done - sooner or later, it's going to be more
drivers than Qlogic (and a few others) we need this working for :-)

I'm optimistic that we'll find the right one line patch eventually!

Jon.