From: Michal Simek <michal.simek@amd.com>
To: Simon Glass <sjg@chromium.org>
Cc: u-boot@lists.denx.de, git@amd.com
Subject: Re: [PATCH v2 2/4] reset: Add sandbox tests for reset_reset() and reset_reset_bulk()
Date: Wed, 13 May 2026 10:52:53 +0200 [thread overview]
Message-ID: <cbadd601-4337-4eaf-bf6b-8c98645dc089@amd.com> (raw)
In-Reply-To: <CAFLszTiYJU028+L40rzNa=X-qqDYCfbPqYMfGhzpK3Xq2mr8ag@mail.gmail.com>
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
next prev parent reply other threads:[~2026-05-13 8:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 12:30 [PATCH v2 0/4] reset: Introduce reset_reset.*() API Michal Simek
2026-05-05 12:30 ` [PATCH v2 1/4] reset: Add reset_reset() and reset_reset_bulk() API Michal Simek
2026-05-07 21:11 ` Simon Glass
2026-05-13 8:25 ` Michal Simek
2026-05-15 14:10 ` Simon Glass
2026-05-05 12:30 ` [PATCH v2 2/4] reset: Add sandbox tests for reset_reset() and reset_reset_bulk() Michal Simek
2026-05-07 21:11 ` Simon Glass
2026-05-13 8:52 ` Michal Simek [this message]
2026-05-13 14:47 ` Simon Glass
2026-05-13 15:14 ` Michal Simek
2026-05-05 12:30 ` [PATCH v2 3/4] spi: cadence: Use reset_reset_bulk() for proper reset cycling Michal Simek
2026-05-05 12:30 ` [PATCH v2 4/4] reset: zynqmp: Implement rst_reset using PM_RESET_ACTION_PULSE Michal Simek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cbadd601-4337-4eaf-bf6b-8c98645dc089@amd.com \
--to=michal.simek@amd.com \
--cc=git@amd.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox