linux-kernel - Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface via sysfs

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:	Tue, 2 Jul 2013 11:11:25 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Nick Dyer <nick.dyer@...ev.co.uk>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Daniel Kurtz <djkurtz@...omium.org>,
	Henrik Rydberg <rydberg@...omail.se>,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	Alan.Bowens@...el.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, pmeerw@...erw.net,
	bleung@...omium.org, olofj@...omium.org
Subject: Re: [PATCH 10/53] Input: atmel_mxt_ts - Add memory access interface
 via sysfs

On Fri, Jun 21, 2013 at 09:16:16AM -0700, Nick Dyer wrote:
> Mark Brown wrote:

> > Yes, to be honest.  I'd hope it wouldn't be increasing the number of
> > read/write operations...

> For some operations it does. For example updating the whole chip config
> (which is a common thing to want to do), it would turn a couple of write
> operations into ~20 on recent chips.

Is that really happening on peformance critical paths other than initial
power up (which could be handled more neatly anyway).

> > That still sounds like something the driver can handle (for example, by
> > eating the first error silently if it knows the chip is powered down)

> We've tried to implement this idea of tracking the chip power state in
> the driver and only eating the first error silently when necessary. But
> there are various entertaining corner cases (for example, it may or may
> not be in sleep on probe, how do you deal with intermittent i2c glitch). It
> would end up either being very brittle or an extremely complex mechanism
> involving tracking state and timers, the result of which is only to
> suppress a dmesg debug output saying "i2c retry", and to fail very slightly
> earlier in the normal i2c failure case. The normal fast path through
> this code is exactly the same.

It seems very suspicous that this device has all these problems but
others don't...

> > and of course a system integrator may choose not to copy the reference
> > design in this respect, it does seem a bit odd after all.

> You're being a bit optimistic there. Examples of devices that require
> this are Samsung Galaxy Tab 10.1, Asus Transformer TF101.

If absoluely nobody has used the separate wakeup pin then the hardware
designers are wasting a pin there...  my point isn't that nobody would
use the reference design it's that some boards will have the separate
signal.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)