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]

Message-ID: <51DE61B5.1000600@itdev.co.uk>
Date:	Thu, 11 Jul 2013 08:41:41 +0100
From:	Nick Dyer <nick.dyer@...ev.co.uk>
To:	Mark Brown <broonie@...nel.org>
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

Mark Brown wrote:
> 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).

Well, you're right that we could probably add more API for performance
critical stuff. But that wasn't your original question.

>>> 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.

That's entirely hypothetical, and you're wasting our time until you can
actually point to such hardware, happy to write patches to support that
mode of operation as well if you do.
--
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/