From: sashiko-bot@kernel.org
To: "Ronald Claveau" <linux-kernel-dev@aliel.fr>
Cc: neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org,
devicetree@vger.kernel.org, mfd@lists.linux.dev, robh@kernel.org,
lee@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v12 3/6] mfd: khadas-mcu: Add support for VIM4 MCU variant
Date: Thu, 17 Sep 2026 08:11:18 +0000 [thread overview]
Message-ID: <20260917081118.835FA1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260917-add-mcu-fan-khadas-vim4-v12-3-497cd543a148@aliel.fr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] mfd: Incorrect writeable registers in VIM4 regmap config
--
commit fc44329d7ee6d12a0077930b2632df3554d1e38f
Author: Ronald Claveau <linux-kernel-dev@aliel.fr>
mfd: khadas-mcu: Add support for VIM4 MCU variant
This commit adds support for the VIM4 MCU variant by refactoring the
probe function to use per-variant values. It introduces a dedicated
regmap configuration for the VIM4 MCU, with its own volatile and
writeable register checks.
> diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
> index 0e74efe14f367..4b37e74e2b04a 100644
> --- a/drivers/mfd/khadas-mcu.c
> +++ b/drivers/mfd/khadas-mcu.c
[ ... ]
> +static bool khadas_mcu_vim4_reg_writeable(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case KHADAS_MCU_VERSION_0_REG:
> + case KHADAS_MCU_VERSION_1_REG:
> + case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
> + return false;
> + default:
> + return true;
[Severity: Low]
Does this function omit multiple known read-only registers defined for the MCU,
such as KHADAS_MCU_MAC_0_REG and KHADAS_MCU_USID_0_REG?
Because this switch defaults to true, any unlisted read-only register is
incorrectly marked as writeable. Because the regmap uses REGCACHE_MAPLE,
writing to an omitted read-only register will inappropriately cache the written
value instead of failing, which could poison the cache for subsequent reads.
Even though the khadas-mcu-user-mem cell isn't instantiated for the VIM4 variant
(meaning there is no active code path writing to these registers in normal
production operation), should these known read-only registers be explicitly
handled to prevent future caching issues?
> + }
> +}
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260917-add-mcu-fan-khadas-vim4-v12-0-497cd543a148@aliel.fr?part=3
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: "Ronald Claveau" <linux-kernel-dev@aliel.fr>
Cc: neil.armstrong@linaro.org, linux-amlogic@lists.infradead.org,
devicetree@vger.kernel.org, mfd@lists.linux.dev, robh@kernel.org,
lee@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v12 3/6] mfd: khadas-mcu: Add support for VIM4 MCU variant
Date: Thu, 17 Sep 2026 08:11:18 +0000 [thread overview]
Message-ID: <20260917081118.835FA1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260917-add-mcu-fan-khadas-vim4-v12-3-497cd543a148@aliel.fr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] mfd: Incorrect writeable registers in VIM4 regmap config
--
commit fc44329d7ee6d12a0077930b2632df3554d1e38f
Author: Ronald Claveau <linux-kernel-dev@aliel.fr>
mfd: khadas-mcu: Add support for VIM4 MCU variant
This commit adds support for the VIM4 MCU variant by refactoring the
probe function to use per-variant values. It introduces a dedicated
regmap configuration for the VIM4 MCU, with its own volatile and
writeable register checks.
> diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
> index 0e74efe14f367..4b37e74e2b04a 100644
> --- a/drivers/mfd/khadas-mcu.c
> +++ b/drivers/mfd/khadas-mcu.c
[ ... ]
> +static bool khadas_mcu_vim4_reg_writeable(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case KHADAS_MCU_VERSION_0_REG:
> + case KHADAS_MCU_VERSION_1_REG:
> + case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
> + return false;
> + default:
> + return true;
[Severity: Low]
Does this function omit multiple known read-only registers defined for the MCU,
such as KHADAS_MCU_MAC_0_REG and KHADAS_MCU_USID_0_REG?
Because this switch defaults to true, any unlisted read-only register is
incorrectly marked as writeable. Because the regmap uses REGCACHE_MAPLE,
writing to an omitted read-only register will inappropriately cache the written
value instead of failing, which could poison the cache for subsequent reads.
Even though the khadas-mcu-user-mem cell isn't instantiated for the VIM4 variant
(meaning there is no active code path writing to these registers in normal
production operation), should these known read-only registers be explicitly
handled to prevent future caching issues?
> + }
> +}
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260917-add-mcu-fan-khadas-vim4-v12-0-497cd543a148@aliel.fr?part=3
next prev parent reply other threads:[~2026-09-17 8:11 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-17 7:58 [PATCH v12 0/6] Add VIM4 MCU/FAN support Ronald Claveau
2026-09-17 7:58 ` Ronald Claveau via B4 Relay
2026-09-17 7:58 ` Ronald Claveau via B4 Relay
2026-09-17 7:59 ` [PATCH v12 1/6] mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support Ronald Claveau
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 8:06 ` sashiko-bot
2026-09-17 8:06 ` sashiko-bot
2026-09-17 7:59 ` [PATCH v12 2/6] mfd: khadas-mcu: Use MFD_CELL_* macros for cell declarations Ronald Claveau
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 8:07 ` sashiko-bot
2026-09-17 8:07 ` sashiko-bot
2026-09-18 9:05 ` Neil Armstrong
2026-09-18 9:05 ` Neil Armstrong
2026-09-17 7:59 ` [PATCH v12 3/6] mfd: khadas-mcu: Add support for VIM4 MCU variant Ronald Claveau
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 8:11 ` sashiko-bot [this message]
2026-09-17 8:11 ` sashiko-bot
2026-09-18 8:46 ` Ronald Claveau
2026-09-18 8:46 ` Ronald Claveau
2026-09-17 7:59 ` [PATCH v12 4/6] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support Ronald Claveau
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 8:13 ` sashiko-bot
2026-09-17 8:13 ` sashiko-bot
2026-09-18 8:54 ` Ronald Claveau
2026-09-18 8:54 ` Ronald Claveau
2026-09-18 9:12 ` Daniel Lezcano
2026-09-18 9:12 ` Daniel Lezcano
2026-09-17 7:59 ` [PATCH v12 5/6] arm64: dts: amlogic: t7: Add i2c controller node Ronald Claveau
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 8:03 ` sashiko-bot
2026-09-17 8:03 ` sashiko-bot
2026-09-17 7:59 ` [PATCH v12 6/6] arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node Ronald Claveau
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 7:59 ` Ronald Claveau via B4 Relay
2026-09-17 8:08 ` sashiko-bot
2026-09-17 8:08 ` sashiko-bot
2026-09-23 11:13 ` (subset) [PATCH v12 0/6] Add VIM4 MCU/FAN support Lee Jones
2026-09-23 11:13 ` Lee Jones
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=20260917081118.835FA1F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee@kernel.org \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-kernel-dev@aliel.fr \
--cc=mfd@lists.linux.dev \
--cc=neil.armstrong@linaro.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.