linux-kernel - RE: [PATCH 01/13] input: touchscreen: use polling mode in 88pm860x

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:	Mon, 18 Apr 2011 06:12:25 -0700
From:	Haojian Zhuang <hzhuang1@...vell.com>
To:	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>
CC:	"haojian.zhuang@...il.com" <haojian.zhuang@...il.com>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: RE: [PATCH 01/13] input: touchscreen: use polling mode in 88pm860x



>-----Original Message-----
>From: Valdis.Kletnieks@...edu [mailto:Valdis.Kletnieks@...edu]
>Sent: 2011年4月16日 10:17 PM
>To: Haojian Zhuang
>Cc: haojian.zhuang@...il.com; sameo@...ux.intel.com; linux-
>kernel@...r.kernel.org; Dmitry Torokhov
>Subject: Re: [PATCH 01/13] input: touchscreen: use polling mode in
>88pm860x
>
>On Sat, 16 Apr 2011 20:46:20 +0800, Haojian Zhuang said:
>> Measuring point on touchscreen with IRQ mode can only monitor pen-down
>> event. If finger is moving on touchscreen, it can't be monitored by
>> IRQ pen-down event. So switch to polling mode after pen-down event.
>
>>  drivers/input/touchscreen/88pm860x-ts.c |   79
>++++++++++++++++++++++++------
>
>> +/*
>> + * While 32KHz hardware timer is used for scheduler, we always assign
>HZ
>> + * to 128. It means that 1 tick costs 7.8msec.
>> + */
>> +#define MEASURE_INTERVAL_MS	(7)
>
>Is it guaranteed that this hardware part will only ever be used on
>systems
>where this is true?  How big a bug would it be if somebody tried to glue
>this
>touchscreen into some random embedded-ARM where HZ was something else,
>and
>should this be computed as a function of HZ instead of hardcoding 7?
It's 7msec whatever you choose any silicon. So it's not a problem.

>
>It *looks* like the intent of the schedule_delayed_work() call is "let's
>run
>this once a tick when we're awake *anyhow*" - but looking at the code, I
>can't
>convince myself a rounding error in computing 'interval' won't schedule
>1ms
>before or after the next tick would have been.  Isn't there a better API
>with
>slack timers or something that would do a better "next tick" job?
>
>