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, 7 Feb 2013 15:19:56 -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 01:14 PM, Christopher Heiny wrote:
> 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.

OK, after some trivial research it turns out you're right, and I was 
right originally, but let myself be blindsided by bafflegab.  Doh!

As you mentioned, fixing the endian-ness problem is a pretty wide 
ranging change to the way things are done in the driver.  Fortunately 
it's not a structural change to the architecture of the driver.

But because it affects pretty much the whole code (which is actually a 
LOT more code than we're currently submitting - but that unsubmitted 
code will have to be updated concurrently with the submitted code to 
prevent a trainwreck), I'd like to isolate that fix to a single event.

So I propose we get all our other issues worked out, since a bunch of 
them are already in progress.  Once that stuff is stable, my team can do 
one big change to fix the endian bug.  If the code is stable, we can do 
the update on our end pretty quickly.

How does that sound?

					Chris
--
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/