From: Steven Rostedt <srostedt@redhat.com>
To: Markus Armbruster <armbru@pond.sub.org>
Cc: linux-kernel@vger.kernel.org, Dmitry Torokhov <dtor@mail.ru>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] input: Fix interrupt enable in i8042_ctr when enabling interrupt fails
Date: Tue, 31 Jul 2007 08:56:22 -0400 [thread overview]
Message-ID: <46AF3176.6080106@redhat.com> (raw)
In-Reply-To: <87fy3sxvit.fsf@pike.pond.sub.org>
Markus Armbruster wrote:
> When enabling interrupts fails, the interrupt enable bit remains set
> in i8042_ctr. Later writes of i8042_ctr to the hardware could
> accidentally retry enabling interrupts. Clear the bit on failure.
>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
This patch is more of a "make it right" than a fix, since the problem is
highly unlikely to happen (but perhaps not so unlikely on virtual machines).
Acked-by: Steven Rostedt <rostedt@goodmis.org>
>
> ---
>
> Some time ago Steven Rostedt and I went over this changeset:
>
> commit de9ce703c6b807b1dfef5942df4f2fadd0fdb67a
> Author: Dmitry Torokhov <dtor@insightbb.com>
> Date: Sun Sep 10 21:57:21 2006 -0400
>
> Input: i8042 - get rid of polling timer
>
> Remove polling timer that was used to detect keybord/mice hotplug and
> register both IRQs right away instead of waiting for a driver to
> attach to a port.
>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
>
> Steven pointed out to me that it changes behavior when enabling IRQ
> fails.
>
> The old code enabled IRQs this way:
>
> i8042_ctr |= port->irqen;
>
> if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
> i8042_ctr &= ~port->irqen;
> return -1;
> }
>
> i8042_ctr shadows the 8042's CTR. So, when enabling fails, the bit is
> cleared in the shadow.
>
> The new code does not clear the bit on the error path:
>
> static int i8042_enable_kbd_port(void)
> {
> i8042_ctr &= ~I8042_CTR_KBDDIS;
> i8042_ctr |= I8042_CTR_KBDINT;
>
> if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
> printk(KERN_ERR "i8042.c: Failed to enable KBD port.\n");
> return -EIO;
> }
>
> return 0;
> }
>
> Same for i8042_enable_aux_port().
>
> This leads to the question whether there are later writes of i8042_ctr
> (possibly with other bits altered) to the hardware, which could
> accidentally retry enabling interrupts.
>
> I believe this possible, but unlikely. Scenarios involve enable
> succeeding the first time, failing the second time, and succeeding the
> third time. I can provide details, but the point I'd like to make is
> not that this is broken (although it is, strictly speaking), but that
> it is not obviously correct where it easily could be: just clear the
> interrupt enable bits when writing them to the hardware failed, like
> the old code did.
>
> diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
> index db9cca3..71a7e39 100644
> --- a/drivers/input/serio/i8042.c
> +++ b/drivers/input/serio/i8042.c
> @@ -385,6 +385,7 @@ static int i8042_enable_kbd_port(void)
> i8042_ctr |= I8042_CTR_KBDINT;
>
> if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
> + i8042_ctr &= ~I8042_CTR_KBDINT;
> printk(KERN_ERR "i8042.c: Failed to enable KBD port.\n");
> return -EIO;
> }
> @@ -402,6 +403,7 @@ static int i8042_enable_aux_port(void)
> i8042_ctr |= I8042_CTR_AUXINT;
>
> if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR)) {
> + i8042_ctr &= ~I8042_CTR_AUXINT;
> printk(KERN_ERR "i8042.c: Failed to enable AUX port.\n");
> return -EIO;
> }
next prev parent reply other threads:[~2007-07-31 12:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-13 13:50 [PATCH] input: Fix interrupt enable in i8042_ctr when enabling interrupt fails Markus Armbruster
2007-07-31 12:56 ` Steven Rostedt [this message]
-- strict thread matches above, loose matches on Subject: below --
2007-08-09 8:34 Markus Armbruster
2007-09-10 12:41 Markus Armbruster
2007-09-10 12:59 ` Steven Rostedt
2007-09-10 13:14 ` Dmitry Torokhov
2007-09-10 13:14 ` Dmitry Torokhov
2007-09-10 12:59 ` Steven Rostedt
2007-09-10 12:41 Markus Armbruster
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=46AF3176.6080106@redhat.com \
--to=srostedt@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=armbru@pond.sub.org \
--cc=dtor@mail.ru \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.