[PATCH v3 3/5] reset: sandbox: Cover reset_reset() fallback with second sandbox provider

[Simon Glass]

Hi Michal,

On 2026-05-13T09:42:05, Michal Simek <michal.simek at amd.com> wrote:
> reset: sandbox: Cover reset_reset() fallback with second sandbox provider
>
> Add a sandbox reset controller compatible string
> 'sandbox,reset-ctl-fallback-only' that reuses the existing sandbox assert,
> deassert, request, and free helpers but omits rst_reset. That forces
> reset_reset() through the core assert / udelay / deassert fallback.
>
> Extend the reset-ctl-test DT node with a fifth reset line named 'fallback'
> that points at the new provider, and add dm_test_reset_reset_fallback_path
> which verifies sandbox_reset_get_count() stays zero (rst_reset is never
> invoked) while the line ends deasserted after reset_reset().
>
> This complements the existing rst_reset coverage on sandbox,reset-ctl and
> matches the approach of using a separate controller to exercise the
> fallback path in unit tests.
>
> Signed-off-by: Michal Simek <michal.simek at amd.com>
>
> arch/sandbox/dts/test.dts     | 10 ++++++++--
>  drivers/reset/sandbox-reset.c | 27 +++++++++++++++++++++++++++
>  test/dm/reset.c               | 35 +++++++++++++++++++++++++++++++++++
>  3 files changed, 70 insertions(+), 2 deletions(-)

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

> diff --git a/test/dm/reset.c b/test/dm/reset.c
> @@ -151,6 +154,38 @@ static int dm_test_reset_reset(struct unit_test_state *uts)
> +     ut_asserteq(0, sandbox_reset_query(dev_reset_fb, FALLBACK_RESET_ID));
> +     ut_asserteq(0, sandbox_reset_get_count(dev_reset_fb, FALLBACK_RESET_ID));
> +
> +     ut_assertok(uclass_get_device_by_name(UCLASS_MISC, 'reset-ctl-test',
> +                                           &dev_test));
> +     ut_assertok(reset_get_by_name(dev_test, 'fallback', &ctl));
> +     ut_asserteq_ptr(ctl.dev, dev_reset_fb);
> +     ut_asserteq(ctl.id, FALLBACK_RESET_ID);
> +
> +     ut_assertok(reset_reset(&ctl, 1));
> +     ut_asserteq(0, sandbox_reset_get_count(dev_reset_fb, FALLBACK_RESET_ID));
> +     ut_asserteq(0, sandbox_reset_query(dev_reset_fb, FALLBACK_RESET_ID));

The line starts and ends deasserted, so this only proves rst_reset()
was not invoked, not that the fallback pulsed the line. An
implementation where reset_reset() returns 0 without doing anything
would still pass.

You could reset_assert() first, check the line reads asserted, then
call reset_reset() and verify it comes back deasserted. That mirrors
dm_test_reset_reset() from patch 2 and actually exercises the assert /
udelay / deassert sequence.

> +     ut_asserteq_ptr(ctl.dev, dev_reset_fb);
> +     ut_asserteq(ctl.id, FALLBACK_RESET_ID);

ut_asserteq() takes (expected, actual), so this should be
ut_asserteq(FALLBACK_RESET_ID, ctl.id).

Regards,
Simon