From: sashiko-bot@kernel.org
To: "Ronald Claveau" <linux-kernel-dev@aliel.fr>
Cc: devicetree@vger.kernel.org, neil.armstrong@linaro.org,
mfd@lists.linux.dev, linux-amlogic@lists.infradead.org,
lee@kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v10 1/6] mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
Date: Tue, 01 Sep 2026 15:36:14 +0000 [thread overview]
Message-ID: <20260901153614.9A1DC1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260901-add-mcu-fan-khadas-vim4-v10-1-aecdb9955a30@aliel.fr>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Introducing a bespoke platform data structure (`struct khadas_mcu_fan_pdata`) for parent-initialized private resources violates MFD decoupling guidelines.
--
commit 8a8b8fef22780db703282e4a267b644d5339157a
Author: Ronald Claveau <linux-kernel-dev@aliel.fr>
mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
This commit adds structures and registers to support per-variant configuration
for the Khadas MCU, specifically adding VIM4 support. It introduces an enum
for device matching and a custom platform data structure to pass fan
configuration from the parent to the sub-driver.
> diff --git a/include/linux/mfd/khadas-mcu.h b/include/linux/mfd/khadas-mcu.h
> index a99ba2ed0e4e0..7a9980ea63e7e 100644
> --- a/include/linux/mfd/khadas-mcu.h
> +++ b/include/linux/mfd/khadas-mcu.h
[ ... ]
> @@ -88,4 +95,21 @@ struct khadas_mcu {
> struct regmap *regmap;
> };
>
> +/**
> + * struct khadas_mcu_fan_pdata - fan sub-driver configuration
> + * @fan_reg: register address to write the fan level
> + * @levels: table mapping logical cooling-device states to raw fan levels
> + * @nlevels: number of entries in @levels
> + */
> +struct khadas_mcu_fan_pdata {
> + unsigned int fan_reg;
> + const unsigned int *levels;
> + unsigned int nlevels;
> +};
[Severity: Low]
Does introducing this bespoke platform data structure for parent-initialized
private resources violate MFD decoupling guidelines?
The parent MFD driver is forced to handle fan-specific configuration (like
register addresses and levels) rather than being limited to genuinely shared
core resources. This creates tight coupling with the child driver and
violates the requirement that private resources be initialized directly in
the child.
> +
> +enum khadas_mcu_type {
> + KHADAS_MCU_GENERIC = 1, /* VIM1/2/3, Edge, Edge-V */
> + KHADAS_MCU_VIM4,
> +};
> +
> #endif /* MFD_KHADAS_MCU_H */
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260901-add-mcu-fan-khadas-vim4-v10-0-aecdb9955a30@aliel.fr?part=1
next prev parent reply other threads:[~2026-09-01 15:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 15:25 [PATCH v10 0/6] Add VIM4 MCU/FAN support Ronald Claveau via B4 Relay
2026-09-01 15:25 ` [PATCH v10 1/6] mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support Ronald Claveau via B4 Relay
2026-09-01 15:36 ` sashiko-bot [this message]
2026-09-01 15:25 ` [PATCH v10 2/6] mfd: khadas-mcu: Use MFD_CELL_* macros for cell declarations Ronald Claveau via B4 Relay
2026-09-01 15:36 ` sashiko-bot
2026-09-01 15:25 ` [PATCH v10 3/6] mfd: khadas-mcu: Add support for VIM4 MCU variant Ronald Claveau via B4 Relay
2026-09-01 15:33 ` sashiko-bot
2026-09-01 15:25 ` [PATCH v10 4/6] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support Ronald Claveau via B4 Relay
2026-09-01 15:58 ` sashiko-bot
2026-09-01 15:25 ` [PATCH v10 5/6] arm64: dts: amlogic: t7: Add i2c controller node Ronald Claveau via B4 Relay
2026-09-01 15:34 ` sashiko-bot
2026-09-01 15:25 ` [PATCH v10 6/6] arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node Ronald Claveau via B4 Relay
2026-09-01 15:34 ` 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=20260901153614.9A1DC1F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox