All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2] uart: add uart testcase in kernel device-drivers
Date: Thu, 26 Mar 2020 08:05:55 +0100	[thread overview]
Message-ID: <20200326070555.GA17560@dell5510> (raw)
In-Reply-To: <CAF12kFv0P4yTVVf-pfXOai8+3urEiWug_dbnTfAXpyfOvzi2ug@mail.gmail.com>

Hi Cixi,

> >We both Cyril and me mentioned that you don't need to use mktemp (+ it'd be
> >unnecessary dependency).
> Now I knew  TST_NEEDS_TMPDIR  is make a temp direct and cd in it ,
> but I need a file contains random data, this file is to used to test the
> PORT,
> Do you meaning I should creat a normal file use dd ,and named by myself?
Yes. We do not care about test concurrency of the same test (i.e. the same test
run more times simultaneously). And even if we care it could be solved by adding $$ -
PID, i.e.: foo.$$ (but you don't need to).
BTW I wrote it in https://lists.linux.it/pipermail/ltp/2020-March/016107.html

> >> This is problematic as well, it expects that all ports that are not
> >> in-use are loopback connected. This is not true in general case, which
> >> means that we cannot add the test to the kernel_misc runtest file as it
> >> is because it will fail on most of the systems out there.
> >Oh, I didn't realize this obvious thing.
> >> We will have to figure out how to pass which ports are interconnected to
> >> the test somehow, because that is something that only the user who set
> >> up the machine knows.
> >Maybe expect user sets it in some variable before running the test? e.g.:
> we can decide  which PORT can be test,  But just like Cyril said, we don't
> know the machines is run int loopback mode or  HW flow control  mode,
> So can I put the testcase tags into two file in the runtest, one is used to
> test
> loopback mode, and the other is test for   HW flow control  ?
> runtest/uart-loopback
> runtest/uart-HWflow

Wouldn't it help this below?
> > Maybe expect user sets it in some variable before running the test? e.g.:

> > if [ -n "$UART_INTERCONNECTED_PORTS" ]; then
> >     tst_brk TCONF "set space separated interconnected ports in
> > \$UART_INTERCONNECTED_PORTS"
> > fi

Kind regards,
Petr

  reply	other threads:[~2020-03-26  7:05 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24 12:17 [LTP] [PATCH v2] uart: add uart testcase in kernel device-drivers gengcixi
2020-03-25 10:28 ` Cyril Hrubis
2020-03-25 10:33   ` Cyril Hrubis
2020-03-25 15:28   ` Petr Vorel
2020-03-26  6:35     ` Cixi Geng
2020-03-26  7:05       ` Petr Vorel [this message]
2020-03-27  2:44         ` Cixi Geng
2020-03-27 14:13           ` Cyril Hrubis
2020-03-25 15:24 ` Petr Vorel

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=20200326070555.GA17560@dell5510 \
    --to=pvorel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.