From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Raul E Rangel <rrangel@chromium.org>
Cc: linux-input@vger.kernel.org, Shirish.S@amd.com,
Andy Shevchenko <andy@infradead.org>, Dan Murphy <dmurphy@ti.com>,
Darren Hart <dvhart@infradead.org>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
"Lee, Chun-Yi" <jlee@suse.com>, Pavel Machek <pavel@ucw.cz>,
Rajat Jain <rajatja@google.com>,
Stephen Boyd <swboyd@chromium.org>,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
platform-driver-x86@vger.kernel.org
Subject: Re: [PATCH v2 1/2] Input: i8042 - Prevent intermixing i8042 commands
Date: Sun, 6 Dec 2020 22:40:32 -0800 [thread overview]
Message-ID: <X83OYA0TaUszBD1y@google.com> (raw)
In-Reply-To: <20200827144112.v2.1.I6981f9a9f0c12e60f8038f3b574184f8ffc1b9b5@changeid>
Hi Raul,
On Thu, Aug 27, 2020 at 02:41:53PM -0600, Raul E Rangel wrote:
> The i8042_mutex must be held by writers of the AUX and KBD ports, as
> well as users of i8042_command. There were a lot of users of
> i8042_command that were not calling i8042_lock_chip/i8042_unlock_chip.
> This resulted in i8042_commands being issues in between PS/2
> transactions.
>
> This change moves the mutex lock into i8042_command and removes the
> burden of locking the mutex from the callers.
I think there is a benefit for allowing users issue a sequence of
commands to i8042 without interruptions, so I would prefer keeping
i8042_[un]lock_chip() in place.
Given that the issue you were observing was caused by i8042_port_close()
interfering with probing, maybe we could do something like this:
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index abae23af0791..aff871001eda 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -344,6 +344,8 @@ int i8042_command(unsigned char *param, int command)
unsigned long flags;
int retval;
+ lockdep_assert_held(&i8042_mutex);
+
if (!i8042_present)
return -1;
@@ -364,6 +366,8 @@ static int i8042_kbd_write(struct serio *port, unsigned char c)
unsigned long flags;
int retval = 0;
+ lockdep_assert_held(&i8042_mutex);
+
spin_lock_irqsave(&i8042_lock, flags);
if (!(retval = i8042_wait_write())) {
@@ -411,6 +415,8 @@ static void i8042_port_close(struct serio *serio)
port_name = "KBD";
}
+ i8042_lock_chip();
+
i8042_ctr &= ~irq_bit;
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
pr_warn("Can't write CTR while closing %s port\n", port_name);
@@ -422,6 +428,8 @@ static void i8042_port_close(struct serio *serio)
if (i8042_command(&i8042_ctr, I8042_CMD_CTL_WCTR))
pr_err("Can't reactivate %s port\n", port_name);
+ i8042_unlock_chip();
+
/*
* See if there is any data appeared while we were messing with
* port state.
Thanks.
--
Dmitry
prev parent reply other threads:[~2020-12-07 6:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-27 20:41 [PATCH v2 1/2] Input: i8042 - Prevent intermixing i8042 commands Raul E Rangel
2020-08-27 20:41 ` [PATCH v2 2/2] Input: i8042 - Lock i8042_mutex before flushing Raul E Rangel
2020-10-28 20:35 ` [PATCH v2 1/2] Input: i8042 - Prevent intermixing i8042 commands Hans de Goede
2020-12-07 6:40 ` Dmitry Torokhov [this message]
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=X83OYA0TaUszBD1y@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=Shirish.S@amd.com \
--cc=andy@infradead.org \
--cc=dmurphy@ti.com \
--cc=dvhart@infradead.org \
--cc=jacek.anaszewski@gmail.com \
--cc=jlee@suse.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rajatja@google.com \
--cc=rrangel@chromium.org \
--cc=swboyd@chromium.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.