Re: [PATCH v2 00/14] reset: major reset core refactoring

[Bartosz Golaszewski]

On Mon, Feb 23, 2026 at 11:08 AM Bartosz Golaszewski
<bartosz.golaszewski@xxxxxxxxxxxxxxxx> wrote:
>
> Here is the promised refactoring of the reset core. The main goal of the
> series is to make the reset subsystem fwnode-agnostic - meaning it can
> work with all kinds of firmware nodes instead of being OF-centric - but
> there are some other related changes in here as well. I'm sending it all
> out for review to give Phillipp a better picture of the end result but
> individual pieces can be picked up earlier if accepted.
>
> The series is logically split into several parts:
>
> Patches 1-5: Several reset-gpio improvements. Most are not very
> controversial but I included a reworked version of the patch adding a
> firmware device link between the auxiliary reset device and its
> consumers.
>
> Patches 6-7: Just general improvements.
>
> Patch 8: Before we support all firmware nodes (even software nodes for
> which no devlinks are created) we need to make sure reset drivers can
> survive a sudden unbinding of the supplier with consumers still holding
> references to the controller. This patch addresses it using SRCU.
>
> Patches 9,10: Rework locking in reset core. Make locking fine-grained
> instead of using a single global lock for everything.
>
> Patches 11-14: Make reset core use fwnode as primary source of
> device properties and references. Convert reset-gpio to becoming the
> first fwnode-agnostic driver.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>
> ---

Hi Philipp!

I definitely don't mean to rush you but I wanted to ask what your plan
for this series is? If all looks good to you, I suggest to queue it
early into the cycle as with a rework that major I suspect there will
be some bug reports coming so it makes sense for it to cook for some
time in linux next and give me time to fix any regressions.

Bart