| /Documentation/dev-tools/kunit/ |
| D | usage.rst | 6 Test Cases
9 The fundamental unit in KUnit is the test case. A test case is a function with
10 the signature ``void (*)(struct kunit *test)``. It calls the function under test
15 void example_test_success(struct kunit *test)
19 void example_test_failure(struct kunit *test)
21 KUNIT_FAIL(test, "This test never passes.");
27 which is a special expectation that logs a message and causes the test case to
33 test. An expectation is called like a function. A test is made by setting
34 expectations about the behavior of a piece of code under test. When one or more
35 expectations fail, the test case fails and information about the failure is
[all …]
|
| D | style.rst | 4 Test Style and Nomenclature
23 To make tests easy to find, they are grouped into suites and subsystems. A test
24 suite is a group of tests which test a related area of the kernel. A subsystem
25 is a set of test suites which test different parts of a kernel subsystem
31 Every test suite must belong to a subsystem. A subsystem is a collection of one
32 or more KUnit test suites which test the same driver or part of the kernel. A
33 test subsystem should match a single kernel module. If the code being tested
38 Test subsystems should be named after the code being tested, either after the
39 module (wherever possible), or after the directory or files being tested. Test
42 If a test subsystem name has multiple components, they should be separated by
[all …]
|
| D | faq.rst | 12 A `unit test <https://martinfowler.com/bliki/UnitTest.html>`_ is supposed to
13 test a single unit of code in isolation and hence the name *unit test*. A unit
14 test should be the finest granularity of testing and should allow all possible
15 code paths to be tested in the code under test. This is only possible if the
16 code under test is small and does not have any external dependencies outside of
17 the test's control like hardware.
20 require installing the kernel on a test machine or in a virtual machine. All
22 kernel under test. This is true for Autotest, kselftest, and some others,
44 What is the difference between a unit test and other kinds of tests?
47 test, or an end-to-end test.
[all …]
|
| D | index.rst | 23 test execution support has been disabled. In addition, in order
37 of test cases called test suites. The tests either run on kernel boot
39 failed test cases in the kernel log. The test results appear in
40 :doc:`KTAP (Kernel - Test Anything Protocol) format</dev-tools/ktap>`.
45 language, and test parts of the Kernel implementation (example: a C
48 KUnit can test any kernel component, for example: file system, system
51 KUnit follows the white-box testing approach. The test has access to
58 parses the test results and
66 - Runs a test in milliseconds.
72 - For Kernel under test, Linux kernel version 5.5 or greater.
[all …]
|
| D | architecture.rst | 10 - `kunit_tool (Command-line Test Harness)`_
20 - Reports test results
21 - Provides test utilities
23 Test Cases
26 The test case is the fundamental unit in KUnit. KUnit test cases are organised
27 into suites. A KUnit test case is a function with type signature
28 ``void (*)(struct kunit *test)``. These test case functions are wrapped in a
34 Each KUnit test case receives a ``struct kunit`` context object that tracks a
35 running test. The KUnit assertion macros and other KUnit utilities use the
38 - ``->priv``: The setup functions can use it to store arbitrary test
[all …]
|
| D | start.rst | 8 teaching how to run existing tests and then how to write a simple test case,
19 tests, and formats the test results. From the kernel repository, you
97 For example, to include the kernel's linked-list test you can run::
128 separator between the name of the test suite and the test case,
129 otherwise, it will be interpreted as the name of the test suite.
132 a. inform the name of a test suite, like ``"kunit_executor_test"``,
133 to run every test case it contains::
137 b. inform the name of a test case prefixed by its test suite,
138 like ``"example.example_simple_test"``, to run specifically that test case::
142 c. use wildcard characters (``*?[``) to run any test case that matches the pattern,
[all …]
|
| D | running_tips.rst | 147 Currently it's your only option if you want to test on architectures other than
169 Then we'd see output like this in dmesg signaling the test ran and passed:
193 Then after booting into our kernel, we can run the test via
197 $ modprobe kunit-example-test
202 The ``modprobe`` will *not* have a non-zero exit code if any test
209 most test authors won't think about.
216 You can use ``kunit.py parse`` to parse dmesg for test output and print out
242 $ modprobe kunit-example-test > /dev/null
247 $ modprobe -r kunit-example-test
262 # Reset coverage counters before running the test.
[all …]
|
| /Documentation/devicetree/bindings/sound/ |
| D | test-component.yaml | 4 $id: http://devicetree.org/schemas/sound/test-component.yaml#
7 title: Test Component
15 - test-cpu
16 - test-cpu-verbose
17 - test-cpu-verbose-dai
18 - test-cpu-verbose-component
19 - test-codec
20 - test-codec-verbose
21 - test-codec-verbose-dai
22 - test-codec-verbose-component
[all …]
|
| /Documentation/dev-tools/ |
| D | ktap.rst | 4 The Kernel Test Anything Protocol (KTAP), version 1
7 TAP, or the Test Anything Protocol is a format for specifying test results used
9 <https://testanything.org/>`_. The Linux Kernel largely uses TAP output for test
10 results. However, Kernel testing frameworks have special needs for test results
16 KTAP test results describe a series of tests (which may be nested: i.e., test
18 lines -- and a final result. The test structure and results are
25 - Test case result lines
29 information, in particular nested test results, may be lost. Also note that
46 start of the nested test results. This differs from TAP14, which uses a
56 A test plan provides the number of tests (or subtests) in the KTAP output.
[all …]
|
| D | kselftest.rst | 11 from mainline offers the best coverage. Several test rings run mainline
12 kselftest suite on stable releases. The reason is that when a new test
13 gets added to test existing code to regression test a bug, we should be
14 able to run that test on an older kernel. Hence, it is important to keep
15 code that can still test an older kernel and make sure it skips the test
26 in safe mode with a limited scope. In limited mode, cpu-hotplug test is
28 hotplug test is run on 2% of hotplug capable memory instead of 10%.
31 userspace may wish to use the `Test Harness`_. Tests that need to be
32 run in kernel space may wish to use a `Test Module`_.
70 Kselftest supports "summary" option to make it easier to understand the test
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-platform-intel-ifs | 1 Device instance to test mapping
2 intel_ifs_0 -> Scan Test
3 intel_ifs_1 -> Array BIST test
9 Description: Write <cpu#> to trigger IFS test for one online core.
10 Note that the test is per core. The cpu# can be
12 completes the test for the core containing that thread.
13 Example: to test the core containing cpu5: echo 5 >
21 Description: The status of the last test. It can be one of "pass", "fail"
29 Description: Additional information regarding the last test. The details file reports
30 the hex value of the STATUS MSR for this test. Note that the error_code field
[all …]
|
| D | debugfs-scmi | 9 Users: Debugging, any userspace test suite
20 Users: Debugging, any userspace test suite
28 Users: Debugging, any userspace test suite
36 Users: Debugging, any userspace test suite
44 Users: Debugging, any userspace test suite
52 Users: Debugging, any userspace test suite
61 Users: Debugging, any userspace test suite
70 Users: Debugging, any userspace test suite
|
| /Documentation/dev-tools/kunit/api/ |
| D | functionredirection.rst | 11 tested from other parts of the kernel. This ensures the reliability of the test
13 hardware or config options (making the test easier to run), and protects the
14 stability of the rest of the system (making it less likely for test-specific
28 indirection which can use or emulate a separate set of test state. However,
42 It works by adding a macro to the "real" function which checks to see if a test
68 In the event they need to access or modify test-specific state, they can use
79 struct kunit *test = kunit_get_current_test();
80 KUNIT_EXPECT_STREQ(test, str, "Hello World!");
83 3. Activate the static stub from your test.
85 From within a test, the redirection can be enabled with
[all …]
|
| /Documentation/driver-api/dmaengine/ |
| D | dmatest.rst | 2 DMA Test Guide
7 This small document introduces how to test DMA drivers using dmatest module.
15 The dmatest module can be configured to test a specific channel. It can also
16 test multiple channels at the same time, and it can start multiple threads
20 The test suite works only on the channels that have at least one
28 Part 1 - How to build the test module
33 Device Drivers -> DMA Engine support -> DMA Test client
57 Example of multi-channel test usage (new in the 5.0 kernel)::
86 Note that running a new test will not stop any in progress test.
88 The following command returns the state of the test. ::
[all …]
|
| /Documentation/devicetree/ |
| D | of_unittest.rst | 12 This document explains how the test data required for executing OF unittest
21 OF Selftest has been designed to test the interface (include/linux/of.h)
34 of a test or whether there is a real problem that is independent of unittest.
48 3. Test-data
52 the test data required for executing the unit tests automated in
80 3.1. Adding the test data
129 Before executing OF unittest, it is required to attach the test data to
134 __dtb_testcases_begin - address marking the start of test data blob
135 __dtb_testcases_end - address marking the end of test data blob
139 then it attaches the unflattened test data tree to the live tree, else it
[all …]
|
| /Documentation/power/ |
| D | basic-pm-debugging.rst | 18 test at least a couple of times in a row for confidence. [This is necessary,
44 a) Test modes of hibernation
50 core run in a test mode. There are 5 test modes available:
53 - test the freezing of processes
56 - test the freezing of processes and suspending of devices
59 - test the freezing of processes, suspending of devices and platform
63 - test the freezing of processes, suspending of devices, platform
67 - test the freezing of processes, suspending of devices, platform global
77 /sys/power/pm_test (eg. "devices" to test the freezing of processes and
79 to use the "devices" test mode along with the "platform" mode of hibernation,
[all …]
|
| D | drivers-testing.rst | 7 1. Preparing the test system
10 Unfortunately, to effectively test the support for the system-wide suspend and
18 Of course, for this purpose the test system has to be known to suspend and
20 resolve all suspend/resume-related problems in the test system before you start
27 Once you have resolved the suspend/resume-related problems with your test system
28 without the new driver, you are ready to test it:
30 a) Build the driver as a module, load it and try the test modes of hibernation
36 c) Compile the driver directly into the kernel and try the test modes of
42 e) Try the test modes of suspend (see:
|
| /Documentation/admin-guide/aoe/ |
| D | udev-install.sh | 10 if test -z "$conf"; then
11 if test -r /etc/udev/udev.conf; then
15 if test -z "$conf" || test ! -r "$conf"; then
26 if test -z "$rules_d" ; then
29 if test ! -d "$rules_d"; then
|
| /Documentation/translations/zh_CN/devicetree/ |
| D | of_unittest.rst | 108 __dtb_testcases_begin - address marking the start of test data blob
109 __dtb_testcases_end - address marking the end of test data blob
122 test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null
124 test-child01 null null null
164 test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null
166 null null null test-child01
172 聪明的读者会注意到，与先前的结构相比，test-child0节点成为最后一个兄弟姐妹（图2）。
|
| /Documentation/gpu/amdgpu/ |
| D | ras.rst | 46 RAS Basic Test
48 The test verifies the RAS feature enabled status and makes sure the necessary sysfs and debugfs fil…
51 RAS Query Test
53 This test checks the RAS availability and enablement status for each supported IP block as well as
56 RAS Inject Test
58 This test injects errors for each IP.
60 RAS Disable Test
62 This test tests disabling of RAS features for each IP block.
|
| /Documentation/devicetree/bindings/media/i2c/ |
| D | adv7604.yaml | 36 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
37 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
38 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
39 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
40 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
41 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
42 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
43 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
44 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
45 - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ]
[all …]
|
| /Documentation/gpu/ |
| D | vkms.rst | 57 The IGT GPU Tools is a test suite used specifically for debugging and
73 to test. IGT_DEVICE can also be used with the run-test.sh script to run the
76 sudo ./build/tests/<name of test> --device "sys:/sys/devices/platform/vkms"
77 sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/<name of test>
78 sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t <name of test>
80 For example, to test the functionality of the writeback library,
81 we can run the kms_writeback test::
87 You can also run subtests if you do not want to run the entire test::
103 - kms_plane: some test cases are failing due to timeout on capturing CRC;
108 tested with kms_flip test; in some way, we can say that VKMS already mimics
[all …]
|
| /Documentation/i2c/ |
| D | slave-testunit-backend.rst | 9 This backend can be used to trigger test cases for I2C bus masters which
29 0x00 CMD - which test to trigger
30 0x01 DATAL - configuration byte 1 for the test
31 0x02 DATAH - configuration byte 2 for the test
32 0x03 DELAY - delay in n * 10ms until test is started
38 DELAY is a generic parameter which will delay the execution of the test in CMD.
54 This is useful to test if your bus master driver is handling multi-master
56 the bus. If the bus master under test also wants to access the bus at the same
66 This test will send an SMBUS_HOST_NOTIFY message to the host. Note that the
77 This test will respond to a block process call as defined by the SMBus
|
| /Documentation/networking/device_drivers/ethernet/cirrus/ |
| D | cs89x0.rst | 46 5.2.1 Diagnostic Self-Test
47 5.2.2 Diagnostic Network Test
383 the CS8900/20 Setup Utility can be used to test the functionality of the
384 adapter and its network connection. Use the diagnostics 'Self Test' option to
385 test the functionality of the adapter with the hardware configuration you have
386 assigned. You can use the diagnostics 'Network Test' to test the ability of the
406 * Select 'Self-Test' to test the adapter's basic functionality.
407 * Select 'Network Test' to test the network connection and cabling.
410 5.2.1. Diagnostic Self-test
413 The diagnostic self-test checks the adapter's basic functionality as well as
[all …]
|
| /Documentation/litmus-tests/ |
| D | README | 7 For more information about how to "run" a litmus test or how to generate
8 a kernel test module based on a litmus test, please see
16 Test that an atomic RMW followed by a smp_mb__after_atomic() is
21 Test that atomic_set() cannot break the atomicity of atomic RMWs.
|