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

[PATCH v2 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

Changes in v2:
- Add delay_us parameter to specify delay between assert and deassert
- Pass delay_us to rst_reset op so drivers can use it if needed
- Return -ENOSYS in stubs when !CONFIG_DM_RESET (like clk.h)
- Fix line length to stay within 80 characters
- Add reset_count field to track reset pulse operations
- Implement sandbox_reset_reset() for rst_reset op
- Add sandbox_reset_get_count() to query reset pulse count
- Clear reset_count when reset is requested
- Update tests to verify reset pulse actually happened
- Pass 10us via parameter

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   |  3 ++
 drivers/reset/reset-uclass.c       | 34 +++++++++++++++
 drivers/reset/reset-zynqmp.c       | 11 +++++
 drivers/reset/sandbox-reset-test.c | 14 +++++++
 drivers/reset/sandbox-reset.c      | 31 ++++++++++++++
 drivers/spi/cadence_qspi.c         | 16 ++-----
 include/reset-uclass.h             | 12 ++++++
 include/reset.h                    | 41 ++++++++++++++++++
 test/dm/reset.c                    | 67 ++++++++++++++++++++++++++++++
 9 files changed, 217 insertions(+), 12 deletions(-)

-- 
2.43.0

base-commit: 57460fde4ba84d67de4066ee1141e89e8139ed23

[PATCH v2 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 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@amd.com>
---

Changes in v2:
- Add delay_us parameter to specify delay between assert and deassert
- Pass delay_us to rst_reset op so drivers can use it if needed
- Return -ENOSYS in stubs when !CONFIG_DM_RESET (like clk.h)
- Fix line length to stay within 80 characters

 drivers/reset/reset-uclass.c | 34 ++++++++++++++++++++++++++++++
 include/reset-uclass.h       | 12 +++++++++++
 include/reset.h              | 41 ++++++++++++++++++++++++++++++++++++
 3 files changed, 87 insertions(+)

diff --git a/drivers/reset/reset-uclass.c b/drivers/reset/reset-uclass.c
index fe4cebf54f15..c199e3e5da71 100644
--- a/drivers/reset/reset-uclass.c
+++ b/drivers/reset/reset-uclass.c
@@ -13,6 +13,7 @@
 #include <reset-uclass.h>
 #include <dm/devres.h>
 #include <dm/lists.h>
+#include <linux/delay.h>
 
 static inline struct reset_ops *reset_dev_ops(struct udevice *dev)
 {
@@ -225,6 +226,39 @@ int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
 	return 0;
 }
 
+int reset_reset(struct reset_ctl *reset_ctl, ulong delay_us)
+{
+	struct reset_ops *ops = reset_dev_ops(reset_ctl->dev);
+	int ret;
+
+	debug("%s(reset_ctl=%p, delay_us=%lu)\n", __func__, reset_ctl,
+	      delay_us);
+
+	if (ops->rst_reset)
+		return ops->rst_reset(reset_ctl, delay_us);
+
+	ret = reset_assert(reset_ctl);
+	if (ret < 0)
+		return ret;
+
+	udelay(delay_us);
+
+	return reset_deassert(reset_ctl);
+}
+
+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;
+}
+
 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..706fcffd234d 100644
--- a/include/reset-uclass.h
+++ b/include/reset-uclass.h
@@ -76,6 +76,18 @@ 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.
+	 * @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);
 	/**
 	 * rst_status - Check reset signal status.
 	 *
diff --git a/include/reset.h b/include/reset.h
index 036a786d2ace..a4a6ea962b2b 100644
--- a/include/reset.h
+++ b/include/reset.h
@@ -320,6 +320,37 @@ 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_*().
+ * @delay_us:	Delay in microseconds between assert and deassert.
+ *		Use 0 for no delay (or when the driver handles the delay
+ *		internally via rst_reset op).
+ * Return: 0 if OK, or a negative error code.
+ */
+int reset_reset(struct reset_ctl *reset_ctl, ulong delay_us);
+
+/**
+ * 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().
+ * @delay_us:	Delay in microseconds between assert and deassert.
+ *		Use 0 for no delay (or when the driver handles the delay
+ *		internally via rst_reset op).
+ * Return: 0 if OK, or a negative error code.
+ */
+int reset_reset_bulk(struct reset_ctl_bulk *bulk, ulong delay_us);
+
 /**
  * rst_status - Check reset signal status.
  *
@@ -443,6 +474,16 @@ static inline int reset_deassert_bulk(struct reset_ctl_bulk *bulk)
 	return 0;
 }
 
+static inline int reset_reset(struct reset_ctl *reset_ctl, ulong delay_us)
+{
+	return -ENOSYS;
+}
+
+static inline int reset_reset_bulk(struct reset_ctl_bulk *bulk, ulong delay_us)
+{
+	return -ENOSYS;
+}
+
 static inline int reset_status(struct reset_ctl *reset_ctl)
 {
 	return -ENOTSUPP;
-- 
2.43.0

Re: [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@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@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@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

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

[Michal Simek]

On 5/7/26 23:11, Simon Glass wrote:
> Hi Michal,
> 
> On 2026-05-05T12:30:28, 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 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@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@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.

ok. Will fix in v3.


>> 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?

You are right that behavior has changed but it is aligned with what Linux kernel 
is doing.
We are using only one reset line that's why not an issue for us. But it saves 
one firmware call (per reset line).

int reset_control_bulk_reset(int num_rstcs,
                              struct reset_control_bulk_data *rstcs)
{
         int ret, i;

         for (i = 0; i < num_rstcs; i++) {
                 ret = reset_control_reset(rstcs[i].rstc);
                 if (ret)
                         return ret;
         }

         return 0;
}
EXPORT_SYMBOL_GPL(reset_control_bulk_reset);


If it is problematic we can go back to assert_bulk/delay/deassert_bulk in 
cadence driver.

Thanks,
Michal

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

[Simon Glass]

Hi Michal,

On Wed, 13 May 2026 at 02:25, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 5/7/26 23:11, Simon Glass wrote:
> > Hi Michal,
> >
> > On 2026-05-05T12:30:28, 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 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@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@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.
>
> ok. Will fix in v3.
>
>
> >> 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?
>
> You are right that behavior has changed but it is aligned with what Linux kernel
> is doing.
> We are using only one reset line that's why not an issue for us. But it saves
> one firmware call (per reset line).
>
> int reset_control_bulk_reset(int num_rstcs,
>                               struct reset_control_bulk_data *rstcs)
> {
>          int ret, i;
>
>          for (i = 0; i < num_rstcs; i++) {
>                  ret = reset_control_reset(rstcs[i].rstc);
>                  if (ret)
>                          return ret;
>          }
>
>          return 0;
> }
> EXPORT_SYMBOL_GPL(reset_control_bulk_reset);
>
>
> If it is problematic we can go back to assert_bulk/delay/deassert_bulk in
> cadence driver.

Well if it matches Linux we should be OK.

Regards,
Simon

[PATCH v2 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>
---

Changes in v2:
- Add reset_count field to track reset pulse operations
- Implement sandbox_reset_reset() for rst_reset op
- Add sandbox_reset_get_count() to query reset pulse count
- Clear reset_count when reset is requested
- Update tests to verify reset pulse actually happened

 arch/sandbox/include/asm/reset.h   |  3 ++
 drivers/reset/sandbox-reset-test.c | 14 +++++++
 drivers/reset/sandbox-reset.c      | 31 ++++++++++++++
 test/dm/reset.c                    | 67 ++++++++++++++++++++++++++++++
 4 files changed, 115 insertions(+)

diff --git a/arch/sandbox/include/asm/reset.h b/arch/sandbox/include/asm/reset.h
index f0709b41c09f..2890e0dc09bd 100644
--- a/arch/sandbox/include/asm/reset.h
+++ b/arch/sandbox/include/asm/reset.h
@@ -10,6 +10,7 @@ struct udevice;
 
 int sandbox_reset_query(struct udevice *dev, unsigned long id);
 int sandbox_reset_is_requested(struct udevice *dev, unsigned long id);
+int sandbox_reset_get_count(struct udevice *dev, unsigned long id);
 
 int sandbox_reset_test_get(struct udevice *dev);
 int sandbox_reset_test_get_devm(struct udevice *dev);
@@ -19,6 +20,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..64c205596c5e 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, 0);
+}
+
+int sandbox_reset_test_reset_bulk(struct udevice *dev)
+{
+	struct sandbox_reset_test *sbrt = dev_get_priv(dev);
+
+	return reset_reset_bulk(sbrt->bulkp, 0);
+}
+
 int sandbox_reset_test_free(struct udevice *dev)
 {
 	struct sandbox_reset_test *sbrt = dev_get_priv(dev);
diff --git a/drivers/reset/sandbox-reset.c b/drivers/reset/sandbox-reset.c
index adf9eedcba6d..71fba5b15da0 100644
--- a/drivers/reset/sandbox-reset.c
+++ b/drivers/reset/sandbox-reset.c
@@ -9,12 +9,14 @@
 #include <reset-uclass.h>
 #include <asm/io.h>
 #include <asm/reset.h>
+#include <linux/delay.h>
 
 #define SANDBOX_RESET_SIGNALS 101
 
 struct sandbox_reset_signal {
 	bool asserted;
 	bool requested;
+	int reset_count;
 };
 
 struct sandbox_reset {
@@ -31,6 +33,7 @@ static int sandbox_reset_request(struct reset_ctl *reset_ctl)
 		return -EINVAL;
 
 	sbr->signals[reset_ctl->id].requested = true;
+	sbr->signals[reset_ctl->id].reset_count = 0;
 	return 0;
 }
 
@@ -66,6 +69,21 @@ static int sandbox_reset_deassert(struct reset_ctl *reset_ctl)
 	return 0;
 }
 
+static int sandbox_reset_reset(struct reset_ctl *reset_ctl, ulong delay_us)
+{
+	struct sandbox_reset *sbr = dev_get_priv(reset_ctl->dev);
+
+	debug("%s(reset_ctl=%p, delay_us=%lu)\n", __func__, reset_ctl,
+	      delay_us);
+
+	sbr->signals[reset_ctl->id].asserted = true;
+	udelay(delay_us);
+	sbr->signals[reset_ctl->id].asserted = false;
+	sbr->signals[reset_ctl->id].reset_count++;
+
+	return 0;
+}
+
 static int sandbox_reset_bind(struct udevice *dev)
 {
 	debug("%s(dev=%p)\n", __func__, dev);
@@ -90,6 +108,7 @@ struct reset_ops sandbox_reset_reset_ops = {
 	.rfree = sandbox_reset_free,
 	.rst_assert = sandbox_reset_assert,
 	.rst_deassert = sandbox_reset_deassert,
+	.rst_reset = sandbox_reset_reset,
 };
 
 U_BOOT_DRIVER(sandbox_reset) = {
@@ -125,3 +144,15 @@ int sandbox_reset_is_requested(struct udevice *dev, unsigned long id)
 
 	return sbr->signals[id].requested;
 }
+
+int sandbox_reset_get_count(struct udevice *dev, unsigned long id)
+{
+	struct sandbox_reset *sbr = dev_get_priv(dev);
+
+	debug("%s(dev=%p, id=%ld)\n", __func__, dev, id);
+
+	if (id >= SANDBOX_RESET_SIGNALS)
+		return -EINVAL;
+
+	return sbr->signals[id].reset_count;
+}
diff --git a/test/dm/reset.c b/test/dm/reset.c
index dceb6a1dad38..043d7cb7e0fc 100644
--- a/test/dm/reset.c
+++ b/test/dm/reset.c
@@ -120,6 +120,73 @@ 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));
+
+	/* Verify reset_count starts at 0 */
+	ut_asserteq(0, sandbox_reset_get_count(dev_reset, TEST_RESET_ID));
+
+	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));
+
+	/* Verify reset was pulsed (count incremented) */
+	ut_asserteq(1, sandbox_reset_get_count(dev_reset, TEST_RESET_ID));
+	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));
+
+	/* Verify reset_count starts at 0 */
+	ut_asserteq(0, sandbox_reset_get_count(dev_reset, TEST_RESET_ID));
+	ut_asserteq(0, sandbox_reset_get_count(dev_reset, OTHER_RESET_ID));
+
+	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));
+
+	/* Verify resets were pulsed (counts incremented) */
+	ut_asserteq(1, sandbox_reset_get_count(dev_reset, TEST_RESET_ID));
+	ut_asserteq(1, sandbox_reset_get_count(dev_reset, OTHER_RESET_ID));
+	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 v2 2/4] reset: Add sandbox tests for reset_reset() and reset_reset_bulk()

[Simon Glass]

Hi Michal,

On 2026-05-05T12:30:28, 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   |  3 ++
>  drivers/reset/sandbox-reset-test.c | 14 ++++++++
>  drivers/reset/sandbox-reset.c      | 31 ++++++++++++++++++
>  test/dm/reset.c                    | 67 ++++++++++++++++++++++++++++++++++++++
>  4 files changed, 115 insertions(+)

> diff --git a/drivers/reset/sandbox-reset.c b/drivers/reset/sandbox-reset.c
> @@ -66,6 +69,21 @@ static int sandbox_reset_deassert(struct reset_ctl *reset_ctl)
>       return 0;
>  }
>
> +static int sandbox_reset_reset(struct reset_ctl *reset_ctl, ulong delay_us)
> +{
> +     struct sandbox_reset *sbr = dev_get_priv(reset_ctl->dev);
> +
> +     debug("%s(reset_ctl=%p, delay_us=%lu)\n", __func__, reset_ctl,
> +           delay_us);
> +
> +     sbr->signals[reset_ctl->id].asserted = true;
> +     udelay(delay_us);
> +     sbr->signals[reset_ctl->id].asserted = false;
> +     sbr->signals[reset_ctl->id].reset_count++;
> +
> +     return 0;
> +}

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

Some optional nits / thoughts below.

The commit message says the tests exercise the fallback path since the
sandbox reset driver doesn't have rst_reset op, this patch adds that
method below - so the commit message could use an update.

If you want coverage for the fallback you could add a second
sandbox-reset driver without rst_reset, or hack the rest to clear and
restart ops->rst_reset,

> 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, 0);
> +}
> +
> +int sandbox_reset_test_reset_bulk(struct udevice *dev)
> +{
> +     struct sandbox_reset_test *sbrt = dev_get_priv(dev);
> +
> +     return reset_reset_bulk(sbrt->bulkp, 0);
> +}

You could pass a non-zero value here if you want to test the delay.

Regards,
Simon

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

[Michal Simek]

On 5/7/26 23:11, Simon Glass wrote:
> Hi Michal,
> 
> On 2026-05-05T12:30:28, 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   |  3 ++
>>   drivers/reset/sandbox-reset-test.c | 14 ++++++++
>>   drivers/reset/sandbox-reset.c      | 31 ++++++++++++++++++
>>   test/dm/reset.c                    | 67 ++++++++++++++++++++++++++++++++++++++
>>   4 files changed, 115 insertions(+)
> 
>> diff --git a/drivers/reset/sandbox-reset.c b/drivers/reset/sandbox-reset.c
>> @@ -66,6 +69,21 @@ static int sandbox_reset_deassert(struct reset_ctl *reset_ctl)
>>        return 0;
>>   }
>>
>> +static int sandbox_reset_reset(struct reset_ctl *reset_ctl, ulong delay_us)
>> +{
>> +     struct sandbox_reset *sbr = dev_get_priv(reset_ctl->dev);
>> +
>> +     debug("%s(reset_ctl=%p, delay_us=%lu)\n", __func__, reset_ctl,
>> +           delay_us);
>> +
>> +     sbr->signals[reset_ctl->id].asserted = true;
>> +     udelay(delay_us);
>> +     sbr->signals[reset_ctl->id].asserted = false;
>> +     sbr->signals[reset_ctl->id].reset_count++;
>> +
>> +     return 0;
>> +}
> 
> Reviewed-by: Simon Glass <sjg@chromium.org>
> 
> Some optional nits / thoughts below.
> 
> The commit message says the tests exercise the fallback path since the
> sandbox reset driver doesn't have rst_reset op, this patch adds that
> method below - so the commit message could use an update.

Will update.

> 
> If you want coverage for the fallback you could add a second
> sandbox-reset driver without rst_reset, or hack the rest to clear and
> restart ops->rst_reset,
> 
>> 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, 0);
>> +}
>> +
>> +int sandbox_reset_test_reset_bulk(struct udevice *dev)
>> +{
>> +     struct sandbox_reset_test *sbrt = dev_get_priv(dev);
>> +
>> +     return reset_reset_bulk(sbrt->bulkp, 0);
>> +}
> 
> You could pass a non-zero value here if you want to test the delay.

udelay is called and because there is missing check for 0 value it does timer 
reading once. Don't think that make sense to delay tests.

Thanks,
Michal

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

[Simon Glass]

Hi Michal,

On Wed, 13 May 2026 at 02:53, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 5/7/26 23:11, Simon Glass wrote:
> > Hi Michal,
> >
> > On 2026-05-05T12:30:28, 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   |  3 ++
> >>   drivers/reset/sandbox-reset-test.c | 14 ++++++++
> >>   drivers/reset/sandbox-reset.c      | 31 ++++++++++++++++++
> >>   test/dm/reset.c                    | 67 ++++++++++++++++++++++++++++++++++++++
> >>   4 files changed, 115 insertions(+)
> >
> >> diff --git a/drivers/reset/sandbox-reset.c b/drivers/reset/sandbox-reset.c
> >> @@ -66,6 +69,21 @@ static int sandbox_reset_deassert(struct reset_ctl *reset_ctl)
> >>        return 0;
> >>   }
> >>
> >> +static int sandbox_reset_reset(struct reset_ctl *reset_ctl, ulong delay_us)
> >> +{
> >> +     struct sandbox_reset *sbr = dev_get_priv(reset_ctl->dev);
> >> +
> >> +     debug("%s(reset_ctl=%p, delay_us=%lu)\n", __func__, reset_ctl,
> >> +           delay_us);
> >> +
> >> +     sbr->signals[reset_ctl->id].asserted = true;
> >> +     udelay(delay_us);
> >> +     sbr->signals[reset_ctl->id].asserted = false;
> >> +     sbr->signals[reset_ctl->id].reset_count++;
> >> +
> >> +     return 0;
> >> +}
> >
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> >
> > Some optional nits / thoughts below.
> >
> > The commit message says the tests exercise the fallback path since the
> > sandbox reset driver doesn't have rst_reset op, this patch adds that
> > method below - so the commit message could use an update.
>
> Will update.
>
> >
> > If you want coverage for the fallback you could add a second
> > sandbox-reset driver without rst_reset, or hack the rest to clear and
> > restart ops->rst_reset,
> >
> >> 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, 0);
> >> +}
> >> +
> >> +int sandbox_reset_test_reset_bulk(struct udevice *dev)
> >> +{
> >> +     struct sandbox_reset_test *sbrt = dev_get_priv(dev);
> >> +
> >> +     return reset_reset_bulk(sbrt->bulkp, 0);
> >> +}
> >
> > You could pass a non-zero value here if you want to test the delay.
>
> udelay is called and because there is missing check for 0 value it does timer
> reading once. Don't think that make sense to delay tests.

We try to avoid delays in tests, although 10us wouldn't matter. We do
have timer_test_add_offset() but I don't think it helps with udelay()

Regards,
Simon

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

[Michal Simek]

On 5/13/26 16:47, Simon Glass wrote:
> Hi Michal,
> 
> On Wed, 13 May 2026 at 02:53, Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 5/7/26 23:11, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On 2026-05-05T12:30:28, 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   |  3 ++
>>>>    drivers/reset/sandbox-reset-test.c | 14 ++++++++
>>>>    drivers/reset/sandbox-reset.c      | 31 ++++++++++++++++++
>>>>    test/dm/reset.c                    | 67 ++++++++++++++++++++++++++++++++++++++
>>>>    4 files changed, 115 insertions(+)
>>>
>>>> diff --git a/drivers/reset/sandbox-reset.c b/drivers/reset/sandbox-reset.c
>>>> @@ -66,6 +69,21 @@ static int sandbox_reset_deassert(struct reset_ctl *reset_ctl)
>>>>         return 0;
>>>>    }
>>>>
>>>> +static int sandbox_reset_reset(struct reset_ctl *reset_ctl, ulong delay_us)
>>>> +{
>>>> +     struct sandbox_reset *sbr = dev_get_priv(reset_ctl->dev);
>>>> +
>>>> +     debug("%s(reset_ctl=%p, delay_us=%lu)\n", __func__, reset_ctl,
>>>> +           delay_us);
>>>> +
>>>> +     sbr->signals[reset_ctl->id].asserted = true;
>>>> +     udelay(delay_us);
>>>> +     sbr->signals[reset_ctl->id].asserted = false;
>>>> +     sbr->signals[reset_ctl->id].reset_count++;
>>>> +
>>>> +     return 0;
>>>> +}
>>>
>>> Reviewed-by: Simon Glass <sjg@chromium.org>
>>>
>>> Some optional nits / thoughts below.
>>>
>>> The commit message says the tests exercise the fallback path since the
>>> sandbox reset driver doesn't have rst_reset op, this patch adds that
>>> method below - so the commit message could use an update.
>>
>> Will update.
>>
>>>
>>> If you want coverage for the fallback you could add a second
>>> sandbox-reset driver without rst_reset, or hack the rest to clear and
>>> restart ops->rst_reset,
>>>
>>>> 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, 0);
>>>> +}
>>>> +
>>>> +int sandbox_reset_test_reset_bulk(struct udevice *dev)
>>>> +{
>>>> +     struct sandbox_reset_test *sbrt = dev_get_priv(dev);
>>>> +
>>>> +     return reset_reset_bulk(sbrt->bulkp, 0);
>>>> +}
>>>
>>> You could pass a non-zero value here if you want to test the delay.
>>
>> udelay is called and because there is missing check for 0 value it does timer
>> reading once. Don't think that make sense to delay tests.
> 
> We try to avoid delays in tests, although 10us wouldn't matter. We do
> have timer_test_add_offset() but I don't think it helps with udelay()

I have created new version and also test fallback which has 1us delay there.
Please take a look at that new patch and this part should be covered.

M

[PATCH v2 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>
Reviewed-by: Simon Glass <sjg@chromium.org>
---

Changes in v2:
- Pass 10us via parameter

 drivers/spi/cadence_qspi.c | 16 ++++------------
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 2a4a49c5f1cf..984d4a39ded4 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -31,6 +31,8 @@
 #define CQSPI_DISABLE_STIG_MODE		BIT(0)
 #define CQSPI_DMA_MODE			BIT(1)
 
+#define CQSPI_RESET_DELAY_US		10
+
 __weak int cadence_qspi_apb_dma_read(struct cadence_spi_priv *priv,
 				     const struct spi_mem_op *op)
 {
@@ -256,19 +258,9 @@ 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);
+		ret = reset_reset_bulk(priv->resets, CQSPI_RESET_DELAY_US);
 		if (ret) {
-			dev_err(bus, "Failed to deassert OSPI reset: %d\n", ret);
+			dev_err(bus, "Failed to reset OSPI: %d\n", ret);
 			return ret;
 		}
 	}
-- 
2.43.0

[PATCH v2 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>
Reviewed-by: Simon Glass <sjg@chromium.org>
---

(no changes since v1)

 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..2b58f3a75b42 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, ulong delay_us)
+{
+	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