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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <386072610710152308o3d4a04bfgfcecafc9c345286b@mail.gmail.com>
Date:	Tue, 16 Oct 2007 14:08:04 +0800
From:	"Bryan Wu" <cooloney.lkml@...il.com>
To:	"Ahmed S. Darwish" <darwish.07@...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 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).

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?

Thanks
-Bryan Wu
-
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/