Re: [PATCH v6 11/12] reset: zte: Add a zx297520v3 reset driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The driver registers a platform_driver with an `id_table` but fails to declare the `MODULE_DEVICE_TABLE` macro, breaking automatic module loading.
- [Medium] The Kconfig entry for RESET_ZTE_ZX297520V3 does not select MFD_SYSCON, leading to silent probe failures when syscon is disabled.
--

commit a55000e5fe1a8cfd1c7dc0bc7830d18e5a7d4876
Author: Stefan Dösinger <stefandoesinger@gmail.com>

reset: zte: Add a zx297520v3 reset driver

This drives the MFD child devices created by the zx297520v3-crm driver
as well as the aux device created by the zx297520v3-lspclk driver.

> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index d009eb0849a3b..4dca1f89d22b5 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -404,6 +404,16 @@ config RESET_UNIPHIER_GLUE
>  	  on UniPhier SoCs. Say Y if you want to control reset signals
>  	  provided by the glue layer.
>  
> +config RESET_ZTE_ZX297520V3
> +	tristate "ZTE zx297520v3 Reset Driver"
> +	depends on ZTE_ZX297520V3_CRM || COMPILE_TEST

[Severity: Medium]
Will this cause silent probe failures if CONFIG_MFD_SYSCON is disabled?

When syscon is not enabled, device_node_to_regmap() is stubbed out to return
ERR_PTR(-ENOTSUPP). This means the driver probe will abort when it tries
to acquire the parent syscon regmap in reset_zx297520v3_probe(). 

Should this Kconfig entry use select MFD_SYSCON or depends on MFD_SYSCON to
guarantee the syscon APIs are available?

> +	default SOC_ZX297520V3
> +	help
> +	  This enables the reset controllers for ZTE zx297520v3 SoCs. The reset
> +	  controllers are part of the clock and reset management controllers on

[ ... ]

> diff --git a/drivers/reset/reset-zte-zx297520v3.c b/drivers/reset/reset-zte-zx297520v3.c
> new file mode 100644
> index 0000000000000..75a9e6e93cdac
> --- /dev/null
> +++ b/drivers/reset/reset-zte-zx297520v3.c

[ ... ]

> +static const struct platform_device_id reset_zx297520v3_ids[] = {
> +	{
> +		.name = "zx297520v3-topreset",
> +		.driver_data = (kernel_ulong_t)&zx297520v3_topreset_data,
> +	},
> +	{
> +		.name = "zx297520v3-matrixreset",
> +		.driver_data = (kernel_ulong_t)&zx297520v3_matrixreset_data,
> +	},
> +	{
> +		.name = "zx297520v3-lspreset",
> +		.driver_data = (kernel_ulong_t)&zx297520v3_lspreset_data,
> +	},
> +	{ }
> +};

[Severity: Medium]
Is a MODULE_DEVICE_TABLE declaration needed for this platform device ID table?

Without exporting the table, the driver might fail to load automatically when
built as a module. When the parent MFD core creates the child platform devices
(such as zx297520v3-topreset), udev relies on the modules.alias file to match
the MODALIAS uevent property.

> +
> +static struct platform_driver reset_zx297520v3 = {
> +	.probe = reset_zx297520v3_probe,
> +	.driver = {
> +		.name = "reset-zx297520v3",
> +	},
> +	.id_table = reset_zx297520v3_ids,
> +};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-zx29clk-v6-0-377b704f80c4@gmail.com?part=11