[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150305004827.GC3325@dtor-glaptop>
Date: Wed, 4 Mar 2015 16:48:27 -0800
From: Dmitry Torokhov <dtor@...omium.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Charlie Mooney <charliemooney@...omium.org>,
linux-kernel@...r.kernel.org, ming.lei@...onical.com
Subject: Re: [PATCH] firmware_class: Add firmware filename overrides
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists