Re: [PATCH v22 03/13] power: reset: reboot-mode: Add support for predefined reboot modes

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Memory allocated by reboot_mode_add_predefined_modes() leaks if driver probe fails before registration.
--

commit ee3620bd44dbaeea7086626f9b3f70bbf53b0350
Author: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>

power: reset: reboot-mode: Add support for predefined reboot modes

This commit extends the reboot-mode framework to handle predefined modes
alongside those defined in the device tree. Drivers can now define and
register their own reboot-modes via the framework using a centralized
initialization call.

> diff --git a/drivers/power/reset/reboot-mode.c b/drivers/power/reset/reboot-mode.c
> --- a/drivers/power/reset/reboot-mode.c
> +++ b/drivers/power/reset/reboot-mode.c
[ ... ]
> @@ -344,6 +375,55 @@ void devm_reboot_mode_unregister(struct device *dev,
>  }
>  EXPORT_SYMBOL_GPL(devm_reboot_mode_unregister);
>  
> +/**
> + * reboot_mode_add_predefined_modes - Add predefined reboot modes
> + * @reboot: reboot mode driver
> + * @modes: array of predefined reboot mode entries
> + * @count: number of entries in @modes
> + *
> + * Add predefined reboot modes in a single call before registration.
[ ... ]
> +int reboot_mode_add_predefined_modes(struct reboot_mode_driver *reboot,
> +				     const struct reboot_mode_entry *modes,
> +				     size_t count)
> +{
> +	struct mode_info *info;
> +	int ret;
> +	size_t i;
> +
> +	if (reboot->reboot_notifier.notifier_call == reboot_mode_notify ||
> +	    !list_empty(&reboot->predefined_modes))
> +		return -EBUSY;
> +
> +	if (!modes || !count)
> +		return -EINVAL;
> +
> +	for (i = 0; i < count; i++) {
> +		info = reboot_mode_create_info(modes[i].name, modes[i].magic);
> +		if (IS_ERR(info)) {
> +			ret = PTR_ERR(info);
> +			goto error;
> +		}
> +
> +		list_add_tail(&info->list, &reboot->predefined_modes);
> +	}
> +
> +	return 0;
> +
> +error:
> +	reboot_mode_release_list(&reboot->predefined_modes);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(reboot_mode_add_predefined_modes);

If a driver successfully calls reboot_mode_add_predefined_modes(), but the
probe function fails before reboot_mode_register() is called, does this code
leak the dynamically allocated mode_info structures?

For example, if devm_reboot_mode_register() internally fails at
devres_alloc() and returns -ENOMEM before calling reboot_mode_register(),
the framework will not be registered. Since devres will later free the
reboot_mode_driver itself, the dynamically allocated list elements added to
predefined_modes appear to be permanently orphaned.

Would it be possible to provide an exported cleanup function for error
handling, or perhaps manage these allocations using devres?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260514-arm-psci-system_reset2-vendor-reboots-v22-0-28a5bde07483@oss.qualcomm.com?part=3