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

[Marcel Holtmann <marcel@holtmann.org>]

Hi Victor,

> > 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.
> 
> You're right, I should have been more specific when I said  
> "filename", I really meant a 1:1 mapping to a file in /lib/firmware.
> 
> My question is, should we have a generic 1:1 mapping and make it  
> visible through MODULE_FIRMWARE.

please re-read my email and the initial thread about MODULE_FIRMWARE.
The MODULE_FIRMWARE extension only export the pattern used by
request_firmware(), because otherwise some tools don't know what a
kernel driver actually expects.

It happens to be a 1:1 mapping, but that is pure coincidence and a
little bit of laziness from the early users (mainly me) when providing
the first firmware script for the hotplug package. For all my drivers, I
don't need any fancy mapping.

>   Or like Jon Masters suggested have specific version numbers in the  
> pattern and have them map to specific versions in /lib/firmware and  
> make them all visible through MODULE_FIRMWARE.  I believe the  
> reasoning behind this was to make packaging drivers easier.

No. We need to make the actual file for loading the firmware appear
under the device in sysfs. So the userspace can read extra information
from the driver or device and then make its decision on which firmware
to load.

> I believe that we should have a generic mapping in the driver (i.e,  
> "firmware.bin") and let the admin or the userspace hotplug scripts  
> take care of filename policy with a link to the correct firmware  
> version.
> 
> example :
> 
> firmware.bin -> firmware-xyz.bin
> 
> The main reason for not including speciic mapping in the driver is  
> that everytime a new firmware version is released the driver has to  
> be updated and recompiled.  Its much easier to change a hotplug script.

I say, leave this up to the driver. For a couple of drivers this works
perfectly fine and I don't see any need to change my drivers and make
them more complex if it is not needed.

>From my point I don't see any advantage to make firmware loading more
complex from the kernel perspective. All this weird stuff needs to be
done in userspace. Our current way works quite good for a number devices
that need binary firmware.

I think it is better to first collect the needs of the driver authors
and make sure they understand their own needs. This is not always true.
And then we can discuss any extensions to change something. And I prefer
to have actual hardware and their drivers as an example.

The MODULE_FIRMWARE() extension is an easy and simple extension that
goes along with the current idea of request_firmware().

Regards

Marcel


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