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: <d120d5000607280720u3db9b7dmb7f05cb7e9424934@mail.gmail.com>
Date:	Fri, 28 Jul 2006 10:20:00 -0400
From:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>
To:	"Vojtech Pavlik" <vojtech@...e.cz>
Cc:	linux-kernel@...r.kernel.org, "Dave Jones" <davej@...hat.com>
Subject: Re: [RFC/RFT] Remove polling timer from i8042

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...

-- 
Dmitry
-
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/