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 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.