linux-kernel - Re: [RFC/RFT] Remove polling timer from i8042

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]

Message-ID: <20060728202737.GC5313@suse.cz>
Date:	Fri, 28 Jul 2006 22:27:37 +0200
From:	Vojtech Pavlik <vojtech@...e.cz>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	linux-kernel@...r.kernel.org, Dave Jones <davej@...hat.com>
Subject: Re: [RFC/RFT] Remove polling timer from i8042

On Fri, Jul 28, 2006 at 10:20:00AM -0400, Dmitry Torokhov wrote:
> On 7/28/06, Vojtech Pavlik <vojtech@...e.cz> wrote:
> >On Fri, Jul 28, 2006 at 08:57:31AM -0400, Dmitry Torokhov wrote:
> >
> >> On 7/27/06, Vojtech Pavlik <vojtech@...e.cz> wrote:
> >> >On Thu, Jul 27, 2006 at 12:29:04AM -0400, Dmitry Torokhov wrote:
> >> >> Hi,
> >> >>
> >> >> OK, I had it in works for quite some time and Dave's talk in Ottawa
> >> >> made me finish it ;)
> >> >
> >> >Good work.
> >> >
> >> >However I believe you need to test the AUX IRQ in this case before you
> >> >use it, otherwise you'll have a lot of people with non-working keyboards
> >> >(the input queue is shared), and probably also non-working PCI cards
> >> >(BIOSes like to assign IRQ12 to PCI if no mouse is detected by the
> >> >BIOS).
> >> >
> >>
> >> What do you mean by testing AUX IRQ? Use I8042_CMD_AUX_LOOP to see if
> >> interrupt fires off? The new code releases IRQ if it can't find a
> >> working AUX port...
> >
> >Exactly. Not that a character arrives and can be polled for, but that
> >the interrupt actually gets raised. It can be routed to nowhere and
> >we'll never know, our buffers will be full and keyboard will be stuck.
> >
> 
> Riiiight. OK, I'll add this check - should be simple enough if we just
> have interrupt handler set a flag when it sees AUX irq and have
> probing code sleep for a 1/4 of a second in 50 msec intervals to see
> if the flag was set. Don't want to use completion in main IRQ
> handler... Or do you think it is better to initially register
> i8042_aux_test_irq() that would signal completion and after successful
> testing for IRQ delivery free_irq/request_irq with normal handler?
> Tooo bad we don't have replace_irq...
 
I would go for the second option. Regarding the missing replace_irq(),
it's not a big deal for us - if the second request_irq() fails, we want
to bail out anyway.

-- 
Vojtech Pavlik
Director SuSE Labs
-
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/