[PATCH 0/4] reset: Introduce reset_reset.*() API

[PATCH 0/4] reset: Introduce reset_reset.*() API

[Michal Simek]

Hi,

the patchset is adding reset_reset.*() interface which is common
in Linux. And implement it for ZynqMP.

Thanks,
Michal


Michal Simek (4):
  reset: Add reset_reset() and reset_reset_bulk() API
  reset: Add sandbox tests for reset_reset() and reset_reset_bulk()
  spi: cadence: Use reset_reset_bulk() for proper reset cycling
  reset: zynqmp: Implement rst_reset using PM_RESET_ACTION_PULSE

 arch/sandbox/include/asm/reset.h   |  2 ++
 drivers/reset/reset-uclass.c       | 30 +++++++++++++++++
 drivers/reset/reset-zynqmp.c       | 11 +++++++
 drivers/reset/sandbox-reset-test.c | 14 ++++++++
 drivers/spi/cadence_qspi.c         | 19 ++---------
 include/reset-uclass.h             | 11 +++++++
 include/reset.h                    | 35 ++++++++++++++++++++
 test/dm/reset.c                    | 53 ++++++++++++++++++++++++++++++
 8 files changed, 158 insertions(+), 17 deletions(-)

-- 
2.43.0

base-commit: 4885b1983ec158ed98e727091be38f7de104108e

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

[Michal Simek]

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 mirrors 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.

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

 drivers/reset/reset-uclass.c | 30 ++++++++++++++++++++++++++++++
 include/reset-uclass.h       | 11 +++++++++++
 include/reset.h              | 35 +++++++++++++++++++++++++++++++++++
 3 files changed, 76 insertions(+)

diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
index fe4cebf54f15..b26712abc366 100644
--- a/drivers/reset/reset-uclass.c
+++ b/drivers/reset/reset-uclass.c
@@ -225,6 +225,36 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
 	return 0;
 }
 
+int reset_reset(struct reset_ctl *reset_ctl)
+{
+	struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+	int ret;
+
+	debug("%s(reset_ctl=%p)\n", __func__, reset_ctl);
+
+	if (ops->rst_reset)
+		return ops->rst_reset(reset_ctl);
+
+	ret = reset_assert(reset_ctl);
+	if (ret < 0)
+		return ret;
+
+	return reset_deassert(reset_ctl);
+}
+
+int reset_reset_bulk(struct reset_ctl_bulk *bulk)
+{
+	int i, ret;
+
+	for (i = 0; i < bulk->count; i++) {
+		ret = reset_reset(&bulk->resets[i]);
+		if (ret < 0)
+			return ret;
+	}
+
+	return 0;
+}
+
 int reset_status(struct reset_ctl *reset_ctl)
 {
 	struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
diff --git a/include/reset-uclass.h b/include/reset-uclass.h
index 9a0696dd1e3b..3ff665c947ea 100644
--- a/include/reset-uclass.h
+++ b/include/reset-uclass.h
@@ -76,6 +76,17 @@ struct reset_ops {
 	 * @return 0 if OK, or a negative error code.
 	 */
 	int (*rst_deassert)(struct reset_ctl *reset_ctl);
+	/**
+	 * 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.
+	 * @return 0 if OK, or a negative error code.
+	 */
+	int (*rst_reset)(struct reset_ctl *reset_ctl);
 	/**
 	 * rst_status - Check reset signal status.
 	 *
diff --git a/include/reset.h b/include/reset.h
index 036a786d2ace..cd10596825a3 100644
--- a/include/reset.h
+++ b/include/reset.h
@@ -320,6 +320,31 @@ int reset_deassert(struct reset_ctl *reset_ctl);
  */
 int reset_deassert_bulk(struct reset_ctl_bulk *bulk);
 
+/**
+ * reset_reset - Reset a HW module by asserting and deasserting a reset signal.
+ *
+ * This function will assert and then deassert the specified reset signal,
+ * thus resetting the affected HW module. This is a convenience function
+ * that combines reset_assert() and reset_deassert().
+ *
+ * @reset_ctl:	A reset control struct that was previously successfully
+ *		requested by reset_get_by_*().
+ * Return: 0 if OK, or a negative error code.
+ */
+int reset_reset(struct reset_ctl *reset_ctl);
+
+/**
+ * reset_reset_bulk - Reset all HW modules in a reset control bulk struct.
+ *
+ * This function will assert and then deassert all reset signals in the
+ * specified reset control bulk struct, thus resetting all affected HW modules.
+ *
+ * @bulk:	A reset control bulk struct that was previously successfully
+ *		requested by reset_get_bulk().
+ * Return: 0 if OK, or a negative error code.
+ */
+int reset_reset_bulk(struct reset_ctl_bulk *bulk);
+
 /**
  * rst_status - Check reset signal status.
  *
@@ -443,6 +468,16 @@ static inline int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
 	return 0;
 }
 
+static inline int reset_reset(struct reset_ctl *reset_ctl)
+{
+	return 0;
+}
+
+static inline int reset_reset_bulk(struct reset_ctl_bulk *bulk)
+{
+	return 0;
+}
+
 static inline int reset_status(struct reset_ctl *reset_ctl)
 {
 	return -ENOTSUPP;
-- 
2.43.0

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

[Simon Glass]

Hi Michal,

On 2026-04-30T12:20:00, Michal Simek <michal.simek@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 mirrors 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.
>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
>
> drivers/reset/reset-uclass.c | 30 ++++++++++++++++++++++++++++++
>  include/reset-uclass.h       | 11 +++++++++++
>  include/reset.h              | 35 +++++++++++++++++++++++++++++++++++
>  3 files changed, 76 insertions(+)

> diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
> @@ -225,6 +225,36 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
> +int reset_reset(struct reset_ctl *reset_ctl)
> +{
> +     struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
> +     int ret;
> +
> +     debug('%s(reset_ctl=%p)\n', __func__, reset_ctl);
> +
> +     if (ops->rst_reset)
> +             return ops->rst_reset(reset_ctl);
> +
> +     ret = reset_assert(reset_ctl);
> +     if (ret < 0)
> +             return ret;
> +
> +     return reset_deassert(reset_ctl);
> +}

Will this provide a long-enough pulse on real hardware?

> diff --git a/include/reset.h b/include/reset.h
> @@ -443,6 +468,16 @@ static inline int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
> +static inline int reset_reset(struct reset_ctl *reset_ctl)
> +{
> +     return 0;
> +}

Just to check - this matches the existing assert/deassert stubs,
silently succeeding with !CONFIG_DM_RESET: is that intended? Should we
return -NOSYS here?

Regards,
Simon

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

[Michal Simek]

On 5/4/26 14:17, Simon Glass wrote:
> Hi Michal,
> 
> On 2026-04-30T12:20:00, Michal Simek <michal.simek@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 mirrors 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.
>>
>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>
>> drivers/reset/reset-uclass.c | 30 ++++++++++++++++++++++++++++++
>>   include/reset-uclass.h       | 11 +++++++++++
>>   include/reset.h              | 35 +++++++++++++++++++++++++++++++++++
>>   3 files changed, 76 insertions(+)
> 
>> diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
>> @@ -225,6 +225,36 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
>> +int reset_reset(struct reset_ctl *reset_ctl)
>> +{
>> +     struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
>> +     int ret;
>> +
>> +     debug('%s(reset_ctl=%p)\n', __func__, reset_ctl);
>> +
>> +     if (ops->rst_reset)
>> +             return ops->rst_reset(reset_ctl);
>> +
>> +     ret = reset_assert(reset_ctl);
>> +     if (ret < 0)
>> +             return ret;
>> +
>> +     return reset_deassert(reset_ctl);
>> +}
> 
> Will this provide a long-enough pulse on real hardware?

In our case delays are handled by firmware itself because we are asking firmware 
to do it. It means no issue on our platform.

GPIO based reset can be also handled via gpio delay driver.
But I can add there one more parameter to also pass waiting delay. What do you 
think?


> 
>> diff --git a/include/reset.h b/include/reset.h
>> @@ -443,6 +468,16 @@ static inline int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
>> +static inline int reset_reset(struct reset_ctl *reset_ctl)
>> +{
>> +     return 0;
>> +}
> 
> Just to check - this matches the existing assert/deassert stubs,
> silently succeeding with !CONFIG_DM_RESET: is that intended? Should we
> return -NOSYS here?

Will look at this one.

M

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

[Simon Glass]

Hi Michal,

On Mon, 4 May 2026 at 06:39, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 5/4/26 14:17, Simon Glass wrote:
> > Hi Michal,
> >
> > On 2026-04-30T12:20:00, Michal Simek <michal.simek@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 mirrors 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.
> >>
> >> Signed-off-by: Michal Simek <michal.simek@amd.com>
> >>
> >> drivers/reset/reset-uclass.c | 30 ++++++++++++++++++++++++++++++
> >>   include/reset-uclass.h       | 11 +++++++++++
> >>   include/reset.h              | 35 +++++++++++++++++++++++++++++++++++
> >>   3 files changed, 76 insertions(+)
> >
> >> diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
> >> @@ -225,6 +225,36 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
> >> +int reset_reset(struct reset_ctl *reset_ctl)
> >> +{
> >> +     struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
> >> +     int ret;
> >> +
> >> +     debug('%s(reset_ctl=%p)\n', __func__, reset_ctl);
> >> +
> >> +     if (ops->rst_reset)
> >> +             return ops->rst_reset(reset_ctl);
> >> +
> >> +     ret = reset_assert(reset_ctl);
> >> +     if (ret < 0)
> >> +             return ret;
> >> +
> >> +     return reset_deassert(reset_ctl);
> >> +}
> >
> > Will this provide a long-enough pulse on real hardware?
>
> In our case delays are handled by firmware itself because we are asking firmware
> to do it. It means no issue on our platform.
>
> GPIO based reset can be also handled via gpio delay driver.
> But I can add there one more parameter to also pass waiting delay. What do you
> think?

Seems like a good idea to me.

>
>
> >
> >> diff --git a/include/reset.h b/include/reset.h
> >> @@ -443,6 +468,16 @@ static inline int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
> >> +static inline int reset_reset(struct reset_ctl *reset_ctl)
> >> +{
> >> +     return 0;
> >> +}
> >
> > Just to check - this matches the existing assert/deassert stubs,
> > silently succeeding with !CONFIG_DM_RESET: is that intended? Should we
> > return -NOSYS here?
>
> Will look at this one.
>

I meant -ENOSYS of course. We have that in clk.h for example.

Regards,
Simon

[PATCH 2/4] reset: Add sandbox tests for reset_reset() and reset_reset_bulk()

[Michal Simek]

Add DM test coverage for the new reset_reset() and reset_reset_bulk()
API functions. The tests exercise the assert + deassert fallback path
since the sandbox reset driver does not implement the rst_reset op.

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

 arch/sandbox/include/asm/reset.h   |  2 ++
 drivers/reset/sandbox-reset-test.c | 14 ++++++++
 test/dm/reset.c                    | 53 ++++++++++++++++++++++++++++++
 3 files changed, 69 insertions(+)

diff --git a/arch/sandbox/include/asm/reset.h b/arch/sandbox/include/asm/reset.h
index f0709b41c09f..5b48c2fe7bbf 100644
--- a/arch/sandbox/include/asm/reset.h
+++ b/arch/sandbox/include/asm/reset.h
@@ -19,6 +19,8 @@ int sandbox_reset_test_assert(struct udevice *dev);
 int sandbox_reset_test_assert_bulk(struct udevice *dev);
 int sandbox_reset_test_deassert(struct udevice *dev);
 int sandbox_reset_test_deassert_bulk(struct udevice *dev);
+int sandbox_reset_test_reset(struct udevice *dev);
+int sandbox_reset_test_reset_bulk(struct udevice *dev);
 int sandbox_reset_test_free(struct udevice *dev);
 int sandbox_reset_test_release_bulk(struct udevice *dev);
 
diff --git a/drivers/reset/sandbox-reset-test.c b/drivers/reset/sandbox-reset-test.c
index dfacb764bc77..1f599d629eb9 100644
--- a/drivers/reset/sandbox-reset-test.c
+++ b/drivers/reset/sandbox-reset-test.c
@@ -96,6 +96,20 @@ int sandbox_reset_test_deassert_bulk(struct udevice *dev)
 	return reset_deassert_bulk(sbrt->bulkp);
 }
 
+int sandbox_reset_test_reset(struct udevice *dev)
+{
+	struct sandbox_reset_test *sbrt = dev_get_priv(dev);
+
+	return reset_reset(sbrt->ctlp);
+}
+
+int sandbox_reset_test_reset_bulk(struct udevice *dev)
+{
+	struct sandbox_reset_test *sbrt = dev_get_priv(dev);
+
+	return reset_reset_bulk(sbrt->bulkp);
+}
+
 int sandbox_reset_test_free(struct udevice *dev)
 {
 	struct sandbox_reset_test *sbrt = dev_get_priv(dev);
diff --git a/test/dm/reset.c b/test/dm/reset.c
index dceb6a1dad38..343c2feb190d 100644
--- a/test/dm/reset.c
+++ b/test/dm/reset.c
@@ -120,6 +120,59 @@ static int dm_test_reset_devm(struct unit_test_state *uts)
 }
 DM_TEST(dm_test_reset_devm, UTF_SCAN_FDT);
 
+static int dm_test_reset_reset(struct unit_test_state *uts)
+{
+	struct udevice *dev_reset;
+	struct udevice *dev_test;
+
+	ut_assertok(uclass_get_device_by_name(UCLASS_RESET, "reset-ctl",
+					      &dev_reset));
+	ut_asserteq(0, sandbox_reset_query(dev_reset, TEST_RESET_ID));
+
+	ut_assertok(uclass_get_device_by_name(UCLASS_MISC, "reset-ctl-test",
+					      &dev_test));
+	ut_assertok(sandbox_reset_test_get(dev_test));
+
+	ut_assertok(sandbox_reset_test_assert(dev_test));
+	ut_asserteq(1, sandbox_reset_query(dev_reset, TEST_RESET_ID));
+
+	ut_assertok(sandbox_reset_test_reset(dev_test));
+	ut_asserteq(0, sandbox_reset_query(dev_reset, TEST_RESET_ID));
+
+	ut_assertok(sandbox_reset_test_free(dev_test));
+
+	return 0;
+}
+DM_TEST(dm_test_reset_reset, UTF_SCAN_FDT);
+
+static int dm_test_reset_reset_bulk(struct unit_test_state *uts)
+{
+	struct udevice *dev_reset;
+	struct udevice *dev_test;
+
+	ut_assertok(uclass_get_device_by_name(UCLASS_RESET, "reset-ctl",
+					      &dev_reset));
+	ut_asserteq(0, sandbox_reset_query(dev_reset, TEST_RESET_ID));
+	ut_asserteq(0, sandbox_reset_query(dev_reset, OTHER_RESET_ID));
+
+	ut_assertok(uclass_get_device_by_name(UCLASS_MISC, "reset-ctl-test",
+					      &dev_test));
+	ut_assertok(sandbox_reset_test_get_bulk(dev_test));
+
+	ut_assertok(sandbox_reset_test_assert_bulk(dev_test));
+	ut_asserteq(1, sandbox_reset_query(dev_reset, TEST_RESET_ID));
+	ut_asserteq(1, sandbox_reset_query(dev_reset, OTHER_RESET_ID));
+
+	ut_assertok(sandbox_reset_test_reset_bulk(dev_test));
+	ut_asserteq(0, sandbox_reset_query(dev_reset, TEST_RESET_ID));
+	ut_asserteq(0, sandbox_reset_query(dev_reset, OTHER_RESET_ID));
+
+	ut_assertok(sandbox_reset_test_release_bulk(dev_test));
+
+	return 0;
+}
+DM_TEST(dm_test_reset_reset_bulk, UTF_SCAN_FDT);
+
 static int dm_test_reset_bulk(struct unit_test_state *uts)
 {
 	struct udevice *dev_reset;
-- 
2.43.0

Re: [PATCH 2/4] reset: Add sandbox tests for reset_reset() and reset_reset_bulk()

[Simon Glass]

Hi Michal,

On 2026-04-30T12:20:00, Michal Simek <michal.simek@amd.com> wrote:
> reset: Add sandbox tests for reset_reset() and reset_reset_bulk()
>
> Add DM test coverage for the new reset_reset() and reset_reset_bulk()
> API functions. The tests exercise the assert + deassert fallback path
> since the sandbox reset driver does not implement the rst_reset op.
>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
>
> arch/sandbox/include/asm/reset.h   |  2 ++
>  drivers/reset/sandbox-reset-test.c | 14 ++++++++++
>  test/dm/reset.c                    | 53 ++++++++++++++++++++++++++++++++++++++
>  3 files changed, 69 insertions(+)

> diff --git a/test/dm/reset.c b/test/dm/reset.c
> @@ -120,6 +120,59 @@ static int dm_test_reset_devm(struct unit_test_state *uts)
> +     ut_assertok(sandbox_reset_test_assert(dev_test));
> +     ut_asserteq(1, sandbox_reset_query(dev_reset, TEST_RESET_ID));
> +
> +     ut_assertok(sandbox_reset_test_reset(dev_test));
> +     ut_asserteq(0, sandbox_reset_query(dev_reset, TEST_RESET_ID));

This only checks the final state, i.e. a broken reset_reset() that
skips the assert step would still pass, since the line was already
asserted manually before the call. Please can you extend the sandbox
driver to track the assert phase (a sticky 'was_asserted' flag or a
transition counter) so the test confirms both halves of the pulse
actually happen? Same for dm_test_reset_reset_bulk()

> diff --git a/drivers/reset/sandbox-reset-test.c b/drivers/reset/sandbox-reset-test.c
> @@ -96,6 +96,20 @@ int sandbox_reset_test_deassert_bulk(struct udevice *dev)
> +int sandbox_reset_test_reset(struct udevice *dev)
> +{
> +     struct sandbox_reset_test *sbrt = dev_get_priv(dev);
> +
> +     return reset_reset(sbrt->ctlp);
> +}

Re your commit message, better to implement rst_reset for sandbox, so
that we keep the coverage up.

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

Regards,
Simon

Re: [PATCH 2/4] reset: Add sandbox tests for reset_reset() and reset_reset_bulk()

[Michal Simek]

On 5/4/26 14:17, Simon Glass wrote:
> Hi Michal,
> 
> On 2026-04-30T12:20:00, Michal Simek <michal.simek@amd.com> wrote:
>> reset: Add sandbox tests for reset_reset() and reset_reset_bulk()
>>
>> Add DM test coverage for the new reset_reset() and reset_reset_bulk()
>> API functions. The tests exercise the assert + deassert fallback path
>> since the sandbox reset driver does not implement the rst_reset op.
>>
>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>
>> arch/sandbox/include/asm/reset.h   |  2 ++
>>   drivers/reset/sandbox-reset-test.c | 14 ++++++++++
>>   test/dm/reset.c                    | 53 ++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 69 insertions(+)
> 
>> diff --git a/test/dm/reset.c b/test/dm/reset.c
>> @@ -120,6 +120,59 @@ static int dm_test_reset_devm(struct unit_test_state *uts)
>> +     ut_assertok(sandbox_reset_test_assert(dev_test));
>> +     ut_asserteq(1, sandbox_reset_query(dev_reset, TEST_RESET_ID));
>> +
>> +     ut_assertok(sandbox_reset_test_reset(dev_test));
>> +     ut_asserteq(0, sandbox_reset_query(dev_reset, TEST_RESET_ID));
> 
> This only checks the final state, i.e. a broken reset_reset() that
> skips the assert step would still pass, since the line was already
> asserted manually before the call. Please can you extend the sandbox
> driver to track the assert phase (a sticky 'was_asserted' flag or a
> transition counter) so the test confirms both halves of the pulse
> actually happen? Same for dm_test_reset_reset_bulk()
> 
>> diff --git a/drivers/reset/sandbox-reset-test.c b/drivers/reset/sandbox-reset-test.c
>> @@ -96,6 +96,20 @@ int sandbox_reset_test_deassert_bulk(struct udevice *dev)
>> +int sandbox_reset_test_reset(struct udevice *dev)
>> +{
>> +     struct sandbox_reset_test *sbrt = dev_get_priv(dev);
>> +
>> +     return reset_reset(sbrt->ctlp);
>> +}
> 
> Re your commit message, better to implement rst_reset for sandbox, so
> that we keep the coverage up.

Will look.

M

[PATCH 3/4] spi: cadence: Use reset_reset_bulk() for proper reset cycling

[Michal Simek]

Use the new reset_reset_bulk() API to properly cycle reset signals
during probe instead of just deasserting them. This ensures the
controller is properly reset before initialization.

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

 drivers/spi/cadence_qspi.c | 19 ++-----------------
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 2a4a49c5f1cf..b9f2481b9cd3 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -255,23 +255,8 @@ static int cadence_spi_probe(struct udevice *bus)
 	}
 
 	priv->resets = devm_reset_bulk_get_optional(bus);
-	if (priv->resets) {
-		/* Assert all OSPI reset lines */
-		ret = reset_assert_bulk(priv->resets);
-		if (ret) {
-			dev_err(bus, "Failed to assert OSPI reset: %d\n", ret);
-			return ret;
-		}
-
-		udelay(10);
-
-		/* Deassert all OSPI reset lines */
-		ret = reset_deassert_bulk(priv->resets);
-		if (ret) {
-			dev_err(bus, "Failed to deassert OSPI reset: %d\n", ret);
-			return ret;
-		}
-	}
+	if (priv->resets)
+		reset_reset_bulk(priv->resets);
 
 	if (!priv->qspi_is_init) {
 		cadence_qspi_apb_controller_init(priv);
-- 
2.43.0

Re: [PATCH 3/4] spi: cadence: Use reset_reset_bulk() for proper reset cycling

[Simon Glass]

Hi Michal,

On 2026-04-30T12:20:00, Michal Simek <michal.simek@amd.com> wrote:
> spi: cadence: Use reset_reset_bulk() for proper reset cycling
>
> Use the new reset_reset_bulk() API to properly cycle reset signals
> during probe instead of just deasserting them. This ensures the
> controller is properly reset before initialization.
>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
>
> drivers/spi/cadence_qspi.c | 19 ++-----------------
>  1 file changed, 2 insertions(+), 17 deletions(-)

> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> @@ -255,23 +255,8 @@ static int cadence_spi_probe(struct udevice *bus)
> -             udelay(10);
> -
> -             /* Deassert all OSPI reset lines */
> -             ret = reset_deassert_bulk(priv->resets);
> -             if (ret) {
> -                     dev_err(bus, "Failed to deassert OSPI reset: %d\n", ret);
> -                     return ret;
> -             }
> -     }
> +     if (priv->resets)
> +             reset_reset_bulk(priv->resets);

This silently drops the 10us delay that commit 834d589b8f1 ('spi:
cadence_qspi: pulse controller reset at probe') deliberately added
between assert and deassert. Is that intended?

> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> @@ -255,23 +255,8 @@ static int cadence_spi_probe(struct udevice *bus)
> +     if (priv->resets)
> +             reset_reset_bulk(priv->resets);

The return value is now discarded - is that intended?

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

Regards,
Simon

Re: [PATCH 3/4] spi: cadence: Use reset_reset_bulk() for proper reset cycling

[Michal Simek]

On 5/4/26 14:18, Simon Glass wrote:
> Hi Michal,
> 
> On 2026-04-30T12:20:00, Michal Simek <michal.simek@amd.com> wrote:
>> spi: cadence: Use reset_reset_bulk() for proper reset cycling
>>
>> Use the new reset_reset_bulk() API to properly cycle reset signals
>> during probe instead of just deasserting them. This ensures the
>> controller is properly reset before initialization.
>>
>> Signed-off-by: Michal Simek <michal.simek@amd.com>
>>
>> drivers/spi/cadence_qspi.c | 19 ++-----------------
>>   1 file changed, 2 insertions(+), 17 deletions(-)
> 
>> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
>> @@ -255,23 +255,8 @@ static int cadence_spi_probe(struct udevice *bus)
>> -             udelay(10);
>> -
>> -             /* Deassert all OSPI reset lines */
>> -             ret = reset_deassert_bulk(priv->resets);
>> -             if (ret) {
>> -                     dev_err(bus, "Failed to deassert OSPI reset: %d\n", ret);
>> -                     return ret;
>> -             }
>> -     }
>> +     if (priv->resets)
>> +             reset_reset_bulk(priv->resets);
> 
> This silently drops the 10us delay that commit 834d589b8f1 ('spi:
> cadence_qspi: pulse controller reset at probe') deliberately added
> between assert and deassert. Is that intended?
> 
>> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
>> @@ -255,23 +255,8 @@ static int cadence_spi_probe(struct udevice *bus)
>> +     if (priv->resets)
>> +             reset_reset_bulk(priv->resets);
> 
> The return value is now discarded - is that intended?

Not really. It should be also checked.

M

[PATCH 4/4] reset: zynqmp: Implement rst_reset using PM_RESET_ACTION_PULSE

[Michal Simek]

Implement the rst_reset operation in the ZynqMP reset driver to use
PM_RESET_ACTION_PULSE. This allows the reset controller to perform
a reset pulse in a single firmware call instead of separate assert
and deassert calls.

This matches the Linux kernel implementation of zynqmp_reset_reset().

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

 drivers/reset/reset-zynqmp.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/drivers/reset/reset-zynqmp.c b/drivers/reset/reset-zynqmp.c
index d04e8eef3bb4..b87085b6c5e1 100644
--- a/drivers/reset/reset-zynqmp.c
+++ b/drivers/reset/reset-zynqmp.c
@@ -45,6 +45,16 @@ static int zynqmp_reset_deassert(struct reset_ctl *rst)
 				      PM_RESET_ACTION_RELEASE);
 }
 
+static int zynqmp_reset_reset(struct reset_ctl *rst)
+{
+	struct zynqmp_reset_priv *priv = dev_get_priv(rst->dev);
+
+	dev_dbg(rst->dev, "%s(rst=%p) (id=%lu)\n", __func__, rst, rst->id);
+
+	return zynqmp_pm_reset_assert(priv->reset_id + rst->id,
+				      PM_RESET_ACTION_PULSE);
+}
+
 static int zynqmp_reset_request(struct reset_ctl *rst)
 {
 	struct zynqmp_reset_priv *priv = dev_get_priv(rst->dev);
@@ -74,6 +84,7 @@ const struct reset_ops zynqmp_reset_ops = {
 	.request = zynqmp_reset_request,
 	.rst_assert = zynqmp_reset_assert,
 	.rst_deassert = zynqmp_reset_deassert,
+	.rst_reset = zynqmp_reset_reset,
 };
 
 static const struct udevice_id zynqmp_reset_ids[] = {
-- 
2.43.0

Re: [PATCH 4/4] reset: zynqmp: Implement rst_reset using PM_RESET_ACTION_PULSE

[Simon Glass]

On 2026-04-30T12:20:00, Michal Simek <michal.simek@amd.com> wrote:
> reset: zynqmp: Implement rst_reset using PM_RESET_ACTION_PULSE
>
> Implement the rst_reset operation in the ZynqMP reset driver to use
> PM_RESET_ACTION_PULSE. This allows the reset controller to perform
> a reset pulse in a single firmware call instead of separate assert
> and deassert calls.
>
> This matches the Linux kernel implementation of zynqmp_reset_reset().
>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
>
> drivers/reset/reset-zynqmp.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)

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