From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [Automated-testing] [PATCH 1/2] tst_test: Add support for device discovery
Date: Wed, 24 Jun 2020 11:29:40 +0200 [thread overview]
Message-ID: <20200624092940.GA30917@yuki.lan> (raw)
In-Reply-To: <adafab63-4390-a4a3-b3aa-923b31d5ac37@xilinx.com>
Hi!
> >> Not exactly sure how LTP handles this in general but I think it makes
> >> sense to extend your test (txt_test) parameters to pass TX/RX channel
> >> via parameters directly to test.
> >>
> >> Something like this
> >> uart01_115200 uart01 -b 115200 -t /dev/ttyXX0 -r /dev/ttyXX1
> >
> > You can pass them in an environment variables. If UART_TX and UART_RX
> > are set the device discovery is not attempted at all and the test just
> > uses these.
> >
> > If they are not the script is executed and the test loops over the
> > result(s). It would be more complicated if the devices were passed over
> > command line parameters since we would have to re-execute the binary.
>
> I didn't run LTP for quite a long time myself but on xilinx devices you
> have 3 different uart instances which you can wire: cadence uart (or
> pl011), ns16550 and uartlite.
> That means with the same hw design you should be able to to test
> cadence<=>ns16550 and ns16550<=>uartlite. It means you need to exchange
> variables in the middle of testing.
The whole point of the script is that it returns one configuration per
line and the test then loops over these, which is a bit more flexible
than runtest files.
> Not sure if this is supported but I would simply generate runtest
> description based on information I got from device discovery.
> But I am far from testing at this stage.
The direction I would like to take in the long term is to slowly get rid
of runtest files and replace them with database that would be used by
the test execution framework to execute tests. There are too many
limitations that are imposed by runtest files, which in the end shape
the ways we think about tests. We should have get rid of these long time
ago...
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2020-06-24 9:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 11:28 [LTP] [PATCH 0/2] [RFC] Device discovery & UART test Cyril Hrubis
2020-06-23 11:28 ` [LTP] [PATCH 1/2] tst_test: Add support for device discovery Cyril Hrubis
2020-06-24 8:41 ` [LTP] [Automated-testing] " Michal Simek
2020-06-24 9:05 ` Cyril Hrubis
2020-06-24 9:21 ` Michal Simek
2020-06-24 9:29 ` Cyril Hrubis [this message]
2020-06-24 9:57 ` Cixi Geng
2020-06-24 10:10 ` Cyril Hrubis
2020-06-24 10:53 ` Michal Simek
2020-06-24 18:16 ` [LTP] " Carlos Hernandez
2020-06-25 12:34 ` Cyril Hrubis
2020-06-23 11:28 ` [LTP] [PATCH 2/2] device_drivers/uart01: Add uart01 test Cyril Hrubis
2020-06-24 9:07 ` [LTP] [Automated-testing] " 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=20200624092940.GA30917@yuki.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/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