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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Missing `MODULE_ALIAS` for the platform drivers prevents module autoloading if the auxiliary device is not present.
- [Medium] The Kconfig entry `RESET_ZTE_ZX297520V3` fails to `select MFD_SYSCON` or `depends on MFD_SYSCON`.
- [Low] The driver is missing the `#include <linux/module.h>` header, leading to a build failure.
--

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

reset: zte: Add a zx297520v3 reset driver

This commit adds a reset driver for ZTE zx297520v3 SoCs. It registers two
platform drivers and one auxiliary driver to handle resets across different
hardware blocks.

> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index d009eb0849a3b..116dd23f1b8e3 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
[ ... ]
> @@ -404,6 +404,17 @@ 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 (ARCH_ZTE || COMPILE_TEST)
> +	default CLK_ZTE_ZX297520V3
> +	select AUXILIARY_BUS

[Severity: Medium]
Since this driver uses device_node_to_regmap() to acquire the parent syscon
regmap, should this config also select or depend on MFD_SYSCON? 

If MFD_SYSCON is disabled, device_node_to_regmap() acts as a stub returning
-ENOTSUPP, which will cause the reset driver to unconditionally fail to probe.

> +	help
> +	  This enables the reset controller for ZTE zx297520v3 SoCs. The reset
> +	  controller is part of the clock controller on this SoC. This driver
> +	  operates on an auxiliary device exposed by the clock driver. Enable
> +	  this driver if you plan to boot the kernel on a zx297520v3 based SoC.
> +
>  config RESET_ZYNQ
>  	bool "ZYNQ Reset Driver" if COMPILE_TEST
>  	default ARCH_ZYNQ

> diff --git a/drivers/reset/reset-zte-zx297520v3.c b/drivers/reset/reset-zte-zx297520v3.c
> new file mode 100644
> index 0000000000000..8ef4349042308
> --- /dev/null
> +++ b/drivers/reset/reset-zte-zx297520v3.c
[ ... ]
> +static struct platform_driver * const reset_zx297520v3_mfddrv[] = {
> +	&reset_zx297520v3_top,
> +	&reset_zx297520v3_matrix,
> +};

[Severity: Medium]
Since these platform drivers do not have an .of_match_table and match purely by
name, do they need explicit MODULE_ALIAS declarations (such as
MODULE_ALIAS("platform:zx297520v3-toprst")) for proper udev module autoloading?

Without these aliases, the module might only autoload when the auxiliary device
appears, creating a dependency on the LSP clock driver being loaded first.

[ ... ]
> +static void __exit reset_zx297520v3_exit(void)
> +{
> +	platform_unregister_drivers(reset_zx297520v3_mfddrv,
> +				    ARRAY_SIZE(reset_zx297520v3_mfddrv));
> +	auxiliary_driver_unregister(&reset_zx297520v3_auxdrv);
> +}
> +
> +module_init(reset_zx297520v3_init);
> +module_exit(reset_zx297520v3_exit);

[Severity: Low]
Does this file need to include <linux/module.h>? 

Without it, building this as a loadable module could fail because macros like
module_init, module_exit, MODULE_AUTHOR, and MODULE_DESCRIPTION are not
provided by the other included headers.

> +
> +MODULE_AUTHOR("Stefan Dösinger <stefandoesinger@gmail.com>");
> +MODULE_DESCRIPTION("ZTE zx297520v3 reset driver");
> +MODULE_LICENSE("GPL");

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260628-zx29clk-v5-0-79ff044e4192@gmail.com?part=11