Re: [PATCH v2 09/14] reset: protect struct reset_controller_dev with its own mutex

[Philipp Zabel <p.zabel@pengutronix.de>]

On Mo, 2026-02-23 at 11:06 +0100, Bartosz Golaszewski wrote:
> Currently we use a single, global mutex - misleadingly names
> reset_list_mutex - to protect the global list of reset devices,
> per-controller list of reset control handles and also internal fields of
> struct reset_control. Locking can be made a lot more fine-grained if we
> use a separate mutex for serializing operations on the list AND
> accessing the reset controller device.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
>  drivers/reset/core.c             | 44 ++++++++++++++++++++++++----------------
>  include/linux/reset-controller.h |  3 +++
>  2 files changed, 30 insertions(+), 17 deletions(-)
> 
[...]
> diff --git a/include/linux/reset-controller.h b/include/linux/reset-controller.h
> index aa95b460fdf86f10002a465e285cd0119da6eeaf..2fecb4edeba1a2b1f5f5db2b34c867362c5f9c18 100644
> --- a/include/linux/reset-controller.h
> +++ b/include/linux/reset-controller.h
> @@ -3,6 +3,7 @@
>  #define _LINUX_RESET_CONTROLLER_H_
>  
>  #include <linux/list.h>
> +#include <linux/mutex.h>
>  
>  struct reset_controller_dev;
>  
> @@ -40,6 +41,7 @@ struct of_phandle_args;
>   *            device tree to id as given to the reset control ops, defaults
>   *            to :c:func:`of_reset_simple_xlate`.
>   * @nr_resets: number of reset controls in this reset controller device
> + * @lock: synchronizes concurrent access to the structure's fields

This is not true, or at least not very precise. The lock protects the
reset control list.

The contents of rcdev->list are protected by reset_list_mutex instead:
they are modified outside the rcdev->lock scope in
reset_controller_unregister().

The other fields in struct reset_controller_dev are expected to be
constant over its lifetime.

regards
Philipp