Re: [PATCH v9 04/12] mfd: zx297520v3: Add a clock and reset MFD driver

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Low] Direct cast from `const void *` to an `enum` triggers a `-Wpointer-to-int-cast` compiler warning on 64-bit architectures.
- [Low] The Kconfig symbol `MFD_ZTE_ZX297520V3_CRM` lacks an architecture-specific dependency, unconditionally exposing a highly SoC-specific driver to all architectures.
- [Low] The enum `zx297520v3_mfd_type` includes the string 'mfd', violating the MFD subsystem naming conventions.
--

--- Patch [4]: [PATCH v9 04/12] mfd: zx297520v3: Add a clock and reset MFD driver ---
commit 39c5ccee8d6ebff3fee809871f3a8191107ab75b
Author: Stefan Dösinger <[email protected]>

mfd: zx297520v3: Add a clock and reset MFD driver

This driver registers child devices for the zx297520v3 clock and reset
controllers. The clk-zx297520v3 and reset-zte-zx297520v3 submitted in
the next patches will drive the respective functionalities.

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 35f6e9b76d056..c0c7e83487f40 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
[ ... ]
> @@ -2572,5 +2572,16 @@ config MFD_MAX7360
>  	  additional drivers must be enabled in order to use the functionality
>  	  of the device.
>  
> +config MFD_ZTE_ZX297520V3_CRM
> +	tristate "ZTE zx297520v3 Clock and Reset Manager"
> +	select MFD_CORE
> +	default SOC_ZX297520V3

[Severity: Low]
Should this include an architecture dependency, such as
depends on ARCH_ZTE || COMPILE_TEST? Without it, this highly SoC-specific
driver will be presented in the configuration options for all architectures.

> +	help
> +	  Say yes here to enable the driver for the ZTE zx297520v3 clock and
> +	  reset manager MFD driver. This driver provides the host device for
> +	  the clock and reset drivers and is required to boot the SoC. You
> +	  will also need to enable CLK_ZTE_ZX297520V3 and RESET_ZTE_ZX297520V3
> +	  to build the actual clock and reset child drivers.
> +
>  endmenu
>  endif
> diff --git a/drivers/mfd/zte-zx297520v3-crm.c b/drivers/mfd/zte-zx297520v3-crm.c
> new file mode 100644
> index 0000000000000..37cd0c14680eb
> --- /dev/null
> +++ b/drivers/mfd/zte-zx297520v3-crm.c
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 Stefan Dösinger
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> +#include <linux/mfd/core.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset.h>
> +
> +enum zx297520v3_mfd_type {
> +	ZX297520V3_MFD_INVALID = 0,
> +	ZX297520V3_MFD_TOPCRM,
> +	ZX297520V3_MFD_MATRIXCRM,
> +	ZX297520V3_MFD_LSPCRM,
> +};

[Severity: Low]
This isn't a bug, but does including the string mfd in the enum name violate
the MFD subsystem naming conventions? The guidelines suggest avoiding
hard-coding implementation details like mfd in driver, struct, or device
names.

[ ... ]

> +static int zx297520v3_crm_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	enum zx297520v3_mfd_type type;
> +	const struct mfd_cell *cells;
> +	struct reset_control *rst;
> +	unsigned int num_cells;
> +	struct clk *pclk;
> +
> +	type = (enum zx297520v3_mfd_type)of_device_get_match_data(dev);

[Severity: Low]
Could this direct cast from a const void * pointer to an enum trigger a
-Wpointer-to-int-cast compiler warning on 64-bit architectures? Often an
intermediate cast to uintptr_t or kernel_ulong_t is used to safely preserve
the size before casting to the enum type.

> +	switch (type) {
> +	case ZX297520V3_MFD_TOPCRM:
> +		cells = zx297520v3_topcrm_cells;
> +		num_cells = ARRAY_SIZE(zx297520v3_topcrm_cells);
> +		break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4