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?
so if you do not have an enumeration method for your hardware, then I assume you most likely have device tree in one form or another. And even if you really don't, nothing is stopping you from adding device tree. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
