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:	Thu, 6 Jun 2013 11:03:46 +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 Wed, Jun 05, 2013 at 10:36:45PM +0100, Nick Dyer wrote:
> Dmitry Torokhov wrote:

> > What other purposes does it serve? I'd expect you need it during new
> > board bringup.

> Run-time examples would be adjusting noise suppression or touch suppression
> parameters based on something going on in the app layer (eg having
> different parameters during unlock screen), or tuning report rates based on
> application requirements, ot to inspect debug data if the touch sensor is
> faulty. You might say, well we should implement an kernel driver interface
> for these requirements, but they will vary hugely between different
> products. We are trying to keep the driver as generic as possible and push

If this interface varies dramatically between products then that sounds
like a badly designed interface.  Obviously the way the interface is
being used would be likely to vary between products but what you're
talking about sounds like parameter get/set stuff which sounds pretty
generic to me.  What userspace chooses to do with the parameters is of
course another story.

> product-specific complexity to user space. Hence exposing the register map
> and implementing user-space libraries to deal with this kind of customisation.

This sounds like a bad design decision for Linux, it's just asking for
fragility if userspace can go randomly poking round the entire register
map of the device with nothing coordinating with the driver code.

If you expose the paramters to userspace wouldn't that address the
issue?

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