On Thu, Jul 31, 2014 at 02:00:14PM -0700, Christopher Heiny wrote: > On 07/31/2014 10:53 AM, Dmitry Torokhov wrote: > >Hi Christopher, > > > >On Wed, Mar 12, 2014 at 06:53:56PM -0700, Christopher Heiny wrote: > >>Add support for updating firmware on RMI4 devices with V5 bootloader. > > > >I am wondering why F34 is not following the staindard RMI function > >implementation. By that I mean that it does not declare itself as struct > >rmi_function_handler and does not rely on RMI core to bind itself to the device > >if device supports it. > > Hi Dmitry, > > We originally had an F34 implementation that followed the RMI4 > function standard and exposed most of the basic F34 operations via > sysfs. However, we got feedback (both on LKML and offline) (a) > recommending to use request_firmware, and (b) improve reflash times > while (c) reducing impact on boot time, and (d) "get rid of all that > sysfs crap" (paraphrased, but close to it). > > So after looking at how some other drivers use request_firmware, we > came up with the current approach. Switching to request_firmware > definitely sped up the reflash times! Including a check to see if > firmware update is required before setting up the RMI4 > sensor/function structures also significantly reduced boot times. I am not suggesting you stop using request-firmware or introduce bazillion of new sysfs attributes. I just wondered why you have manual "binding" of F34 functionality instead of standrad RMI4 function binding, liek you do for F01, F11 and so forth. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
