linux-kernel - Re: [PATCH try #3] Input/Joystick Driver: add support AD7142 joystick 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]

Date:	Tue, 16 Oct 2007 18:40:51 +0200
From:	"Ahmed S. Darwish" <darwish.07@...il.com>
To:	Bryan Wu <cooloney.lkml@...il.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>, bryan.wu@...log.com,
	Andrey Panin <pazke@...pac.ru>, Roel Kluin <12o3l@...cali.nl>,
	linux-input@...ey.karlin.mff.cuni.cz,
	linux-joystick@...ey.karlin.mff.cuni.cz,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Jean Delvare <khali@...ux-fr.org>
Subject: Re: [PATCH try #3] Input/Joystick Driver: add support AD7142 joystick driver

On Tue, Oct 16, 2007 at 02:08:04PM +0800, Bryan Wu wrote:
> On 10/16/07, Ahmed S. Darwish <darwish.07@...il.com> wrote:
> > On Mon, Oct 15, 2007 at 11:48:17AM -0400, Dmitry Torokhov wrote:
> > > Hi Bryan,
> > >
> > > On 10/15/07, Bryan Wu <bryan.wu@...log.com> wrote:
> > > > +
> > > > +static int ad7142_thread(void *nothing)
> > > > +{
> > > > +       do {
> > > > +               wait_for_completion(&ad7142_completion);
> > > > +               ad7142_decode();
> > > > +               enable_irq(CONFIG_BFIN_JOYSTICK_IRQ_PFX);
> > > > +       } while (!kthread_should_stop());
> > > > +
> > >
> > > No, this is not going to work well:
> > > - you at least need to reinitialize the completion before enabling
> > > IRQ, otherwise you will spin in a very tight loop
> > > - if noone would touch the joystick ad7142_clsoe would() block
> > > infinitely because noone would signal the completion and
> > > ad7142_thread() would never stop.
> > >
> > > Completion is just not a good abstraction here... Please use work
> > > abstraction and possibly a separate workqueue.
> > >
> >
> > Bryan, I'm very interested in the technical advantage of using a completion
> > here.
> >
> You are welcome, I'd like to discuss these things here.
> 
> > In my _not-experienced_ opinion, I remember completions was created mainly for
> > "create_task, wait till task got finished, go on" case. Why using it in a
> > different context while workqueues was created for a similar situation to
> > ad7142 one (non-irq context bottom-half) ?
> 
> I like completion because it is simple to use and understand. Your
> understanding is right. But there is no limit for using different
> context with completion. completion is a wrapper of waitqueue+done
> flag. For some drivers, in process context call
> wait_for_completetion(), then schedule out and in irq handler call
> complete(). This is very simple and helpful for driver design (For
> example, you call dma function to transfer data, then you schedule out
> and then DMA IRQ handler will call complete() to wakeup you).
> 

Thank you for such a useful information.

> But in this driver, a) can not call ad7142_decode() in IRQ handler,
> because it will sleep in IRQ context by calling some i2c API, b) in
> original design, creating a new kthread and using some waitqueue API
> is the same way as using workqueue, c) cannot use completion as Dmitry
> said.
> 
> I am going to use workqueue here.
> 
> Any idea?
> 

I have no better thoughts than the ones provided by Dmitry actually.

> Thanks
> -Bryan Wu

Regards :),

-- 
Ahmed S. Darwish
HomePage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
-
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/