Devicetree
 help / color / mirror / Atom feed
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 v11 1/6] mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
Date: Wed, 02 Sep 2026 13:02:15 +0000	[thread overview]
Message-ID: <20260902130216.55BC21F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260902-add-mcu-fan-khadas-vim4-v11-1-5f1610d83bf0@aliel.fr>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Parent MFD driver introduces child-specific private resources (fan configuration) via a platform data struct in a global MFD header, violating MFD separation and coupling principles.
--

commit 85d716a1f91fa9e8e2f48479df8c7b07e0cf0279
Author: Ronald Claveau <linux-kernel-dev@aliel.fr>

mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support

This commit introduces per-variant configuration structures for the KHADAS MCU
driver, adding support for VIM4 specific registers. It also introduces an enum
for variant matching and a fan platform data struct to pass fan configuration
to a 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 this struct introduce child-specific private configuration into the core
MFD driver?

By defining khadas_mcu_fan_pdata to pass thermal cooling state levels, it
appears the parent MFD driver will be forced to handle configurations specific
to a single sub-driver. The MFD subsystem principles indicate that the core
driver should only handle shared core resources, while child drivers should
manage their own private configurations.

Could this approach create tight coupling where any new fan variant requires
changes to the core MFD driver, rather than keeping those details contained
within the thermal driver?

> +
> +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/20260902-add-mcu-fan-khadas-vim4-v11-0-5f1610d83bf0@aliel.fr?part=1

  reply	other threads:[~2026-09-02 13:02 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 12:51 [PATCH v11 0/6] Add VIM4 MCU/FAN support Ronald Claveau via B4 Relay
2026-09-02 12:51 ` [PATCH v11 1/6] mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support Ronald Claveau via B4 Relay
2026-09-02 13:02   ` sashiko-bot [this message]
2026-09-02 12:51 ` [PATCH v11 2/6] mfd: khadas-mcu: Use MFD_CELL_* macros for cell declarations Ronald Claveau via B4 Relay
2026-09-02 12:58   ` sashiko-bot
2026-09-02 12:51 ` [PATCH v11 3/6] mfd: khadas-mcu: Add support for VIM4 MCU variant Ronald Claveau via B4 Relay
2026-09-02 13:04   ` sashiko-bot
2026-09-02 12:51 ` [PATCH v11 4/6] thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support Ronald Claveau via B4 Relay
2026-09-02 13:13   ` sashiko-bot
2026-09-02 12:51 ` [PATCH v11 5/6] arm64: dts: amlogic: t7: Add i2c controller node Ronald Claveau via B4 Relay
2026-09-02 13:05   ` sashiko-bot
2026-09-02 12:51 ` [PATCH v11 6/6] arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node Ronald Claveau via B4 Relay
2026-09-02 13:06   ` 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=20260902130216.55BC21F00A3A@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