Okay, thanks for the reviews. My hope was to avoid having to add that feature into each driver, but that's okay. -Charlie
On Fri, Mar 6, 2015 at 3:33 PM, Marcel Holtmann <[email protected]> wrote: > 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/
