[PATCH v2 1/4] reset: Add reset_reset() and reset_reset_bulk() API

[Simon Glass]

Hi Michal,

On 2026-05-05T12:30:28, Michal Simek <michal.simek at amd.com> wrote:
> reset: Add reset_reset() and reset_reset_bulk() API
>
> Add reset_reset() and reset_reset_bulk() functions to the reset
> controller API. These functions assert and then deassert reset signals
> in a single call, providing a convenient way to pulse/toggle a reset
> line.
>
> This mimics the Linux kernel's reset_control_reset() and
> reset_control_bulk_reset() APIs. The new functions are useful for
> drivers that need to cycle a reset line during initialization or
> error recovery but with also passing delay parameter.
>
> If a driver implements the rst_reset op, it will be called directly
> with the delay parameter. Otherwise, the reset core performs
> reset_assert(), optional udelay(), and reset_deassert() as fallback.
>
> Signed-off-by: Michal Simek <michal.simek at amd.com>
>
> drivers/reset/reset-uclass.c | 34 ++++++++++++++++++++++++++++++++++
>  include/reset-uclass.h       | 12 ++++++++++++
>  include/reset.h              | 41 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 87 insertions(+)

Reviewed-by: Simon Glass <sjg at chromium.org>

optional nits / thoughts below

> diff --git a/include/reset-uclass.h b/include/reset-uclass.h
> @@ -76,6 +76,18 @@ struct reset_ops {
> +     /**
> +      * rst_reset - Reset a HW module.
> +      *
> +      * This optional function triggers a reset pulse on the reset line,
> +      * asserting and then deasserting the reset signal. If not implemented,
> +      * the reset core will use rst_assert followed by rst_deassert.
> +      *
> +      * @reset_ctl:  The reset signal to pulse.
> +      * @delay_us:   Delay in microseconds between assert and deassert.
> +      * @return 0 if OK, or a negative error code.
> +      */
> +     int (*rst_reset)(struct reset_ctl *reset_ctl, ulong delay_us);

Please document that the core inserts a udelay(delay_us) between
rst_assert and rst_deassert in the fallback path, and clarify whether
an rst_reset implementation must honour delay_us or may treat it as a
hint. Without that, authors don't really know what to do with the
value.

> diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
> @@ -225,6 +226,39 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
> +int reset_reset_bulk(struct reset_ctl_bulk *bulk, ulong delay_us)
> +{
> +     int i, ret;
> +
> +     for (i = 0; i < bulk->count; i++) {
> +             ret = reset_reset(&bulk->resets[i], delay_us);
> +             if (ret < 0)
> +                     return ret;
> +     }
> +
> +     return 0;
> +}

Just to check - pulsing each reset sequentially means the first
finishes its full assert/delay/deassert before the next starts
asserting. For the cadence_qspi case in 3/4, where multiple OSPI reset
lines are expected to be asserted together, the previous code did
assert_bulk() / udelay() / deassert_bulk() so all lines were held low
simultaneously. The new behaviour is different. Is that intentional,
and have you confirmed the cadence controller is happy with it?

Regards,
Simon