From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Simon Glass <sjg@chromium.org>
Cc: u-boot@lists.denx.de
Subject: Re: [RFC] make sandbox UT more generic
Date: Thu, 31 Aug 2023 14:28:40 +0900 [thread overview]
Message-ID: <ZPAlCLyi8eB+a6yP@octopus> (raw)
In-Reply-To: <CAPnjgZ32h4vtMiScP-4NKEVFCSYcYHV7=bKVSqT3mQSfDPQ=FA@mail.gmail.com>
Hi Simon,
On Wed, Aug 30, 2023 at 08:49:05PM -0600, Simon Glass wrote:
> Hi,
>
> On Wed, 30 Aug 2023 at 18:38, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> >
> > Hi,
> >
> > I'm working on implementing SCMI-based pinctrl/gpio driver,
> > and want to re-use sandbox UT to test the code. However,
> > It is somehow sandbox-specific (with additional DT nodes).
> > How can/should we make it more generic for other targets/drivers
> > rather than just by copying the test code?
> > (I have already created a test for pinmux since there is only
> > one existing scenario, but gpio test has many.)
> >
> > Even if I say 'generic', my case may be special since real
> > hardware (device drivers) cannot always run all the test cases,
> > while SCMI-based drivers potentially can with a dummy SCMI server
> > for sandbox.
> > See:
> > drivers/firmware/scmi/sandbox-scmi_agent.c
>
> We don't have a good way to test drivers that talk to hardware, in general.
>
> For I2C, SPI and some PCI devices you can sometimes write an emulator
> for the chip and then your driver can talk to the emulator as if it
> were talking to the hardware. Sandbox does actually support that with
> memory-mapped I/O too, although it is fairly rarely used.
Well, I don't want or need to emulate some *real* hardware.
Instead, I would like to emulate what the current sandbox drivers
(pinctrl-sandbox.c and gpio/sandbox.c) emulate so that we can re-use
(some portion of) test cases for sandbox (test/dm/pinmux.c and gpio.c).
As you might know, SCMI protocol with associated drivers on U-Boot is
so generic that it would be able to talk to any of real pinctrl/gpio
drivers/firmware (say, run on OPTEE or SCP).
By implementing/mimicking protocol messages in sandbox-scmi_agent.c,
SCMI drivers are expected to provide *virtual* pinctrl/gpio devices
similar to what sandbox does.
I have already implemented pinmux test with some tweaks by copying
test/dm/pinmux.c and duplicating almost the same DT nodes as "pinctrl-gpio"
in test.dts.
But I'm looking for any other means without test code duplication.
Did I clarify my question a bit?
-Takahiro Akashi
> We have done this a lot with Zephyr, as well[1] and achieved 90% code
> coverage on some boards.
>
> But I'm not quite sure I am answering the right question, so I will stop here.
>
> Regards,
> Simon
>
> [1] https://www.youtube.com/watch?v=usXCAXR2G_c
next prev parent reply other threads:[~2023-08-31 5:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 0:38 [RFC] make sandbox UT more generic AKASHI Takahiro
2023-08-31 2:49 ` Simon Glass
2023-08-31 5:28 ` AKASHI Takahiro [this message]
2023-08-31 15:04 ` Simon Glass
2023-09-06 3:00 ` AKASHI Takahiro
2023-09-07 12:23 ` Simon Glass
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=ZPAlCLyi8eB+a6yP@octopus \
--to=takahiro.akashi@linaro.org \
--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