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:

quoted

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.

By the way, isn't rmi_extract_u32() is the same as le32_to_cpup()?

Hmmm.  Looks like that one escaped the sweep of roll-your-own endian 
fixes.  I'll update it.

					Chris