From: Richard Hirst <rhirst@linuxcare.com>
To: Thomas Marteau <marteaut@esiee.fr>
Cc: "parisc-linux@parisc-linux.org" <parisc-linux@parisc-linux.org>
Subject: Re: [parisc-linux] The final patch for the keyboard problem
Date: Tue, 7 Aug 2001 11:58:17 +0100 [thread overview]
Message-ID: <20010807115817.A1011@linuxcare.com> (raw)
In-Reply-To: <3B6F986D.FA89E147@esiee.fr>; from marteaut@esiee.fr on Tue, Aug 07, 2001 at 09:27:41AM +0200
Hi Thimas,
On Tue, Aug 07, 2001 at 09:27:41AM +0200, Thomas Marteau wrote:
> +static int cmd_status;
Calling this awaiting_ack, and setting it true/false might make the code
more readable. Also I suspect it should be volatile really, as it is
modified via an interrupt handler.
> + cmd_status=2;
> + while (cmd_status!=0) {
> + write_output(KBD_CMD_SET_LEDS, lasikbd_hpa);
> + mdelay(1);
> + }
Nasty, as it will hang the kernel if the keyboard never ACKs. Should at
least limit the muber of times you loop here.
> + while ((read_status(hpa) & LASI_STAT_TBNE)==0x01);
Why not simply
while ((read_status(hpa) & LASI_STAT_TBNE))
;
> + do {
> + while ((read_status(hpa) & LASI_STAT_TBNE)==0x01);
> + gsc_writeb(0x00, hpa+LASI_XMTDATA);
> +
> + while ((read_status(hpa) & LASI_STAT_RBNE)==0x00);
> +
> + while ((read_status(hpa) & LASI_STAT_RBNE)==0x01) {
> + data=read_input(hpa);
> + fail++;
> + if(fail==10) break;
> + }
> + }while(data!=AUX_REPLY_ACK);
Do you really want the third 'while' loop in that block of code?
loop = 10;
do {
while ((read_status(hpa) & LASI_STAT_TBNE))
;
gsc_writeb(0x00, hpa+LASI_XMTDATA);
while (!(read_status(hpa) & LASI_STAT_RBNE))
;
data = read_input(hpa);
loop--;
} while (data != AUX_REPLY_ACK && loop);
One less while loop, but it can still hang in either of the first two while
loops if the h/w misbehaves.
> + /* allocate the irq and memory region for that device */
> + if (!(irq = busdevice_alloc_irq(d)))
> + return -ENODEV;
> +
> + if (request_irq(irq, lasikbd_interrupt, 0, name, hpa))
> + return -ENODEV;
> +
> + if (!request_mem_region((unsigned long)hpa, LASI_STATUS + 4, name))
> + return -ENODEV;
Typically a driver would release resources before exiting. e.g. if
request_mem_region() fails you should release_irq().
There are a couple of compiler warnings also.
Anyway, I'm about to try it on a couple of machines here; I'll let you
know how it goes.
Cheers,
Richard
next prev parent reply other threads:[~2001-08-07 10:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-07 7:27 [parisc-linux] The final patch for the keyboard problem Thomas Marteau
2001-08-07 10:58 ` Richard Hirst [this message]
2001-08-07 12:14 ` Richard Hirst
2001-08-07 21:36 ` Richard Hirst
2001-08-09 16:45 ` Grant Grundler
2001-08-07 23:31 ` Richard Hirst
2001-08-07 16:23 ` Matthew Wilcox
2001-08-10 17:23 ` Richard Hirst
2001-08-13 18:09 ` marteau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010807115817.A1011@linuxcare.com \
--to=rhirst@linuxcare.com \
--cc=marteaut@esiee.fr \
--cc=parisc-linux@parisc-linux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox