Re: [PATCH 2.6.20 1/1] usb/input updated aiptek tablet driver

On Friday 09 March 2007 19:29, Pete Zaitcev wrote:
> > +/* Activity checking thread. If a sufficient period of inactivity is detected, 
> > +   the tablet's proximity is reset. */
> > +static void activity_check(unsigned long data)
> > +{
> > +     struct aiptek *aiptek = (struct aiptek *) data;
> > +
> > +     /* This timer is set *after* handling input for the table, and
> > +        cleared *before* handling it. Am guessing that we never run
> > +        concurrently the module code. */
> > +
> > +     /* info("aiptek: timeout proximity\n"); */
> > +
> > +     /* apparently over-due. Reset the misc key, no tool, no proximity */
> > +     input_report_abs(aiptek->inputdev, ABS_MISC, 0);
> > +     input_sync(aiptek->inputdev);
> > +}
> 
> This concerns me a bit. I am not 100% sure that input_sync and friends
> are safe to run from several CPUs. Usually, nobody is bitten by this,
> because they are delivered from a single IRQ. If you start doing this
> from a timer, it's not longer true. Dmitry must bless this practice
> (cc-ed). Perhas you want a spinlock here.
> 

I want to fix locking in input handlers so concurrent execution of
->event() methods is not an issue. However there will be a question
of correctness of the sequence in what events are delivered so some
kind of locking in drivers themselves still may make sense. 

-- 
Dmitry

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel