linux.git/drivers/reset/core.c, branch v7.1-rc2

reset: core: Drop unnecessary double quote

2026-03-27T12:44:49+00:00

Drop unnecessary double quote.

Reported-by: Pavel Machek 
Closes: https://lore.kernel.org/all/acJbYxKGAB4lxGQr@duo.ucw.cz
Signed-off-by: Claudiu Beznea 
Reviewed-by: Philipp Zabel 
Signed-off-by: Philipp Zabel

reset: don't overwrite fwnode_reset_n_cells

2026-03-11T07:27:21+00:00

Fix a logic bug in reset_controller_register() where we set
fwnode_reset_n_cells to 1 if fwnode is set and fwnode_xlate is not but
we do it after assigning of_fwnode_handle(of_node) to fwnode.

Modify the logic to: assign fwnode from of_node if applicable, if fwnode
is still not set, try to get it from the device and only then check
of_xlate and fwnode_xlate and either assign fwnode_reset_n_cells from OF
or default to fwnode_reset_simple_xlate and fwnode_reset_n_cells = 1.

Fixes: ba8dbbb14b7e ("reset: convert the core API to using firmware nodes")
Reported-by: Mark Brown 
Closes: https://lore.kernel.org/all/0b72286b-33dd-4bc9-8c0e-161c2f4baed8@sirena.org.uk/
Signed-off-by: Bartosz Golaszewski 
Tested-by: Mark Brown 
Reviewed-by: Philipp Zabel 
Signed-off-by: Philipp Zabel

reset: core: Fix indentation

2026-03-10T09:05:49+00:00

Correct an accidental whitespace change.

Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202603100730.J3pi4xqi-lkp@intel.com/
Fixes: 9035073d0ef1 ("reset: convert reset core to using firmware nodes")
Signed-off-by: Philipp Zabel

reset: convert reset core to using firmware nodes

2026-03-09T09:20:04+00:00

With everything else now in place, we can convert the remaining parts of
the reset subsystem to becoming fwnode-agnostic - meaning it will work
with all kinds of firmware nodes, not only devicetree.

To that end: extend struct reset_controller_dev with fields taking
information relevant for using firmware nodes (which mirrors what we
already do for OF-nodes) and limit using of_ APIs only to where it's
absolutely necessary (mostly around the of_xlate callback).

For backward compatibility of existing drivers we still support OF-nodes
but firmware nodes become the preferred method.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Philipp Zabel 
Signed-off-by: Philipp Zabel

reset: convert the core API to using firmware nodes

2026-03-09T09:20:04+00:00

In order to simplify the commit converting the internals of reset core
to using firmware nodes, first convert the user-facing API. Modify the
signature of the core consumer functions but leave the specialized
wrappers as is to avoid modifying users for now.

No functional change intended.

Reviewed-by: Philipp Zabel 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Philipp Zabel

reset: convert of_reset_control_get_count() to using firmware nodes

2026-03-09T09:20:04+00:00

Start the conversion of reset core to using firmware nodes by reworking
of_reset_control_get_count(). Unfortunately there is no fwnode-based
alternative to of_count_phandle_with_args() so we have to hand-code it.

Reviewed-by: Philipp Zabel 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Philipp Zabel

reset: protect struct reset_control with its own mutex

2026-03-09T09:20:04+00:00

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 control handle.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Philipp Zabel 
Signed-off-by: Philipp Zabel

reset: protect struct reset_controller_dev with its own mutex

2026-03-09T09:20:04+00:00

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 
Reviewed-by: Philipp Zabel 
Signed-off-by: Philipp Zabel

reset: handle removing supplier before consumers

2026-03-09T09:20:04+00:00

Except for the reset-gpio, all reset drivers use device tree - and as
such - benefit from the device links set up by driver core. This means,
that no reset supplier will be unbound before all its consumers have
been. For this reason, nobody bothered making the reset core resiliant
to the object life-time issues that are plagueing the kernel. In this
case: reset control handles referencing the reset provider device with
no serialization or NULL-pointer checking.

We now want to make the reset core fwnode-agnostic but before we do, we
must make sure it can survive unbinding of suppliers with consumers
still holding reset control handles.

To that end: use SRCU to protect the rcdev pointer inside struct
reset_control. We protect all sections using the pointer with SRCU
read-only critical sections and synchronize SRCU after every
modification of the pointer.

This is in line with what the GPIO subsystem does and what the proposed
revocable API tries to generalize. When and if the latter makes its way
into the kernel, reset core could potentially also be generalized to use
it.

Signed-off-by: Bartosz Golaszewski 
Reviewed-by: Philipp Zabel 
Signed-off-by: Philipp Zabel

reset: use lock guards in reset core

2026-03-09T09:20:03+00:00

Simplify the locking code in reset core by using lock guard from
linux/cleanup.h.

Reviewed-by: Philipp Zabel 
Signed-off-by: Bartosz Golaszewski 
Signed-off-by: Philipp Zabel