[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061103081847.GC10906@suse.cz>
Date: Fri, 3 Nov 2006 09:18:47 +0100
From: Vojtech Pavlik <vojtech@...e.cz>
To: Dmitry Torokhov <dtor@...ightbb.com>
Cc: Dave Neuer <mr.fred.smoothie@...ox.com>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>
Subject: Re: [RFT/PATCH] i8042: remove polling timer (v6)
On Fri, Nov 03, 2006 at 12:56:02AM -0500, Dmitry Torokhov wrote:
> On Monday 30 October 2006 09:22, Dave Neuer wrote:
> > On 10/30/06, Dave Neuer <mr.fred.smoothie@...ox.com> wrote:
> > >
> > > Maybe I'm missing something, (well actually I'm sure I'm missing
> > > somethng). Looking at the code again, it's unclear to me why there is
> > > even a call to the ISR in i8042_aux_write, since the latter function
> > > already calls i8042_read_data.
> > >
> >
> > Whoops, sorry. I meant i8042_command, which is called by
> > i8042_aux_write before the call to i8042_interrupt, already calls
> > i8042_read_data.
> >
>
> It only calls i8042_read_data() if command is supposed to return data.
> Neither I8042_CMD_AUX_SEND nor I8042_CMD_MUX_SEND wait fotr data to come
> back.
>
> Anyway, I removed call to i8042_interrupt() from i8042_aux_write() because
> it is indeed unnecessary.
It was there because some older i8042's will report an error byte (=>
data) even though no device is connected, not just set error flags.
The unflushed byte in the FIFO then caused problems later on.
It may be that now it'll get disposed of correctly, I haven't looked at
the code for a while.
--
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/
Powered by blists - more mailing lists