From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Patryk Duda <patrykd@google.com>
Cc: Guenter Roeck <groeck@chromium.org>,
Benson Leung <bleung@chromium.org>,
chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] platform/chrome: cros_ec_proto: Lock device when updating MKBP version
Date: Mon, 29 Jul 2024 03:47:42 +0000 [thread overview]
Message-ID: <ZqcQ3rjY6Wu4lU6t@google.com> (raw)
In-Reply-To: <20240725175714.1769080-1-patrykd@google.com>
On Thu, Jul 25, 2024 at 05:57:13PM +0000, Patryk Duda wrote:
> The cros_ec_get_host_command_version_mask() function requires that the
> caller must have ec_dev->lock mutex before calling it. This requirement
> was not met and as a result it was possible that two commands were sent
> to the device at the same time.
To clarify:
- What would happen if multiple cros_ec_get_host_command_version_mask() calls
at the same time?
- What are the callees? I'm trying to understand the source of parallelism.
Also, the patch also needs an unlock at [1].
[1]: https://elixir.bootlin.com/linux/v6.10/source/drivers/platform/chrome/cros_ec_proto.c#L819
> The problem was observed while using UART backend which doesn't use any
> additional locks, unlike SPI backend which locks the controller until
> response is received.
Is it a general issue if multiple commands send to EC at a time? If yes, it
should serialize that in the UART transportation.
next prev parent reply other threads:[~2024-07-29 3:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-25 17:57 [PATCH] platform/chrome: cros_ec_proto: Lock device when updating MKBP version Patryk Duda
2024-07-29 3:47 ` Tzung-Bi Shih [this message]
2024-07-29 11:57 ` Patryk Duda
2024-07-30 6:04 ` Tzung-Bi Shih
2024-07-30 8:05 ` Patryk Duda
2024-07-30 10:14 ` Tzung-Bi Shih
2024-07-30 10:55 ` Patryk Duda
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=ZqcQ3rjY6Wu4lU6t@google.com \
--to=tzungbi@kernel.org \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=groeck@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patrykd@google.com \
/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