Hi Marcel, On Thu, Mar 5, 2015 at 11:11 AM, Marcel Holtmann <mar...@holtmann.org> wrote: > Hi Dmitry, > >>>>>> Specifically this was motivated by a situation where we have one >>>>>> device with a dual-sourced touchscreen. Both use the same driver but >>>>>> have different hardware & fw. Our FW updating software therefore, >>>>>> needs to be able to update with the correct FW and detect all this at >>>>>> runtime due to a read-only partition (so moving the firmware binaries >>>>>> around isn't really an option) >>>>>> Here the device has only one touchscreen at a time, but it isn't known >>>>>> until run-time which will be present. >>>>>> >>>>>> So in this case the driver is serving the same function in each >>>>>> situation (running a touchscreen) but may be working with different >>>>>> hardware. >>>>>> >>>>>> Another situation where I've personally wanted this functionality is >>>>>> on a device that uses the same touch driver for both a touchscreen and >>>>>> a touchpad on the same device. If the driver only grabs a copy of FW >>>>>> from, say, /lib/firmware/touch_fw.bin then you either need to move the >>>>>> firmware binaries around on disk to update either device, or have a >>>>>> change like this that allows you to override which filename it loads. >>>>>> The moving option is not viable if you're using a RO filesystem. >>>>> >>>>> what is the actual problem here? We have drivers that load multiple >>>>> firmware files and we have drivers that pick a different firmware >>>>> depending on some parameters it reads from the device. >>>>> >>>>> Seems this is all possible already at the moment with the existing >>>>> framework. You just need to update the drivers to operate properly. >>>>> >>>> >>>> I totally agree, this functionality is not novel. We could have added >>>> this feature into the specific driver in question, but then we will >>>> have to do the same thing on all the other drivers we might want to do >>>> this on. I guess the real problem that this solves is by adding the >>>> change here, it allows you to override firmware names for *any* driver >>>> without having to duplicate the functionality in each one as they come >>>> up. >>>> >>>> For a specific instance, here at ChromiumOS we have devices that use >>>> Atmel, Cypress, Synaptics, and Elan touchpads and touchscreens that >>>> all can encounter this issue. The Atmel driver has a similar version >>>> of this feature baked into it but the others don't. We could add a >>>> fw_filename attribute to each of these drivers, but then it would have >>>> to be maintained across (at least) four drivers. >>> >>> what I am hearing here is that you can not query the hardware and figure >>> out which manufacturer it is and with that don't know which firmware you >>> need. >> >> Right, the drivers in question (bunch of input drivers such as >> elan_ts, atmel_mxt_ts, etc) might not be able to determine the >> "proper" configuration to load. Factories quite often swap >> pin-compatible parts and want to use the same image. Also the parts >> can be swapped out during RMA while keeping the same image. Userspace >> is able to query magnitude of sources and make an informed decision >> that it then communicates to the kernel. >> >>> However if that is the case, then this seems to be something that should be >>> solved with device tree. >> >> Why are we making device tree a hard dependency here? > > device tree is suppose to describe the hardware in your devices. If you can > not determinate your hardware by enumeration or other means, then it should > be done via device tree. Seems the perfect fit here.
And if I do not have device tree? 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/
