diff --git a/android/README.md b/android/README.md
index 8445834..4f55d39 100644
--- a/android/README.md
+++ b/android/README.md
@@ -33,12 +33,24 @@
 * `external/ltp/android/ltp_package_list.mk`: Lists all tests that will get pulled into VTS - VTS depends on this list. This file gets auto-generated by android/tools/gen_android_build.sh.
 * `external/ltp/android/tools/disabled_tests.txt`: Lists tests which cannot or should not be compiled for Android. This file is read by gen_android_build.sh during LTP upgrades to produce *.mk files required to build LTP for Android.
 * `external/ltp/testcases`: Source for LTP tests. Among the most important for the purposes of Treble are those in external/ltp/testcases/kernel/syscalls.
-* `test/vts-testcase/kernel/ltp/configs/disabled_tests.py`: Any test listed here will not be run in VTS, either in the staging or stable set, despite being compiled. If a test does not appear here then it at least runs as part of the VtsKernelLtpStaging module.
-* `test/vts-testcase/kernel/ltp/configs/stable_tests.py`: Any test listed here will run as part of the VtsKernelLtp (stable) module.
+* `test/vts-testcase/kernel/ltp/testcase/tools/configs/disabled_tests.py`: Any test listed here will not be run in VTS, despite being compiled.
+* `test/vts-testcase/kernel/ltp/testcase/tools/configs/stable_tests.py`: Any test listed here will run as part of the vts_ltp_test_arm/vts_ltp_test_arm_64 modules.
 
-New tests are run in the staging set for some time (a couple weeks or more) to
-ensure they are reliable prior to their being added to the stable set.
+Running LTP through atest
+-------------------------
+You can run LTP tests with atest, which handles all the setup and build steps.
 
+To run all 32 bit LTP tests:
+* `atest vts_ltp_test_arm`
+
+To run all 64 bit LTP tests:
+* `atest vts_ltp_test_arm_64`
+
+To run a single test:
+* `atest vts_ltp_test_arm:dio.dio13_32bit`
+
+Running LTP through VTS
+-----------------------
 To run VTS LTP it must first be built. VTS is not device specific, you need not
 compile it specifically for the device you wish to run it on, assuming it is
 the same architecture.
@@ -47,33 +59,19 @@
 * `lunch`
 * `make -j vts`
 
-Before running VTS ensure your host has the required prerequisites (this need
-only be done once):
-* `. test/vts/script/setup.sh`
-
 Then open vts-tradefed and run the VTS stable set:
 * `vts-tradefed`
-* `vts-tf > run vts-kernel -m VtsKernelLtp`
+* `vts-tf > run vts-kernel -m vts_ltp_test_arm`
 
 If you regularly work with multiple devices it may be useful to specify the
 specific device you wish to run VTS on via the serial number:
-* `vts-tf > run vts-kernel -m VtsKernelLtp -s 000123456789`
-
-Or we can run the staging set:
-* `vts-tf > run vts-kernel -m VtsKernelLtpStaging`
+* `vts-tf > run vts-kernel -m vts_ltp_test_arm -s 000123456789`
 
 Or a specific test within the stable set:
-* `vts-tf > run vts-kernel -m VtsKernelLtp -t dio.dio13`
+* `vts-tf > run vts-kernel -m vts_ltp_test_arm -t dio.dio13_32bit`
 
-Maybe several:
-* `vts-tf > run vts-kernel -m VtsKernelLtp -t dio.dio13,fs.stream04`
-
-You may choose whether to specify bitness of the tests. This would run 4 tests - dio.dio13
-both 32-bit and 64-bit, fs.stream04 64-bit, and fs.lftest01 32-bit:
-* `vts-tf > run vts-kernel -m VtsKernelLtp -t dio.dio13,fs.stream04_64bit,fs.lftest01_32bit`
-
-Running LTP Faster
-------------------
+Running LTP Directly
+--------------------
 
 Running LTP tests within VTS can be quite cumbersome, especially if you are
 iterating a lot trying to debug something. Build and run LTP tests faster by
@@ -142,12 +140,8 @@
 affect whether the test is built, but rather determines whether it is run at
 all as part of the stable or staging sets.
 
-The file test/vts-testcase/kernel/ltp/configs/stable_tests.py lists tests that
-will run as part of VTS stable (VtsKernelLtp). The
-test/vts-testcase/kernel/ltp/configs/disabled_tests.py file lists tests that
-are runtime disabled in VTS. If a test is not listed in either of these files,
-but is enabled in the build in external/ltp, then it is in the staging set
-(VtsKernelLtpStaging).
+The file test/vts-testcase/kernel/ltp/testcase/tools/configs/stable_tests.py
+lists tests that will run as part of VTS (vts_ltp_test_arm/vts_ltp_test_arm_64).
 
 When a test is enabled for the first time in VTS it should be in the staging
 set. The behavior of the test will be observed over a period of time and ensure
@@ -164,14 +158,11 @@
 and test-timeout parameters to VTS in
 `test/vts-testcase/kernel/ltp/stable/AndroidTest.xml`.
 
-How do I see or get notified about recent VTS LTP results?
+How do I see recent VTS LTP results?
 ----------------------------------------------------------
 
-The internal portal at go/vts-web shows results for the continuous VTS testing
-done on internal devices. By adding tests such as VtsKernelLtp or
-VtsKernelLtpStaging to your favorites you will get email notifications whenever
-failures are seen.  Be warned, the testing iterates continuously and the
-notification emails can generate a lot of traffic.
+The internal portal at go/vts11-dashboard shows results for the continuous VTS testing
+done on internal devices.
 
 Test results are also gathered by Linaro and may be seen
 [here](https://qa-reports.linaro.org/android-lkft/).
@@ -200,6 +191,10 @@
 platform and are unsure if they are safe you should run them in emulation, in a
 virtualized environment, or on a dedicated development x86 platform.
 
+To run LTP tests for x86 platform, you can do:
+* `atest vts_ltp_test_x86`
+* `atest vts_ltp_test_x86_64`
+
 Sending Fixes Upstream
 ----------------------
 
diff --git a/testcases/kernel/syscalls/mknod/mknod07.c b/testcases/kernel/syscalls/mknod/mknod07.c
index 69cff02..8291990 100644
--- a/testcases/kernel/syscalls/mknod/mknod07.c
+++ b/testcases/kernel/syscalls/mknod/mknod07.c
@@ -43,6 +43,7 @@
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/mount.h>
+#include <sys/sysmacros.h>
 
 #include "test.h"
 #include "safe_macros.h"
@@ -69,13 +70,14 @@
 	char *pathname;
 	int mode;
 	int exp_errno;
+	int major, minor;
 } test_cases[] = {
-	{ "testdir_1/tnode_1", SOCKET_MODE, EACCES },
-	{ "testdir_1/tnode_2", FIFO_MODE, EACCES },
-	{ "tnode_3", CHR_MODE, EPERM },
-	{ "tnode_4", BLK_MODE, EPERM },
-	{ "mntpoint/tnode_5", SOCKET_MODE, EROFS },
-	{ elooppathname, FIFO_MODE, ELOOP },
+	{ "testdir_1/tnode_1", SOCKET_MODE, EACCES, 0, 0 },
+	{ "testdir_1/tnode_2", FIFO_MODE, EACCES, 0, 0 },
+	{ "tnode_3", CHR_MODE, EPERM, 1, 3 },
+	{ "tnode_4", BLK_MODE, EPERM, 0, 0 },
+	{ "mntpoint/tnode_5", SOCKET_MODE, EROFS, 0, 0 },
+	{ elooppathname, FIFO_MODE, ELOOP, 0, 0 },
 };
 
 char *TCID = "mknod07";
@@ -149,7 +151,8 @@
 
 static void mknod_verify(const struct test_case_t *test_case)
 {
-	TEST(mknod(test_case->pathname, test_case->mode, 0));
+	TEST(mknod(test_case->pathname, test_case->mode,
+		makedev(test_case->major, test_case->minor)));
 
 	if (TEST_RETURN != -1) {
 		tst_resm(TFAIL, "mknod succeeded unexpectedly");