Re: [PATCH v3 07/12] reset: Add reset_control_get_from_provider_exclusive()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The dummy stub for `reset_control_get_from_provider_exclusive()` incorrectly returns `NULL` instead of `ERR_PTR(-ENOTSUPP)` when `CONFIG_RESET_CONTROLLER` is disabled.
--

commit b2e455f4dc1ad499526bd8cbd50a8edaddca9cff
Author: Geert Uytterhoeven <geert+renesas@glider.be>

reset: Add reset_control_get_from_provider_exclusive()

This commit adds a public helper reset_control_get_from_provider_exclusive()
to lookup and obtain an exclusive reference to a reset controller. The
implementation is based on the recently introduced
__reset_control_get_from_provider() helper.

> diff --git a/include/linux/reset.h b/include/linux/reset.h
> index 9c391cf0c8229..09ee47b27f88d 100644
> --- a/include/linux/reset.h
> +++ b/include/linux/reset.h
[ ... ]
> @@ -173,6 +175,12 @@ static inline struct reset_control *__reset_control_get(
>  	return optional ? NULL : ERR_PTR(-ENOTSUPP);
>  }
>  
> +static inline struct reset_control *reset_control_get_from_provider_exclusive(
> +				const struct fwnode_reference_args *args)
> +{
> +	return NULL;
> +}
> +

[Severity: Medium]
When CONFIG_RESET_CONTROLLER is disabled, should this stub return
ERR_PTR(-ENOTSUPP) instead of NULL?

In the reset framework, a NULL reset control is treated as a valid but
optional no-op. If a driver calls reset_control_get_from_provider_exclusive()
during probing on a kernel compiled without the reset framework, and the stub
returns NULL, IS_ERR() will evaluate to false. 

This would mislead the caller into believing it successfully acquired the
mandatory exclusive reset control. The driver would skip error handling and
proceed without actually performing the required hardware resets, potentially
causing hardware malfunctions.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1788338320.git.geert+renesas@glider.be?part=7