[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170209181018.GB8862@dtor-ws>
Date: Thu, 9 Feb 2017 10:10:18 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Robin van der Gracht <robin@...tonic.nl>
Cc: Miguel Ojeda Sandonis <miguel.ojeda.sandonis@...il.com>,
linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH 2/3] auxdisplay: ht16k33: rework input device
initialization
Hi Robin,
On Wed, Feb 08, 2017 at 05:48:02PM +0100, Robin van der Gracht wrote:
> On Tue, 31 Jan 2017 12:54:37 -0800
> Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
> > +
> > + err = devm_request_threaded_irq(&client->dev, client->irq,
> > + NULL, ht16k33_keypad_irq_thread,
> > + IRQF_TRIGGER_RISING | IRQF_ONESHOT,
> > + DRIVER_NAME, keypad);
>
> I believe the interrupt trigger should be switched to IRQF_TRIGGER_HIGH
> combined with IRQF_ONESHOT, for this new setup. This is causing a race
> condition.
>
> In the previous situation a 'key data' read was triggered by
> ht16k33_keypad_start(). This cleared the IRQ and gave a (somewhat racy)
> known state. Now, when the IRQ line is HIGH during probe keyscan
> wont work.
>
> Also, when ht16k33_keypad_stop() is run while the irq thread is waiting
> for debounce, the scan will be skipped and irq will never be cleared.
> This also breaks keyscan.
You are absolutely right, I shoudl have changed this to
IRQF_TRIGGER_HIGH. I'll resend updated patch series in a minute.
Thanks.
--
Dmitry
Powered by blists - more mailing lists