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 17:46:29 +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 Thu, Jun 06, 2013 at 05:13:32PM +0100, Nick Dyer wrote:

> I am not a legal expert, but I have described what you suggest to people
> who are more expert in the NDA terms and they say I cannot implement a
> solution which exposes the names of all the parameters. In any case,

Who said anything about names?  I'd assume the userspace stuff is
eventually talking to the device based on numbers of some kind and I'd
expect that this would be what ends up in the API.

> Without the register names all you really have is the object protocol that
> we started with, you would end up accessing

> /sys/bus/i2c/drivers/atmel_mxt_ts/1-0020/objectX/registerX

> rather than parsing the object table once when your program started, then
> performing a read/write to offset X.

Well, assuming sysfs makes sense for this.  It's not immediately clear
to me that it does.

> And we wouldn't have won anything, because the user could still write to
> the register that turns off reporting (for example) by mistake with both
> methods.

You'd not have access to the entire device register map which seems like
a win and people would be able to integrate sensibly with things like
the overall device power management (which might help with whatever is
causing you to have to cope with failing I/O) more smoothly.

> > So this goes back to what I was saying before about the interface being
> > badly designed - if the API you have to present is really this complex
> > then you've got a big problem in kernel or out of kernel.

> Touch controllers are inherently complex system with a lot of configurable
> parameters. The fact that it's complex and changes quickly doesn't make it
> badly designed per se.

Having lots of configuration and having the parameters change regularly
doesn't immediately mean that it has to be complex - the requirement is
very common, touchscreens aren't too remarkable here.  The usual thing
is for the kernel to understand how to transfer data back and forth but
not the content of the data.

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