From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
gregkh@linuxfoundation.org, wagi@monom.org, dwmw2@infradead.org,
rafal@milecki.pl, arend.vanspriel@broadcom.com,
rjw@rjwysocki.net, yi1.li@linux.intel.com,
atull@opensource.altera.com, moritz.fischer@ettus.com,
pmladek@suse.com, johannes.berg@intel.com,
emmanuel.grumbach@intel.com, luciano.coelho@intel.com,
kvalo@codeaurora.org, luto@kernel.org, dhowells@redhat.com,
pjones@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 3/5] test: add new driver_data load tester
Date: Thu, 11 May 2017 20:26:29 +0200 [thread overview]
Message-ID: <20170511182629.GY28800@wotan.suse.de> (raw)
In-Reply-To: <20170511104625.GF22134@linaro.org>
On Thu, May 11, 2017 at 07:46:27PM +0900, AKASHI Takahiro wrote:
> On Fri, Apr 28, 2017 at 03:45:35AM +0200, Luis R. Rodriguez wrote:
> > > > diff --git a/tools/testing/selftests/firmware/driver_data.sh b/tools/testing/selftests/firmware/driver_data.sh
> > ...
> >
> > > > +TEST_NAME="driver_data"
> > > > +TEST_DRIVER="test_${TEST_NAME}"
> > > > +TEST_DIR=$(dirname $0)
> > > > +
> > > > +# This represents
> > > > +#
> > > > +# TEST_ID:TEST_COUNT:ENABLED
> > > > +#
> > > > +# TEST_ID: is the test id number
> > > > +# TEST_COUNT: number of times we should run the test
> > > > +# ENABLED: 1 if enabled, 0 otherwise
> > > > +#
> > > > +# Once these are enabled please leave them as-is. Write your own test,
> > > > +# we have tons of space.
> > > > +ALL_TESTS="0001:3:1"
> > > > +ALL_TESTS="$ALL_TESTS 0002:3:1"
> > > > +ALL_TESTS="$ALL_TESTS 0003:3:1"
> > > > +ALL_TESTS="$ALL_TESTS 0004:10:1"
> > > > +ALL_TESTS="$ALL_TESTS 0005:10:1"
> > > > +ALL_TESTS="$ALL_TESTS 0006:10:1"
> > > > +ALL_TESTS="$ALL_TESTS 0007:10:1"
> > > > +ALL_TESTS="$ALL_TESTS 0008:10:1"
> > > > +ALL_TESTS="$ALL_TESTS 0009:10:1"
> > > > +ALL_TESTS="$ALL_TESTS 0010:10:1"
> > > > +ALL_TESTS="$ALL_TESTS 0011:10:1"
> > > > +ALL_TESTS="$ALL_TESTS 0012:1:1"
> > > > +ALL_TESTS="$ALL_TESTS 0013:1:1"
> > >
> > > Do you have good reasons for "the number of times" here?
> >
> > Just that 1 was not enough and more than 10 seemed too much. As is the tests
>
> In my opinion, "1," or "2" given the nature of firmware caching, is good
> enough, but it's up to you.
No, firmware caching deserves its own test unit on its own, but that will be
enabled through a separate test once we move DRIVER_DATA_PRIV_REQ_NO_CACHE
to DRIVER_DATA_REQ_NO_CACHE (a private feature to a publicly available
enabled feature). This will be enabled for the upcoming work which enables
FGPA firmware upload which will first enable request_firmware_into_buf()
through the driver data API which uses this.
> BTW, firmware caching is a bit annoying in my signature tests
> because caching will bypass the verification checks when we iterates
> tests with different conditions.
It would seems to make sense to me to only need to verify files when read
for the first time, once its cache I don't see why we would re-verify them ?
> > are rather simple compared to what we can do given the flexibility in how we
> > can perform tests due to the test driver structure, in the future this will
> > become more important. But best to just get in the basics before we hammer and
> > expand on this a lot. There is also the question of sharing this sort of logic
> > with the upper testing layers so that they deal with this and not us
> > (tools/testing/selftests/), in that sense all this is just sufficient for us to do
> > our own testing for now, but we may and should consider how to get the upper
> > layers to deal this for us. But we can address this later.
> >
> > > > +# Not yet sure how to automate suspend test well yet. For now we expect a
> > > > +# manual run. If using qemu you can resume a guest using something like the
> > > > +# following on the monitor pts.
> > > > +# system_wakeupakeup | socat - /dev/pts/7,raw,echo=0,crnl
> > > > +#ALL_TESTS="$ALL_TESTS 0014:0:1"
> > > > +
> > > > +test_modprobe()
> > > > +{
> > > > + if [ ! -d $DIR ]; then
> > > > + echo "$0: $DIR not present" >&2
> > > > + echo "You must have the following enabled in your kernel:" >&2
> > > > + cat $TEST_DIR/config >&2
> > > > + exit 1
> > > > + fi
> > > > +}
> > > > +
> > > > +function allow_user_defaults()
> > > > +{
> > > > + if [ -z $DEFAULT_NUM_TESTS ]; then
> > > > + DEFAULT_NUM_TESTS=50
> > > > + fi
> > > > +
> > > > + if [ -z $FW_SYSFSPATH ]; then
> > > > + FW_SYSFSPATH="/sys/module/firmware_class/parameters/path"
> > > > + fi
> > > > +
> > > > + if [ -z $OLD_FWPATH ]; then
> > > > + OLD_FWPATH=$(cat $FW_SYSFSPATH)
> > > > + fi
> > > > +
> > > > + if [ -z $FWPATH]; then
> > > > + FWPATH=$(mktemp -d)
> > > > + fi
> > > > +
> > > > + if [ -z $DEFAULT_DRIVER_DATA ]; then
> > > > + config_reset
> > > > + DEFAULT_DRIVER_DATA=$(config_get_name)
> > > > + fi
> > > > +
> > > > + if [ -z $FW ]; then
> > > > + FW="$FWPATH/$DEFAULT_DRIVER_DATA"
> > > > + fi
> > > > +
> > > > + if [ -z $SYS_STATE_PATH ]; then
> > > > + SYS_STATE_PATH="/sys/power/state"
> > > > + fi
> > > > +
> > > > + # Set the kernel search path.
> > > > + echo -n "$FWPATH" > $FW_SYSFSPATH
> > > > +
> > > > + # This is an unlikely real-world firmware content. :)
> > > > + echo "ABCD0123" >"$FW"
> > >
> > > Do you always want to overwrite the firmware even if user explicitly
> > > provides it?
> >
> > This is a test script so it constructs its own temporary path so it can
> > have the confidence to overwrite anything it pleases. So in this case yes.
> > Its just as the old firmware test script.
>
> Right, but looking into the script, even if an user supplies a firmware
> blob, the script overwrites it unnecessarily.
FWPATH=$(mktemp -d)
...
FW="$FWPATH/$DEFAULT_DRIVER_DATA"
...
echo "ABCD0123" >"$FW"
So this is really just touching the custom path stuff, unless of course the
caller overrides the above variables, in which case its trusted they know what
they are doing, ie custom test cases / setup / system. That was the goal.
> This may also be inconvenient if I add signature verification tests.
> (Not sure though.)
You can feel free to modify this as you see fit to account for firmware
signing. If you run into issues please feel free to make adjustments.
> > > > +usage()
> > > > +{
> > > > + NUM_TESTS=$(grep -o ' ' <<<"$ALL_TESTS" | grep -c .)
> > > > + let NUM_TESTS=$NUM_TESTS+1
> > > > + MAX_TEST=$(printf "%04d\n" $NUM_TESTS)
> > > > + echo "Usage: $0 [ -t <4-number-digit> ] | [ -w <4-number-digit> ] |"
> > > > + echo " [ -s <4-number-digit> ] | [ -c <4-number-digit> <test- count>"
> > > > + echo " [ all ] [ -h | --help ] [ -l ]"
> > > > + echo ""
> > > > + echo "Valid tests: 0001-$MAX_TEST"
> > > > + echo ""
> > > > + echo " all Runs all tests (default)"
> > > > + echo " -t Run test ID the number amount of times is recommended"
> > > > + echo " -w Watch test ID run until it runs into an error"
> > > > + echo " -c Run test ID once"
> > >
> > > -> -s
> > >
> > > > + echo " -s Run test ID x test-count number of times"
> > >
> > > -> -c
> >
> > Good thing you highlighted these, I had them flipped, -s was for single run
> > and -c was for test-count number of times.
> >
> > > If you make the second parameter optional, you don't need
> > > -t nor -s:
> > > driver_data.sh -c 0004 ; recommended times
> > > driver_data.sh -c 0004 1 ; only once
> > > driver_data.sh -c 0004 100 ; as many times as you want
> >
> > True but I prefer having short-hand notations as well.
>
> Okay, up to you.
In the end I hope we get rid of all this anyway and replace it with
a centralized way for selftests but IMHO this is a secondary step.
Luis
next prev parent reply other threads:[~2017-05-11 18:26 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-30 3:25 [PATCH v6 0/5] firmware: add driver data API Luis R. Rodriguez
2017-03-30 3:25 ` [PATCH v6 1/5] firmware: add extensible driver data params Luis R. Rodriguez
2017-04-06 7:26 ` Luca Coelho
2017-04-27 2:05 ` Luis R. Rodriguez
2017-03-30 3:25 ` [PATCH v6 2/5] firmware: add extensible driver data API Luis R. Rodriguez
2017-04-10 12:42 ` Coelho, Luciano
2017-04-11 8:01 ` takahiro.akashi
2017-04-27 3:23 ` Luis R. Rodriguez
2017-04-27 3:16 ` Luis R. Rodriguez
2017-04-27 5:44 ` Luca Coelho
2017-04-27 8:04 ` Luis R. Rodriguez
2017-04-27 6:09 ` Luca Coelho
2017-04-27 10:31 ` Luis R. Rodriguez
2017-04-13 9:36 ` AKASHI Takahiro
2017-04-28 0:51 ` Luis R. Rodriguez
2017-04-28 3:19 ` AKASHI Takahiro
2017-04-29 4:36 ` Luis R. Rodriguez
2017-03-30 3:25 ` [PATCH v6 3/5] test: add new driver_data load tester Luis R. Rodriguez
2017-04-11 8:32 ` AKASHI Takahiro
2017-04-28 1:45 ` Luis R. Rodriguez
2017-05-11 10:46 ` AKASHI Takahiro
2017-05-11 17:11 ` Luis R. Rodriguez
2017-05-17 22:45 ` Li, Yi
2017-05-19 18:31 ` Luis R. Rodriguez
2017-05-11 18:12 ` Luis R. Rodriguez
2017-05-11 18:26 ` Luis R. Rodriguez [this message]
2017-05-11 18:32 ` Luis R. Rodriguez
2017-05-12 0:28 ` AKASHI Takahiro
2017-05-12 15:59 ` Luis R. Rodriguez
2017-05-17 9:08 ` AKASHI Takahiro
2017-05-17 15:38 ` Luis R. Rodriguez
2017-05-12 0:20 ` AKASHI Takahiro
2017-05-12 15:52 ` Luis R. Rodriguez
2017-05-13 18:46 ` Luis R. Rodriguez
2017-03-30 3:25 ` [PATCH v6 4/5] iwlwifi: convert to use driver data API Luis R. Rodriguez
2017-04-10 13:19 ` Luca Coelho
2017-04-28 0:56 ` Luis R. Rodriguez
2017-04-28 12:17 ` Luca Coelho
2017-03-30 3:25 ` [PATCH v6 5/5] brcmfmac: don't warn user if requested nvram fails Luis R. Rodriguez
2017-04-27 0:49 ` Luis R. Rodriguez
2017-05-02 8:49 ` [PATCH v7 0/5] firmware: add driver data API Luis R. Rodriguez
2017-05-02 8:49 ` [PATCH v7 1/5] firmware: add extensible driver data params Luis R. Rodriguez
2017-05-11 18:17 ` Li, Yi
2017-05-11 18:28 ` Luis R. Rodriguez
2017-05-02 8:49 ` [PATCH v7 2/5] firmware: add extensible driver data API Luis R. Rodriguez
2017-05-02 8:49 ` [PATCH v7 3/5] test: add new driver_data load tester Luis R. Rodriguez
2017-05-11 10:10 ` AKASHI Takahiro
2017-05-11 17:00 ` Luis R. Rodriguez
2017-05-15 18:23 ` [PATCH v8] " Luis R. Rodriguez
2017-05-02 8:49 ` [PATCH v7 4/5] firmware: document the extensible driver data API Luis R. Rodriguez
2017-05-02 8:49 ` [PATCH v7 5/5] iwlwifi: convert to use " Luis R. Rodriguez
2017-05-19 19:10 ` [PATCH v8 0/5] firmware: add " Luis R. Rodriguez
2017-05-19 19:10 ` [PATCH v8 1/5] firmware: add extensible driver data params Luis R. Rodriguez
2017-05-19 19:10 ` [PATCH v8 2/5] firmware: add extensible driver data API Luis R. Rodriguez
2017-05-19 19:10 ` [PATCH v8 3/5] test: add new driver_data load tester Luis R. Rodriguez
2017-05-19 19:10 ` [PATCH v8 4/5] firmware: document the extensible driver data API Luis R. Rodriguez
2017-05-19 19:10 ` [PATCH v8 5/5] iwlwifi: convert to use " Luis R. Rodriguez
2017-06-05 21:33 ` [PATCH v8 0/5] firmware: add " Luis R. Rodriguez
2017-06-05 21:39 ` [PATCH v9 " Luis R. Rodriguez
2017-06-05 21:39 ` [PATCH v9 1/5] firmware: add extensible driver data params Luis R. Rodriguez
2017-06-13 9:05 ` Greg KH
2017-06-13 10:31 ` Rafał Miłecki
2017-06-13 13:17 ` Greg KH
2017-06-13 14:12 ` Rafał Miłecki
2017-06-13 15:32 ` Luis R. Rodriguez
2017-06-13 15:50 ` Greg KH
2017-06-13 19:40 ` Luis R. Rodriguez
2017-06-14 15:57 ` Li, Yi
2017-06-17 19:38 ` Greg KH
2017-06-19 7:33 ` Johannes Berg
2017-06-19 19:41 ` Luis R. Rodriguez
2017-06-20 1:26 ` AKASHI Takahiro
2017-06-19 19:35 ` Luis R. Rodriguez
2017-06-23 15:51 ` Greg KH
2017-06-23 22:43 ` Luis R. Rodriguez
2017-06-23 23:09 ` Linus Torvalds
2017-06-24 0:48 ` Luis R. Rodriguez
2017-06-24 12:39 ` Greg KH
2017-06-26 17:33 ` Luis R. Rodriguez
2017-06-26 18:19 ` Rafał Miłecki
2017-06-26 21:29 ` Luis R. Rodriguez
2017-06-27 2:28 ` Vikram Mulukutla
2017-06-27 17:25 ` Luis R. Rodriguez
2017-06-24 12:40 ` Greg KH
2017-06-26 15:50 ` Luis R. Rodriguez
2017-06-23 15:59 ` Greg KH
2017-06-23 22:47 ` Luis R. Rodriguez
2017-06-19 22:51 ` Li, Yi
2017-06-20 1:48 ` AKASHI Takahiro
2017-06-20 15:20 ` Li, Yi
2017-06-20 16:27 ` Vikram Mulukutla
2017-06-20 17:22 ` Luis R. Rodriguez
2017-06-21 0:49 ` AKASHI Takahiro
2017-06-23 16:33 ` Luis R. Rodriguez
2017-06-05 21:39 ` [PATCH v9 2/5] firmware: add extensible driver data API Luis R. Rodriguez
2017-06-05 21:39 ` [PATCH v9 3/5] test: add new driver_data load tester Luis R. Rodriguez
2017-06-05 21:39 ` [PATCH v9 4/5] firmware: document the extensible driver data API Luis R. Rodriguez
2017-06-05 21:39 ` [PATCH v9 5/5] iwlwifi: convert to use " Luis R. Rodriguez
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=20170511182629.GY28800@wotan.suse.de \
--to=mcgrof@suse.com \
--cc=arend.vanspriel@broadcom.com \
--cc=atull@opensource.altera.com \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=emmanuel.grumbach@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=johannes.berg@intel.com \
--cc=kvalo@codeaurora.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luciano.coelho@intel.com \
--cc=luto@kernel.org \
--cc=mcgrof@kernel.org \
--cc=moritz.fischer@ettus.com \
--cc=pjones@redhat.com \
--cc=pmladek@suse.com \
--cc=rafal@milecki.pl \
--cc=rjw@rjwysocki.net \
--cc=takahiro.akashi@linaro.org \
--cc=wagi@monom.org \
--cc=yi1.li@linux.intel.com \
/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
Powered by JetHome