On Wed, Mar 04, 2015 at 03:57:09PM -0800, Greg KH wrote: > On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote: > > This patch adds an additional feature to the firmware_class.c module. > > To allow a unified method of specifying new firmware locations when > > drivers request a firmware binary to update their devices with, we > > have added the concept of a "fw override" > > > > A fw override is a rule that matches firmware requests based on the > > name of the device requesting the fw and what the filename for the > > fw they are requesting is, and overrides their requests with a new > > value. > > > > Overrides are set up by piping a description of the override into > > an attribute set up at /sys/class/firmware/fw_override. The string > > should be a null-deliminited list of the firmware name you want to > > over ride, the new name to replace it with, and the device name that > > you want the override to apply to. For example you could set up > > an override for a device called "my_device" so that any time it > > requests a firmware called "my_fw.bin" it instead gets "new_fw.bin" > > with the following command: > > > > echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' > > > /sys/class/firmware/fw_override > > I hate to ask, but I have to, why do you need this?
We may have single driver serve several devices (a touchscreen and a touchpad) that require different firmware/config file to function. We have several options: - modify the driver to allow changing firmware name from userspace - gets old when there are several drivers that need that; - encode part numbers in the driver and request different firmware - not easily maintainable, still has an issue that same part might be used for different devices; - replace the firmware file on disk before initiating firmware load - does not work well with read-only file systems; - have udev supply different data - udev went out of fashion; - have one central place (firmware loader) that users can control to override the names - this solution. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
