lkml.org 
[lkml]   [2001]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: BUG: pc_keyb.c
>> Due to writing to the status register before it's ready as far as
>> I can see.

Which writes are you thinking of?

>> Fix: change all mdelay(1) in pc_keyb.c to mdelay(2)'s

There are four of them. Any one in particular?

(1) The first is

static void kb_wait(void) {
do {
status = handle_kbd_event();
if (! (status & KBD_STAT_IBF))
return;
mdelay(1);
} ...
}

Here handle_kbd_event() does kbd_read_status() which does
inb(KBD_STATUS_REG).
So, the mdelay(1) separates reads of the status register.

(2) The second is (in send_data, waiting for an ack):
for (;;) {
if (acknowledge)
return 1;
mdelay(1);
}
Here the delay seems completely arbitrary.

(3) The third is in kbd_wait_for_input():
do {
int retval = kbd_read_data();
if (retval >= 0)
return retval;
mdelay(1);
}
Here kbd_read_data() does kbd_read_status().
Again the mdelay(1) separates reads of the status register.

(4) The last is in detect_auxiliary_port() which is __init
and hence probably irrelevant.


If it is really necessary to have mdelay(1) or even mdelay(2),
then it seems to me that this implies that there is a minimum
delay between two reads of the status register.
But the present code does not guarantee such a delay at all.
For example, kbd_write_cmd() does
kb_wait();
outb(...);
kb_wait();
where the second kb_wait reads the status very quickly after the first.


So, I am inclined to think that the present mdelay(1) is just random
nonsense. It does not guarantee anything at all. If some delay is required
somewhere then we must introduce a mechanism that enforces the delay.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:57    [W:0.027 / U:1.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site