linux-kernel - Re: [lm-sensors] [PATCH] adxl345 accelerometer hwmon driver

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: <4A4CF587.1030202@gmail.com>
Date:	Thu, 02 Jul 2009 17:59:35 +0000
From:	Jonathan Cameron <Jonathan.Cameron@...il.com>
To:	Mike Frysinger <vapier.adi@...il.com>
CC:	Jonathan Cameron <jic23@....ac.uk>,
	Chris Verges <chrisv@...erswitching.com>,
	linux-kernel@...r.kernel.org, lm-sensors@...sensors.org,
	Michael Hennerich <michael.hennerich@...log.com>,
	Robin Getz <rgetz@...ckfin.uclinux.org>
Subject: Re: [lm-sensors] [PATCH] adxl345 accelerometer hwmon driver

Mike Frysinger wrote:
> On Thu, Jul 2, 2009 at 13:38, Jonathan Cameron wrote:
>   
>> One interesting thing I just came across whilst searching lkml for
>> your post to reply to, was that Mike Frysinger submited a patch
>> adding some board support for an adx34x driver to bf548-ezkit.
>> I've not seen any sign of this anywhere else as yet (it hasn't
>> hit the input list which would be the obvious place) I've copied in
>> both people who signed off.  Michael or Mike able to give us more info?
>>     
>
> that's because we're still in the process of making sure it is stable.
>  I2C is a pita to work with.
> http://git.kernel.org/?p=linux/kernel/git/vapier/blackfin.git;a=commitdiff;h=43d4cabbdeb5c24f84b159c5dc369c1a60844a48
>
> the advantage here is that we have been testing our driver with actual
> hardware ...
>   
Cheat ;)

Looks like a nice driver, see what you mean about the i2c fun and games
you are having
though.
I'm particularly interested in your use of the fifo:

I've only had a quick look, but assuming I read it right, you are using
the fifo
with a watermark of 0 then spitting out 3 separate events for every
element in it.
Basically a data ready response unless you fail to read in time. Seems
like a sensible
approach with this particular chip in input type applications.

Does this work well even at the higher rates?  Seems a fair bit of
overhead but I guess
if everything is quick enough it doesn't really matter. Does this act as
a clean means
of ensuring you get a consistent set of values?

Thanks,

Jonathan

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