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 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/

Reply via email to