Hi Charles, >>>>>>>>>>> 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. >> >> It depends if the driver can determinate what the device is from >> ACPI. If yes, you can just load the corresponding fw image >> for the current device. Otherwise the ACPI can't help your problem. > > We run into the situation where to very similar devices (all the same > HW models) need to ship with the same OS image. One device may have a > pin-for-pin compatable, 2nd source version of some piece of hardware. > The device tree/etc is all the same because the two slighty different > parts are connected the same way (same i2c address, or similar). > > The only way to tell them apart is by talking to the driver once the > device is already up and running. In our motivating case it's reading > a sysfs attribute to get a manufacturer ID, but it could be anything > similar. > > If you want to be able to put a different FW on these two very similar > devices (that can only be differentiated once they're up and running) > I think this might be the best way to do it -- apart from altering the > driver for every part that needs this kind of special treatment.
if you can get a manufacturer ID over sysfs, then you can obviously pick the right firmware from within the driver. No need to play any tricks in userspace or the request_firmware interface. 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/
