2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-22 20:23:57 +08:00
Commit Graph

8 Commits

Author SHA1 Message Date
Luis R. Rodriguez
c92316bf8e test_firmware: add batched firmware tests
The firmware API has a feature to enable batching requests for the same fil
e under one worker, so only one lookup is done. This only triggers if we so
happen to schedule two lookups for same file around the same time, or if
release_firmware() has not been called for a successful firmware call. This
can happen for instance if you happen to have multiple devices and one
device driver for certain drivers where the stars line up scheduling
wise.

This adds a new sync and async test trigger. Instead of adding a new
trigger for each new test type we make the tests a bit configurable so that
we could configure the tests in userspace and just kick a test through a
few basic triggers. With this, for instance the two types of sync requests:

  o request_firmware() and
  o request_firmware_direct()

can be modified with a knob. Likewise the two type of async requests:

   o request_firmware_nowait(uevent=true) and
   o request_firmware_nowait(uevent=false)

can be configured with another knob. The call request_firmware_into_buf()
has no users... yet.

The old tests are left in place as-is given they serve a few other purposes
which we are currently not interested in also testing yet. This will change
later as we will be able to just consolidate all tests under a few basic
triggers with just one general configuration setup.

We perform two types of tests, one for where the file is present and one
for where the file is not present. All test tests go tested and they now
pass for the following 3 kernel builds possible for the firmware API:

0. Most distro setup:
   CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
   CONFIG_FW_LOADER_USER_HELPER=y
1. Android:
   CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
   CONFIG_FW_LOADER_USER_HELPER=y
2. Rare build:
   CONFIG_FW_LOADER_USER_HELPER_FALLBACK=n
   CONFIG_FW_LOADER_USER_HELPER=n

Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-10 13:58:41 -07:00
Luis R. Rodriguez
061132d2b9 test_firmware: add test custom fallback trigger
We have no custom fallback mechanism test interface. Provide one.
This tests both the custom fallback mechanism and cancelling the
it.

Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-25 11:52:34 +01:00
Luis R. Rodriguez
083a93b0c1 test_firmware: use device attribute groups
This simplifies init and exit.

Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-25 11:52:34 +01:00
Luis R. Rodriguez
67fd553ce0 test_firmware: move misc_device down
This will make further changes easier to review.

Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-25 11:52:34 +01:00
Brian Norris
eb910947c8 test: firmware_class: add asynchronous request trigger
We might want to test for bugs like that found in commit f9692b2699
("firmware: fix possible use after free on name on asynchronous
request"), where the asynchronous request API had race conditions.

Let's add a simple file that will launch the async request, then wait
until it's complete and report the status. It's not a true async test
(we're using a mutex + wait_for_completion(), so we can't get more than
one going at the same time), but it does help make sure the basic API is
sane, and it can catch some class of bugs.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2016-01-07 13:44:22 -07:00
Brian Norris
be4a1326d1 test: firmware_class: use kstrndup() where appropriate
We're essentially just doing an open-coded kstrndup(). The only
differences are with what happens after the first '\0' character, but
request_firmware() doesn't care about that.

Suggested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2016-01-07 13:43:28 -07:00
Brian Norris
47e0bbb7fa test: firmware_class: report errors properly on failure
request_firmware() failures currently won't get reported at all (the
error code is discarded). What's more, we get confusing messages, like:

    # echo -n notafile > /sys/devices/virtual/misc/test_firmware/trigger_request
    [ 8280.311856] test_firmware: loading 'notafile'
    [ 8280.317042] test_firmware: load of 'notafile' failed: -2
    [ 8280.322445] test_firmware: loaded: 0
    # echo $?
    0

Report the failures via write() errors, and don't say we "loaded"
anything.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
2016-01-07 13:41:22 -07:00
Kees Cook
0a8adf5847 test: add firmware_class loader test
This provides a simple interface to trigger the firmware_class loader
to test built-in, filesystem, and user helper modes. Additionally adds
tests via the new interface to the selftests tree.

Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-07-17 18:44:19 -07:00