linux-kernel - Re: [PATCH 04/05] input: RMI4 F01 device control

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 31 Jan 2013 13:14:10 -0800
From:	Christopher Heiny <cheiny@...aptics.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Jean Delvare <khali@...ux-fr.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linux Input <linux-input@...r.kernel.org>,
	Allie Xiong <axiong@...aptics.com>,
	Vivian Ly <vly@...aptics.com>,
	Daniel Rosenberg <daniel.rosenberg@...aptics.com>,
	Alexandra Chin <alexandra.chin@...synaptics.com>,
	Joerie de Gram <j.de.gram@...il.com>,
	Wolfram Sang <w.sang@...gutronix.de>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Linus Walleij <linus.walleij@...ricsson.com>
Subject: Re: [PATCH 04/05] input: RMI4 F01 device control

On 01/31/2013 12:08 AM, Dmitry Torokhov wrote:
> Hi Chris,
>
> On Fri, Jan 18, 2013 at 05:12:44PM -0800, Christopher Heiny wrote:
>> In addition to the changes described in 0/0 of this patchset, this patch
>> includes device serialization updated to conform to the latest RMI4
>> specification.
>
> I was looking at the various aspects of the RMI4 patchset, trying to
> fix the issues that I see, but there is one big issue that I simply do
> not have time to tackle - the driver is completely broken on big endian
> architectures due to reliance on bitfileds when exchanging the data with
> the device.

Grumble.  I brought this up during the original development, but was 
assured that it would work fine per the C language spec.  I'll have to 
revisit that discussion and report back.

Also, I noticed you merged F01 header into F01.  That's going to have to 
be backed out, because F05, F34, and F54 are also interested in the F01 
stuff, as is the (proposed) F01 diagnostic module.  We just aren't 
submitting that code right now in order to keep the code down to a 
managable size.

> Consider the following structures:
>
>>   struct f01_device_status {
>> -	u8 status_code:4;
>> +	enum rmi_device_status status_code:4;
>>   	u8 reserved:2;
>>   	u8 flash_prog:1;
>>   	u8 unconfigured:1;
>> @@ -159,4 +136,113 @@ struct f01_device_control_0 {
>>   	u8 configured:1;
>>   } __attribute__((__packed__));
>>
>> +/**
>> + * @reset - set this bit to force a firmware reset of the sensor.
>> + */
>> +struct f01_device_commands {
>> +	u8 reset:1;
>> +	u8 reserved:7;
>> +};
>> +
>
> To make this work on BE boxes you either need to add #ifdefs to the
> structures reversing the order of fields or use bit shifts and masks to
> get/set specific bits in bytes.
>
> I tried converting F01 code (you can see the [likely broken as I can't
> test] result in my tree), but I really do not have time for F11.
>
> Thanks.
>


-- 

Christopher Heiny
Senior Staff Firmware Engineer
Synaptics Incorporated
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/