On Thu, Mar 5, 2015 at 2:12 PM, Marcel Holtmann <[email protected]> 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? > > 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.
We have ACPI (for example) and no, it is not 5.0. Thanks, Dmitry -- 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/
