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 12:14:37 +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 12:00:54PM +0100, Nick Dyer wrote:
> Mark Brown wrote:

> > The retries can just be done further up the stack?  All regmap is doing
> > with I/O errors is punting them straight back up to the caller so the
> > caller can retry just as well using regmap as it can using the raw I/O
> > protocol.

> It would have to be put into users of the debugfs interface as well.
> There's quite tight timing required to make it work properly (see patch
> [40/53]).

This is yet another reason for implementing the protocol properly
instead of trying to bodge around the kernel.  It really seems like
the biggest problem here is the decision to try to bodge the entire
thing into userspace with no kernel support.

> > Without seeing the address thing it's hard to comment.

> Patch [36/53]. If the T5 message processor is from address 100-110, you can
> do a read of 50 bytes starting at address 100, and it will return 10
> messages, but anything in regmap that tries to do bounds checking would get
> confused, I think.

That's just not going to be supported, sorry.  You can implement custom
locks and access the device directly where you need to do stuff like
that while still using regmap for actual registers though.

> Also, we would like to implement address pointer caching. maXTouch allows
> us to skip the address part of the i2c transaction if the address pointer
> in the chip hasn't changed. This speeds up interrupt handler slightly. But
> it requires extra housekeeping at a low level to remember what the address
> pointer was on the previous transaction to know whether to send it or not.

That sounded like what you were talking about, it's pretty common and is
sane enough for reads.

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