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

[Marcel Holtmann <marcel@holtmann.org>]

Hi Victor,

> 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.
> 
> 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.

actually it has never been really a filename. It was a simple pattern
that the initial hotplug script and later the udev script mapped 1:1 to
a filename on your filesystem. If you check the mailing list archives of
LKML and linux-hotplug you will see that I always resisted in allowing
drivers to include a directory path in that call. A couple of people
tried this and it is not what it was meant to be.

The MODULE_FIRMWARE approach simply makes this pattern visible via
modinfo, because otherwise you would have to scan the source code to
find this pattern. And to make it use you have to apply the same policy
the firmware script is applying when choosing the file. Currently this
is a 1:1 mapping.

Regards

Marcel