Hi,
This series adds initial KVM selftests support for powerpc
(64-bit, BookS). It spans 3 maintainers but it does not really
affect arch/powerpc, and it is well contained in selftests
code, just touches some makefiles and a tiny bit headers so
conflicts should be unlikely and trivial.
I guess Paolo is the best point to merge these, if no comments
or objections?
Thanks,
Nick
Nicholas Piggin (2):
KVM: PPC: Add kvm selftests support for powerpc
KVM: PPC: Add basic framework tests for kvm selftests
tools/testing/selftests/kvm/Makefile | 14 +
.../selftests/kvm/include/kvm_util_base.h | 13 +
.../selftests/kvm/include/powerpc/hcall.h | 22 ++
.../selftests/kvm/include/powerpc/processor.h | 13 +
tools/testing/selftests/kvm/lib/kvm_util.c | 10 +
.../testing/selftests/kvm/lib/powerpc/hcall.c | 45 +++
.../selftests/kvm/lib/powerpc/processor.c | 355 ++++++++++++++++++
.../testing/selftests/kvm/lib/powerpc/ucall.c | 30 ++
.../testing/selftests/kvm/powerpc/null_test.c | 186 +++++++++
.../selftests/kvm/powerpc/rtas_hcall.c | 146 +++++++
10 files changed, 834 insertions(+)
create mode 100644 tools/testing/selftests/kvm/include/powerpc/hcall.h
create mode 100644 tools/testing/selftests/kvm/include/powerpc/processor.h
create mode 100644 tools/testing/selftests/kvm/lib/powerpc/hcall.c
create mode 100644 tools/testing/selftests/kvm/lib/powerpc/processor.c
create mode 100644 tools/testing/selftests/kvm/lib/powerpc/ucall.c
create mode 100644 tools/testing/selftests/kvm/powerpc/null_test.c
create mode 100644 tools/testing/selftests/kvm/powerpc/rtas_hcall.c
--
2.37.2
Support ROHM BU27034 ALS sensor
This series adds support for ROHM BU27034 Ambient Light Sensor.
The BU27034 has configurable gain and measurement (integration) time
settings. Both of these have inversely proportional relation to the
sensor's intensity channel scale.
Many users only set the scale, which means that many drivers attempt to
'guess' the best gain+time combination to meet the scale. Usually this
is the biggest integration time which allows setting the requested
scale. Typically, increasing the integration time has better accuracy
than increasing the gain, which often amplifies the noise as well as the
real signal.
However, there may be cases where more responsive sensors are needed.
So, in some cases the longest integration times may not be what the user
prefers. The driver has no way of knowing this.
Hence, the approach taken by this series is to allow user to set both
the scale and the integration time with following logic:
1. When scale is set, the existing integration time is tried to be
maintained as a first priority.
1a) If the requested scale can't be met by current time, then also
other time + gain combinations are searched. If scale can be met
by some other integration time, then the new time may be applied.
If the time setting is common for all channels, then also other
channels must be able to maintain their scale with this new time
(by changing their gain). The new times are scanned in the order
of preference (typically the longest times first).
1b) If the requested scale can be met using current time, then only
the gain for the channel is changed.
2. When the integration time change - scale is tried to be maintained.
When integration time change is requested also gain for all impacted
channels is adjusted so that the scale is not changed, or is chaned
as little as possible. This is different from the RFCv1 where the
request was rejected if suitable gain couldn't be found for some
channel(s).
This logic is simple. When total gain (either caused by time or hw-gain)
is doubled, the scale gets halved. Also, the supported times are given a
'multiplier' value which tells how much they increase the total gain.
However, when I wrote this logic in bu27034 driver, I made quite a few
errors on the way - and driver got pretty big. As I am writing drivers
for two other sensors (RGB C/IR + flicker BU27010 and RGB C/IR BU27008)
with similar gain-time-scale logic I thought that adding common helpers
for these computations might be wise. I hope this way all the bugs will
be concentrated in one place and not in every individual driver ;)
Hence, this series also intriduces IIO gain-time-scale helpers
(abbreviated as gts-helpers) + a couple of KUnit tests for the most
hairy parts.
Speaking of which - testing the devm interfaces requires a 'dummy
device'. There were neat helpers in DRM tests for creating and freeing
such a device. This series moves those helpers to more generic location.
What is worth noting is that there is something similar ongoing in the
CCF territory:
https://lore.kernel.org/all/20230302013822.1808711-1-sboyd@kernel.org/
These efforts should be somehow coordinated in order to avoid any avoid
conflicts.
Finally, these added helpers do provide some value also for drivers
which only:
a) allow gain change
or
b) allow changing both the time and gain while trying to maintain the
scale.
For a) we provide the gain - selector (register value) table format +
selector to gain look-ups, gain <-> scale conversions and the available
scales helpers.
For latter case we also provide the time-tables, and actually all the
APIs should be usable by setting the time multiplier to 1. (not testeted
thoroughly though).
The patch 1/8 introduces the helpers for creating/dropping a test device
for devm-tests. It can be applied alone.
The patches 2/8 (convert DRM tests to use new helper) depends on patch
1/8 but is othervice not part of this series. It can be applied to DRM
tree after the dependency to 1/8 is handled.
The patch 5/8 (IIO GTS tests) also depends on the patch 1/8 (and also
other patches in the series).
Rest of the series should be Ok to be applied with/without the patches
1/8, 2/8, 5/8 - although the 5/8 would be "nice to have" together with
the rest of the series for the testability reasons.
Revision history:
v4 => v5: Mostly fixes to review comments from Andy and Jonathan.
- more accurate change-log in individual patches
- copy code from DRM test helper instead of moving it to simplify
merging
- document all exported GTS helpers.
- inline a few GTS helpers
- use again Milli lux for the bu27034 with RAW IIO_LIGHT channel and scale
- Fix bug from added in v4 bu27034 time setting.
v3 => v4: (Still mostly fixes to review comments from Andy and Jonathan)
- more accurate change-log in individual patches
- dt-binding and maintainer patches unchanged.
- dropped unused helpers and converted ones currently used only internally
to static.
- extracted "dummy device" creation helpers from DRM tests.
- added tests for devm APIs
- dropped scale for PROCESSED channel in BU27034 and converted mLux
values to luxes
- dropped channel 2 GAIN setting which can't be done due to HW
limitations.
v2 => v3: (Mostly fixes to review comments from Andy and Jonathan)
- dt-binding and maintainer patches unchanged.
- iio-gts-helper tests: Use namespaces
- iio-gts-helpers + bu27034 plenty of changes. See more comprehensive
changelog in individual patches.
RFCv1 => v2:
dt-bindings:
- Fix binding file name and id by using comma instead of a hyphen to
separate the vendor and part names.
gts-helpers:
- fix include guardian
- Improve kernel doc for iio_init_iio_gts.
- Add iio_gts_scale_to_total_gain
- Add iio_gts_total_gain_to_scale
- Fix review comments from Jonathan
- add documentation to few functions
- replace 0xffffffffffffffffLLU by U64_MAX
- some styling fixes
- drop unnecessary NULL checks
- order function arguments by in / out purpose
- drop GAIN_SCALE_ITIME_MS()
- Add helpers for available scales and times
- Rename to iio-gts-helpers
gts-tests:
- add tests for available scales/times helpers
- adapt to renamed iio-gts-helpers.h header
bu27034-driver:
- (really) protect read-only registers
- fix get and set gain
- buffered mode
- Protect the whole sequences including meas_en/meas_dis to avoid messing
up the enable / disable order
- typofixes / doc improvements
- change dropped GAIN_SCALE_ITIME_MS() to GAIN_SCALE_ITIME_US()
- use more accurate scale for lux channel (milli lux)
- provide available scales / integration times (using helpers).
- adapt to renamed iio-gts-helpers.h file
- bu27034 - longer lines in Kconfig
- Drop bu27034_meas_en and bu27034_meas_dis wrappers.
- Change device-name from bu27034-als to bu27034
MAINTAINERS:
- Add iio-list
---
Matti Vaittinen (8):
drivers: kunit: Generic helpers for test device creation
drm/tests: helpers: Use generic helpers
dt-bindings: iio: light: Support ROHM BU27034
iio: light: Add gain-time-scale helpers
iio: test: test gain-time-scale helpers
MAINTAINERS: Add IIO gain-time-scale helpers
iio: light: ROHM BU27034 Ambient Light Sensor
MAINTAINERS: Add ROHM BU27034
.../bindings/iio/light/rohm,bu27034.yaml | 46 +
MAINTAINERS | 14 +
drivers/base/test/Kconfig | 5 +
drivers/base/test/Makefile | 2 +
drivers/base/test/test_kunit_device.c | 83 +
drivers/gpu/drm/Kconfig | 2 +
.../gpu/drm/tests/drm_client_modeset_test.c | 5 +-
drivers/gpu/drm/tests/drm_kunit_helpers.c | 69 -
drivers/gpu/drm/tests/drm_managed_test.c | 5 +-
drivers/gpu/drm/tests/drm_modes_test.c | 5 +-
drivers/gpu/drm/tests/drm_probe_helper_test.c | 5 +-
drivers/gpu/drm/vc4/Kconfig | 1 +
drivers/gpu/drm/vc4/tests/vc4_mock.c | 3 +-
.../gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 9 +-
drivers/iio/Kconfig | 3 +
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-gts-helper.c | 1064 ++++++++++++
drivers/iio/light/Kconfig | 14 +
drivers/iio/light/Makefile | 1 +
drivers/iio/light/rohm-bu27034.c | 1482 +++++++++++++++++
drivers/iio/test/Kconfig | 14 +
drivers/iio/test/Makefile | 1 +
drivers/iio/test/iio-test-gts.c | 542 ++++++
include/drm/drm_kunit_helpers.h | 7 +-
include/kunit/platform_device.h | 13 +
include/linux/iio/iio-gts-helper.h | 206 +++
26 files changed, 3515 insertions(+), 87 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/light/rohm,bu27034.yaml
create mode 100644 drivers/base/test/test_kunit_device.c
create mode 100644 drivers/iio/industrialio-gts-helper.c
create mode 100644 drivers/iio/light/rohm-bu27034.c
create mode 100644 drivers/iio/test/iio-test-gts.c
create mode 100644 include/kunit/platform_device.h
create mode 100644 include/linux/iio/iio-gts-helper.h
base-commit: eeac8ede17557680855031c6f305ece2378af326
--
2.39.2
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
Change the KTAP v2 spec to allow variable prefixes to KTAP lines,
instead of fixed indentation of two spaces. However, the prefix must be
constant on the same level of testing (besides unknown lines).
This was proposed by Tim Bird in 2021 and then supported by Frank Rowand
in 2022 (see link below).
Link: https://lore.kernel.org/all/bc6e9ed7-d98b-c4da-2a59-ee0915c18f10@gmail.com/
As cited in the original proposal, it is useful in some Fuego tests to
include an identifier in the prefix. This is an example:
KTAP version 1
1..2
[batch_id 4] KTAP version 1
[batch_id 4] 1..2
[batch_id 4] ok 1 cyclictest with 1000 cycles
[batch_id 4] # problem setting CLOCK_REALTIME
[batch_id 4] not ok 2 cyclictest with CLOCK_REALTIME
not ok 1 check realtime
[batch_id 4] KTAP version 1
[batch_id 4] 1..1
[batch_id 4] ok 1 IOZone read/write 4k blocks
ok 2 check I/O performance
Here is a link to a version of the KUnit parser that is able to parse
variable length prefixes for KTAP version 2. Note that the prefix must
be constant at the same level of testing.
Link: https://kunit-review.googlesource.com/c/linux/+/5710
Signed-off-by: Rae Moar <rmoar(a)google.com>
---
This idea has already been proposed but I wanted to potentially
restart the discussion by demonstrating this change can by
implemented in the KUnit parser. Let me know what you think.
Note: this patch is based on Frank's ktap_spec_version_2 branch.
Documentation/dev-tools/ktap.rst | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst
index ff77f4aaa6ef..ac61fdd97096 100644
--- a/Documentation/dev-tools/ktap.rst
+++ b/Documentation/dev-tools/ktap.rst
@@ -192,9 +192,11 @@ starting with another KTAP version line and test plan, and end with the overall
result. If one of the subtests fail, for example, the parent test should also
fail.
-Additionally, all lines in a subtest should be indented. One level of
-indentation is two spaces: " ". The indentation should begin at the version
-line and should end before the parent test's result line.
+Additionally, all lines in a subtest should be indented. The standard for one
+level of indentation is two spaces: " ". However, any prefix for indentation
+is allowed as long as the prefix is consistent throughout that level of
+testing. The indentation should begin at the version line and should end
+before the parent test's result line.
"Unknown lines" are not considered to be lines in a subtest and thus are
allowed to be either indented or not indented.
@@ -229,6 +231,19 @@ An example format with multiple levels of nested testing:
not ok 1 example_test_1
ok 2 example_test_2
+An example of a test with two nested subtests using prefixes:
+
+::
+
+ KTAP version 2
+ 1..1
+ [prefix_1] KTAP version 2
+ [prefix_1] 1..2
+ [prefix_1] ok 1 test_1
+ [prefix_1] ok 2 test_2
+ # example passed
+ ok 1 example
+
Major differences between TAP and KTAP
--------------------------------------
base-commit: 906f02e42adfbd5ae70d328ee71656ecb602aaf5
--
2.40.0.rc1.284.g88254d51c5-goog
Add recognition of the test name line ("# Subtest: <name>") to the KTAP v2
spec.
The purpose of this line is to declare the name of a test before its
results. This functionality is especially useful when trying to parse test
results incrementally and when interpretting results after a crash.
This line is already compliant with KTAP v1 as it is interpretted as a
diagnostic line by parsers. Additionally, the line is currently used by
KUnit tests and was derived from the TAP 14 spec:
https://testanything.org/tap-version-14-specification.html.
Recognition of this line would create an accepted way for different test
frameworks to declare the name of a test before its results.
The proposed location for this line is between the version line and the
test plan line. This location ensures that the line would not be
accidentally parsed as a subtest's diagnostic lines. Note this proposed
location would be a slight differentiation from KTAP v1.
Example of test name line:
KTAP version 2
# Subtest: main_test
1..1
KTAP version 2
# Subtest: sub_test
1..2
ok 1 test_1
ok 2 test_2
ok 1 sub_test
Here is a link to a version of the KUnit parser that is able to parse the
test name line for KTAP version 2. Note this includes a test name line for
the main level of KTAP.
Link: https://kunit-review.googlesource.com/c/linux/+/5709
Signed-off-by: Rae Moar <rmoar(a)google.com>
---
This is a RFC. I would like to know what people think and use this as a
platform for discussion on KTAP v2.
Note: this patch is based on Frank's ktap_spec_version_2 branch.
Documentation/dev-tools/ktap.rst | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst
index ff77f4aaa6ef..9c7ed66d9f77 100644
--- a/Documentation/dev-tools/ktap.rst
+++ b/Documentation/dev-tools/ktap.rst
@@ -28,8 +28,7 @@ KTAP output is built from four different types of lines:
In general, valid KTAP output should also form valid TAP output, but some
information, in particular nested test results, may be lost. Also note that
there is a stagnant draft specification for TAP14, KTAP diverges from this in
-a couple of places (notably the "Subtest" header), which are described where
-relevant later in this document.
+a couple of places, which are described where relevant later in this document.
Version lines
-------------
@@ -44,8 +43,8 @@ For example:
- "TAP version 14"
Note that, in KTAP, subtests also begin with a version line, which denotes the
-start of the nested test results. This differs from TAP14, which uses a
-separate "Subtest" line.
+start of the nested test results. This differs from TAP14, which uses only a
+"Subtest" line.
While, going forward, "KTAP version 2" should be used by compliant tests, it
is expected that most parsers and other tooling will accept the other versions
@@ -166,6 +165,12 @@ even if they do not start with a "#": this is to capture any other useful
kernel output which may help debug the test. It is nevertheless recommended
that tests always prefix any diagnostic output they have with a "#" character.
+One recognized diagnostic line is the "# Subtest: <name>" line. This line
+is used to declare the name of a test before subtest results are printed. This
+is helpful for parsing and for providing context during crashes. As a rule,
+this line is placed after the version line and before the plan line. Note
+this line can be used for the main test, as well as subtests.
+
Unknown lines
-------------
@@ -206,6 +211,7 @@ An example of a test with two nested subtests:
KTAP version 2
1..1
KTAP version 2
+ # Subtest: example
1..2
ok 1 test_1
not ok 2 test_2
@@ -219,6 +225,7 @@ An example format with multiple levels of nested testing:
KTAP version 2
1..2
KTAP version 2
+ # Subtest: example_test_1
1..2
KTAP version 2
1..2
@@ -245,7 +252,7 @@ allows an arbitrary number of tests to be nested no yes
The TAP14 specification does permit nested tests, but instead of using another
nested version line, uses a line of the form
-"Subtest: <name>" where <name> is the name of the parent test.
+"Subtest: <name>" where <name> is the name of the parent test as discussed above.
Example KTAP output
--------------------
@@ -254,6 +261,7 @@ Example KTAP output
KTAP version 2
1..1
KTAP version 2
+ # Subtest: main_test
1..3
KTAP version 2
1..1
@@ -266,6 +274,7 @@ Example KTAP output
ok 2 test_2
ok 2 example_test_2
KTAP version 2
+ # Subtest: example_test_3
1..3
ok 1 test_1
# test_2: FAIL
base-commit: 906f02e42adfbd5ae70d328ee71656ecb602aaf5
--
2.40.0.rc1.284.g88254d51c5-goog
On Fri, Mar 31, 2023 at 8:05 AM kernel test robot <yujie.liu(a)intel.com> wrote:
>
> Hello,
>
> kernel test robot noticed kernel-selftests.memfd.run_fuse_test.sh.fail due to commit (built with gcc-11):
>
> commit: 11f75a01448f1b7a739e75dbd8f17b844fcfc510 ("selftests/memfd: add tests for MFD_NOEXEC_SEAL MFD_EXEC")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>
> in testcase: kernel-selftests
> version: kernel-selftests-x86_64-d4cf28ee-1_20230110
> with following parameters:
>
> group: group-02
>
> test-description: The kernel contains a set of "self tests" under the tools/testing/selftests/ directory. These are intended to be small unit tests to exercise individual code paths in the kernel.
> test-url: https://www.kernel.org/doc/Documentation/kselftest.txt
>
> on test machine: 4 threads Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz (Skylake) with 16G memory
>
> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
>
> # selftests: memfd: run_fuse_test.sh
> # Aborted
> not ok 2 selftests: memfd: run_fuse_test.sh # exit=134
>
> $ ./run_fuse_test.sh
> opening: ./mnt/memfd
> 8 != 40 = GET_SEALS(4)
> Aborted
Hi Jeff,
I think this is caused by test_sysctl() in memfd_test, which sets
/proc/sys/vm/memfd_noexec to a non-zero value and does not restore it
at the end of the test. If fuse_test runs after that, it will
unexpectedly get F_SEAL_EXEC in its memfd seals in addition to the
F_SEAL_WRITE that it intended to add.
I'm not sure how kernel selftests normally perform cleanup (e.g. an
atexit() hook to make sure it cleans up if a test fails?), but at
least we should probably set /proc/sys/vm/memfd_noexec back to its
original value after test_sysctl().
Thanks,
-- Daniel
The fork function in gcc is considered a built in function due to
being used by libgcov when building with gnu extensions.
Rename fork to sched_process_fork to prevent this conflict.
See details:
https://github.com/gcc-mirror/gcc/commit/d1c38823924506d389ca58d02926ace21b…https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82457
Fixes the following error:
In file included from progs/bench_local_storage_create.c:6:
progs/bench_local_storage_create.c:43:14: error: conflicting types for
built-in function 'fork'; expected 'int(void)'
[-Werror=builtin-declaration-mismatch]
43 | int BPF_PROG(fork, struct task_struct *parent, struct
task_struct *child)
| ^~~~
Fixes: cbe9d93d58b1 ("selftests/bpf: Add bench for task storage creation")
Signed-off-by: James Hilliard <james.hilliard1(a)gmail.com>
Cc: Martin KaFai Lau <martin.lau(a)kernel.org>
---
tools/testing/selftests/bpf/benchs/bench_local_storage_create.c | 2 +-
tools/testing/selftests/bpf/progs/bench_local_storage_create.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/bpf/benchs/bench_local_storage_create.c b/tools/testing/selftests/bpf/benchs/bench_local_storage_create.c
index abb0321d4f34..cff703f90e95 100644
--- a/tools/testing/selftests/bpf/benchs/bench_local_storage_create.c
+++ b/tools/testing/selftests/bpf/benchs/bench_local_storage_create.c
@@ -95,7 +95,7 @@ static void setup(void)
exit(1);
}
} else {
- if (!bpf_program__attach(skel->progs.fork)) {
+ if (!bpf_program__attach(skel->progs.sched_process_fork)) {
fprintf(stderr, "Error attaching bpf program\n");
exit(1);
}
diff --git a/tools/testing/selftests/bpf/progs/bench_local_storage_create.c b/tools/testing/selftests/bpf/progs/bench_local_storage_create.c
index 7c851c9d5e47..e4bfbba6c193 100644
--- a/tools/testing/selftests/bpf/progs/bench_local_storage_create.c
+++ b/tools/testing/selftests/bpf/progs/bench_local_storage_create.c
@@ -40,7 +40,7 @@ int BPF_PROG(kmalloc, unsigned long call_site, const void *ptr,
}
SEC("tp_btf/sched_process_fork")
-int BPF_PROG(fork, struct task_struct *parent, struct task_struct *child)
+int BPF_PROG(sched_process_fork, struct task_struct *parent, struct task_struct *child)
{
struct storage *stg;
--
2.34.1