From: sashiko-bot@kernel.org
To: "Alexey Charkov" <alchark@flipper.net>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH 1/4] nvmem: rockchip-otp: Serialize reads
Date: Tue, 01 Sep 2026 15:39:40 +0000 [thread overview]
Message-ID: <20260901153940.C6DE01F01558@smtp.kernel.org> (raw)
In-Reply-To: <20260901-rk3576-otp-cpuid-mac-v1-1-ea9135270fc2@flipper.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Mixing goto-based error handling with scope-based guard() cleanup in the same function.
--
commit 279787a491898a378d6e600f26ecd6fbd75f2d26
Author: Alexey Charkov <alchark@flipper.net>
nvmem: rockchip-otp: Serialize reads
The OTP controller is driven through a single set of registers holding a
state machine which has to be stepped through for every word read, yet
nothing keeps two readers out of each other's way. Concurrent reads
interleave, and the outcome is either a reader bailing out or, worse, one
of them silently taking delivery of the other's data.
Guard the read path with a mutex.
> diff --git a/drivers/nvmem/rockchip-otp.c b/drivers/nvmem/rockchip-otp.c
> index 2c0feb036f3fd..b034b7455016a 100644
> --- a/drivers/nvmem/rockchip-otp.c
> +++ b/drivers/nvmem/rockchip-otp.c
[ ... ]
> @@ -272,6 +275,8 @@ static int rockchip_otp_read(void *context, unsigned int offset,
> if (!otp->data || !otp->data->reg_read)
> return -EINVAL;
>
> + guard(mutex)(&otp->mutex);
> +
[Severity: Medium]
Does adding this guard() mix scope-based cleanup with the goto-based
error handling further down in rockchip_otp_read()?
The kernel cleanup guidelines in include/linux/cleanup.h state that usage
of goto and cleanup helpers should never be mixed in the same function.
Since rockchip_otp_read() still contains a goto err path:
buf = kzalloc(array_size(count, word_size), GFP_KERNEL);
if (!buf) {
ret = -ENOMEM;
goto err;
}
and a manual cleanup label:
err:
clk_bulk_disable_unprepare(otp->data->num_clks, otp->clks);
could the clock cleanup be converted to use scope-based cleanup as well,
or should a plain mutex_lock and mutex_unlock be used instead of guard()
to avoid mixing cleanup styles?
> ret = clk_bulk_prepare_enable(otp->data->num_clks, otp->clks);
> if (ret < 0) {
> dev_err(otp->dev, "failed to prepare/enable clks\n");
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-rk3576-otp-cpuid-mac-v1-0-ea9135270fc2@flipper.net?part=1
next prev parent reply other threads:[~2026-09-01 15:39 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 15:33 [PATCH 0/4] nvmem: Derive Rockchip MAC addresses from the OTP CPU ID Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
2026-09-01 15:33 ` [PATCH 1/4] nvmem: rockchip-otp: Serialize reads Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
2026-09-01 15:39 ` sashiko-bot [this message]
2026-09-02 9:10 ` Miquel Raynal
2026-09-02 9:10 ` Miquel Raynal
2026-09-02 9:24 ` Alexey Charkov
2026-09-02 9:24 ` Alexey Charkov
2026-09-02 10:17 ` Miquel Raynal
2026-09-02 10:17 ` Miquel Raynal
2026-09-02 12:40 ` Alexey Charkov
2026-09-02 12:40 ` Alexey Charkov
2026-09-03 8:06 ` Miquel Raynal
2026-09-03 8:06 ` Miquel Raynal
2026-09-01 15:33 ` [PATCH 2/4] dt-bindings: nvmem: layouts: Add Rockchip OTP CPUID layout Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
2026-09-01 15:33 ` [PATCH 3/4] nvmem: layouts: Add Rockchip OTP CPUID layout driver Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
2026-09-01 16:03 ` sashiko-bot
2026-09-02 9:40 ` Miquel Raynal
2026-09-02 9:40 ` Miquel Raynal
2026-09-01 15:33 ` [PATCH 4/4] arm64: dts: rockchip: Derive GMAC MAC addresses from OTP on RK3576 Alexey Charkov
2026-09-01 15:33 ` Alexey Charkov
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=20260901153940.C6DE01F01558@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alchark@flipper.net \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--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.