From: sashiko-bot@kernel.org
To: "Sasha Finkelstein" <k@chaosmail.tech>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v6 3/6] spmi: apple: check transaction status
Date: Sun, 16 Aug 2026 10:37:07 +0000 [thread overview]
Message-ID: <20260816103708.1A9F61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260816-t603x-spmi-v6-3-c5ab87aa447b@chaosmail.tech>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing concurrency protection for shared hardware controller registers.
--
--- Patch [3]: [PATCH v6 3/6] spmi: apple: check transaction status ---
commit 7a35e38337e2fbd8de6bb123e810dc5312c6e28b
Author: Alba Mendez <me@alba.sh>
spmi: apple: check transaction status
Check for parity errors and missing command ACKs.
> diff --git a/drivers/spmi/spmi-apple-controller.c b/drivers/spmi/spmi-apple-controller.c
> index 15721cb41d5c8..b1c127cf5f441 100644
> --- a/drivers/spmi/spmi-apple-controller.c
> +++ b/drivers/spmi/spmi-apple-controller.c
[ ... ]
> @@ -66,7 +74,7 @@ static int spmi_read_cmd(struct spmi_controller *ctrl, u8 opc, u8 sid,
> {
> struct apple_spmi *spmi = spmi_controller_get_drvdata(ctrl);
> u32 spmi_cmd = apple_spmi_pack_cmd(opc, sid, saddr, len);
> - u32 rsp;
> + u32 reply, rsp;
> size_t len_read = 0;
> u8 i;
> int ret;
[Severity: High]
This isn't a bug introduced by this patch, but is it possible for multiple
kernel threads to execute spmi_read_cmd() or spmi_write_cmd() concurrently
without locking?
If different threads communicate with multiple PMIC endpoints on the same SPMI
bus, it appears concurrent operations might invoke these functions
simultaneously. The core SPMI subsystem does not serialize transactions across
different slaves.
In both functions, the driver writes to SPMI_CMD_REG and then enters a polling
wait without holding any locks. For example, in spmi_read_cmd():
writel(spmi_cmd, spmi->regs + SPMI_CMD_REG);
ret = apple_spmi_wait_rx_not_empty(ctrl);
Could this unprotected wait window allow interleaved accesses to corrupt the
shared command, status, and response registers? Is a mutex or spinlock
required here to protect the active transaction state from concurrent PMIC
transactions?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260816-t603x-spmi-v6-0-c5ab87aa447b@chaosmail.tech?part=3
next prev parent reply other threads:[~2026-08-16 10:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 10:26 [PATCH v6 0/6] spmi: apple: Additional commands and interrupt support Sasha Finkelstein
2026-08-16 10:26 ` [PATCH v6 1/6] dt-bindings: spmi: apple,spmi: Add t603x and t8122 Sasha Finkelstein
2026-08-16 10:30 ` sashiko-bot
2026-08-16 10:26 ` [PATCH v6 2/6] spmi: apple: Validate FIFO state Sasha Finkelstein
2026-08-16 10:37 ` sashiko-bot
2026-08-16 10:26 ` [PATCH v6 3/6] spmi: apple: check transaction status Sasha Finkelstein
2026-08-16 10:37 ` sashiko-bot [this message]
2026-08-16 10:26 ` [PATCH v6 4/6] spmi: apple: Implement remaining commands Sasha Finkelstein
2026-08-16 10:36 ` sashiko-bot
2026-08-16 10:26 ` [PATCH v6 5/6] spmi: apple: lock around FIFOs Sasha Finkelstein
2026-08-16 10:26 ` [PATCH v6 6/6] spmi: apple: Add interrupt functionality Sasha Finkelstein
2026-08-16 10:38 ` sashiko-bot
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=20260816103708.1A9F61F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=k@chaosmail.tech \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.