This patch series adds partial read support in request_firmware_into_buf.
In order to accept the enhanced API it has been requested that kernel
selftests and upstreamed driver utilize the API enhancement and so
are included in this patch series.
Also, no tests existed for existing request_firmware_into_buf kernel API.
Therefore tests have been created and submitted upstream here:
"[PATCH v2 0/2] firmware: selftest for request_firmware_into_buf"
https://lkml.org/lkml/2019/8/22/1367
The firmware selftests patches here require those patches to
be applied first in order for the firmware selftest patches in this
series to be valid.
Finally, in this patch series is the addition of a new Broadcom Valkyrie driver
utilizing the new request_firmware_into_buf enhanced API.
Scott Branden (7):
fs: introduce kernel_pread_file* support
firmware: add offset to request_firmware_into_buf
test_firmware: add partial read support for request_firmware_into_buf
selftests: firmware: Test partial file reads of
request_firmware_into_buf
bcm-vk: add bcm_vk UAPI
misc: bcm-vk: add Broadcom Valkyrie driver
MAINTAINERS: bcm-vk: Add maintainer for Broadcom Valkyrie Driver
MAINTAINERS | 7 +
drivers/base/firmware_loader/firmware.h | 5 +
drivers/base/firmware_loader/main.c | 49 +-
drivers/misc/Kconfig | 1 +
drivers/misc/Makefile | 1 +
drivers/misc/bcm-vk/Kconfig | 16 +
drivers/misc/bcm-vk/Makefile | 7 +
drivers/misc/bcm-vk/README | 29 +
drivers/misc/bcm-vk/bcm_vk.h | 229 +++
drivers/misc/bcm-vk/bcm_vk_dev.c | 1558 +++++++++++++++++
drivers/misc/bcm-vk/bcm_vk_msg.c | 963 ++++++++++
drivers/misc/bcm-vk/bcm_vk_msg.h | 169 ++
drivers/misc/bcm-vk/bcm_vk_sg.c | 273 +++
drivers/misc/bcm-vk/bcm_vk_sg.h | 60 +
drivers/soc/qcom/mdt_loader.c | 7 +-
fs/exec.c | 77 +-
include/linux/firmware.h | 8 +-
include/linux/fs.h | 15 +
include/uapi/linux/misc/bcm_vk.h | 88 +
lib/test_firmware.c | 139 +-
.../selftests/firmware/fw_filesystem.sh | 80 +
21 files changed, 3744 insertions(+), 37 deletions(-)
create mode 100644 drivers/misc/bcm-vk/Kconfig
create mode 100644 drivers/misc/bcm-vk/Makefile
create mode 100644 drivers/misc/bcm-vk/README
create mode 100644 drivers/misc/bcm-vk/bcm_vk.h
create mode 100644 drivers/misc/bcm-vk/bcm_vk_dev.c
create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.c
create mode 100644 drivers/misc/bcm-vk/bcm_vk_msg.h
create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.c
create mode 100644 drivers/misc/bcm-vk/bcm_vk_sg.h
create mode 100644 include/uapi/linux/misc/bcm_vk.h
--
2.17.1
Commit 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second
timeout per test") added a 45 second timeout for tests, and also added
a way for tests to customise the timeout via a settings file.
For example the ftrace tests take multiple minutes to run, so they
were given longer in commit b43e78f65b1d ("tracing/selftests: Turn off
timeout setting").
This works when the tests are run from the source tree. However if the
tests are installed with "make -C tools/testing/selftests install",
the settings files are not copied into the install directory. When the
tests are then run from the install directory the longer timeouts are
not applied and the tests timeout incorrectly.
So add the settings files to TEST_FILES of the appropriate Makefiles
to cause the settings files to be installed using the existing install
logic.
Fixes: 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test")
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
---
tools/testing/selftests/ftrace/Makefile | 2 +-
tools/testing/selftests/livepatch/Makefile | 2 ++
tools/testing/selftests/net/mptcp/Makefile | 2 ++
tools/testing/selftests/rseq/Makefile | 2 ++
tools/testing/selftests/rtc/Makefile | 2 ++
5 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/Makefile b/tools/testing/selftests/ftrace/Makefile
index cd1f5b3a7774..d6e106fbce11 100644
--- a/tools/testing/selftests/ftrace/Makefile
+++ b/tools/testing/selftests/ftrace/Makefile
@@ -2,7 +2,7 @@
all:
TEST_PROGS := ftracetest
-TEST_FILES := test.d
+TEST_FILES := test.d settings
EXTRA_CLEAN := $(OUTPUT)/logs/*
include ../lib.mk
diff --git a/tools/testing/selftests/livepatch/Makefile b/tools/testing/selftests/livepatch/Makefile
index 3876d8d62494..1acc9e1fa3fb 100644
--- a/tools/testing/selftests/livepatch/Makefile
+++ b/tools/testing/selftests/livepatch/Makefile
@@ -8,4 +8,6 @@ TEST_PROGS := \
test-state.sh \
test-ftrace.sh
+TEST_FILES := settings
+
include ../lib.mk
diff --git a/tools/testing/selftests/net/mptcp/Makefile b/tools/testing/selftests/net/mptcp/Makefile
index 93de52016dde..ba450e62dc5b 100644
--- a/tools/testing/selftests/net/mptcp/Makefile
+++ b/tools/testing/selftests/net/mptcp/Makefile
@@ -8,6 +8,8 @@ TEST_PROGS := mptcp_connect.sh
TEST_GEN_FILES = mptcp_connect
+TEST_FILES := settings
+
EXTRA_CLEAN := *.pcap
include ../../lib.mk
diff --git a/tools/testing/selftests/rseq/Makefile b/tools/testing/selftests/rseq/Makefile
index d6469535630a..f1053630bb6f 100644
--- a/tools/testing/selftests/rseq/Makefile
+++ b/tools/testing/selftests/rseq/Makefile
@@ -19,6 +19,8 @@ TEST_GEN_PROGS_EXTENDED = librseq.so
TEST_PROGS = run_param_test.sh
+TEST_FILES := settings
+
include ../lib.mk
$(OUTPUT)/librseq.so: rseq.c rseq.h rseq-*.h
diff --git a/tools/testing/selftests/rtc/Makefile b/tools/testing/selftests/rtc/Makefile
index de9c8566672a..90fa1a346908 100644
--- a/tools/testing/selftests/rtc/Makefile
+++ b/tools/testing/selftests/rtc/Makefile
@@ -6,4 +6,6 @@ TEST_GEN_PROGS = rtctest
TEST_GEN_PROGS_EXTENDED = setdate
+TEST_FILES := settings
+
include ../lib.mk
--
2.21.1
Hi,
On 2/19/20 4:48 PM, Scott Branden wrote:
> diff --git a/drivers/misc/bcm-vk/Kconfig b/drivers/misc/bcm-vk/Kconfig
> new file mode 100644
> index 000000000000..c75dfb89a38d
> --- /dev/null
> +++ b/drivers/misc/bcm-vk/Kconfig
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Broadcom VK device
> +#
> +config BCM_VK
> + tristate "Support for Broadcom VK Accelerators"
> + depends on PCI_MSI
> + default m
Need to justify default m. Normally we don't add drivers as enabled unless
they are required for basic (boot) operation.
> + help
> + Select this option to enable support for Broadcom
> + VK Accelerators. VK is used for performing
> + specific video offload processing. This driver enables
> + userspace programs to access these accelerators via /dev/bcm-vk.N
> + devices.
> +
> + If unsure, say N.
> +
> +if BCM_VK
> +
> +config BCM_VK_H2VK_VERIFY_AND_RETRY
> + bool "Host To VK Verifiy Data and Retry"
Verify
> + help
> + Turn on to verify the data passed down to VK is good,
> + and if not, do a retry until it succeeds.
No timeout on that retry?
> + This is a debug/workaround on FPGA PCIe timing issues
> + but may be found useful for debugging other PCIe hardware issues.
> + Small performance loss by enabling this debug config.
> + For properly operating PCIe hardware no need to enable this.
> +
> + If unsure, say N.
> +
> +config BCM_VK_QSTATS
> + bool "VK Queue Statistics"
> + help
> + Turn on to enable Queue Statistics.
> + These are useful for debugging purposes.
> + Some performance loss by enabling this debug config.
> + For properly operating PCIe hardware no need to enable this.
> +
> + If unsure, say N.
> +
> +endif
cheers.
--
~Randy
On 2/19/20 5:27 PM, Alexei Starovoitov wrote:
> On Wed, Feb 19, 2020 at 03:59:41PM -0600, Daniel Díaz wrote:
>>>
>>> When I download a specific kernel release, how can I know what LLVM
>>> git-hash or version I need (to use BPF-selftests)?
>
> as discussed we're going to add documentation-like file that will
> list required commits in tools.
> This will be enforced for future llvm/pahole commits.
>
>>> Do you think it is reasonable to require end-users to compile their own
>>> bleeding edge version of LLVM, to use BPF-selftests?
>
> absolutely.
+ linux-kselftest(a)vger.kernel.org
End-users in this context are users and not necessarily developers.
> If a developer wants to send a patch they must run all selftests and
> all of them must pass in their environment.
> "but I'm adding a tracing feature and don't care about networking tests
> failing"... is not acceptable.
This is a reasonable expectation when a developers sends bpf patches.
>
>>> I do hope that some end-users of BPF-selftests will be CI-systems.
>>> That also implies that CI-system maintainers need to constantly do
>>> "latest built from sources" of LLVM git-tree to keep up. Is that a
>>> reasonable requirement when buying a CI-system in the cloud?
>
> "buying CI-system in the cloud" ?
> If I could buy such system I would pay for it out of my own pocket to save
> maintainer's and developer's time.
>
>> We [1] are end users of kselftests and many other test suites [2]. We
>> run all of our testing on every git-push on linux-stable-rc, mainline,
>> and linux-next -- approximately 1 million tests per week. We have a
>> dedicated engineering team looking after this CI infrastructure and
>> test results, and as such, I can wholeheartedly echo Jesper's
>> sentiment here: We would really like to help kernel maintainers and
>> developers by automatically testing their code in real hardware, but
>> the BPF kselftests are difficult to work with from a CI perspective.
>> We have caught and reported [3] many [4] build [5] failures [6] in the
>> past for libbpf/Perf, but building is just one of the pieces. We are
>> unable to run the entire BPF kselftests because only a part of the
>> code builds, so our testing is very limited there.
>>
>> We hope that this situation can be improved and that our and everyone
>> else's automated testing can help you guys too. For this to work out,
>> we need some help.
>
It would be helpful understand what "help" is in this context.
> I don't understand what kind of help you need. Just install the latest tools.
What would be helpful is to write bpf tests such that older tests that
worked on older llvm versions continue to work and with some indication
on which tests require new bleeding edge tools.
> Both the latest llvm and the latest pahole are required.
It would be helpful if you can elaborate why latest tools are a
requirement.
> If by 'help' you mean to tweak selftests to skip tests then it's a nack.
> We have human driven CI. Every developer must run selftests/bpf before
> emailing the patches. Myself and Daniel run them as well before applying.
> These manual runs is the only thing that keeps bpf tree going.
> If selftests get to skip tests humans will miss those errors.
> When I don't see '0 SKIPPED, 0 FAILED' I go and investigate.
> Anything but zero is a path to broken kernels.
>
> Imagine the tests would get skipped when pahole is too old.
> That would mean all of the kernel features from year 2019
> would get skipped. Is there a point of running such selftests?
> I think the value is not just zero. The value is negative.
> Such selftests that run old stuff would give false believe
> that they do something meaningful.
> "but CI can do build only tests"... If 'helping' such CI means hurting the
> key developer/maintainer workflow such CI is on its own.
>
Skipping tests will be useless. I am with you on that. However,
figuring out how to maintain some level of backward compatibility
to run at least older tests and warn users to upgrade would be
helpful.
I suspect currently users are ignoring bpf failures because they
are unable to keep up with the requirement to install newer tools
to run the tests. This isn't great either.
Users that care are sharing their pain to see if they can get some
help or explanation on why new tools are required every so often.
I don't think everybody understands why. :)
thanks,
-- Shuah
On 2/20/20 7:58 AM, Christophe Leroy wrote:
> ping
>
> On 02/06/2020 08:11 AM, Christophe Leroy wrote:
>> Commit 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets")
>> added generation of lkdtm test scripts.
>>
>> Ignore those generated scripts when performing 'git status'
>>
>> Fixes: 46d1a0f03d66 ("selftests/lkdtm: Add tests for LKDTM targets")
>> Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
>
> Without this, 'git status' now reports the following crap and real
> problems are drowned in the middle, that's annoying.
>
I will pull this in. Please cc linux-kselftest mailing list in the
future.
thanks,
-- Shuah
Hi Linus,
Please pull the following Kselftest fixes update for Linux 5.6-rc3
This Kselftest update for Linux 5.6-rc3 consists of fixes to build
failures and other test bugs.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9:
Linux 5.6-rc1 (2020-02-09 16:08:48 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-5.6-rc3
for you to fetch changes up to 9a0584f05687947d5a0b87f046bcd2592a55e67c:
selftests: openat2: fix build error on newer glibc (2020-02-13
13:15:45 -0700)
----------------------------------------------------------------
linux-kselftest-5.6-rc3
This Kselftest update for Linux 5.6-rc3 consists of fixes to build
failures and other test bugs.
----------------------------------------------------------------
Aleksa Sarai (1):
selftests: openat2: fix build error on newer glibc
Colin Ian King (1):
selftests: fix spelling mistaked "chaigned" -> "chained"
Dmitry Safonov (1):
selftests: use LDLIBS for libraries instead of LDFLAGS
Jiri Benc (2):
selftests: allow detection of build failures
selftests: fix too long argument
Nikita Sobolev (1):
Kernel selftests: tpm2: check for tpm support
Steven Rostedt (VMware) (1):
selftests/ftrace: Have pid filter test use instance flag
tools/testing/selftests/Makefile | 12 +++++++++--
.../ftrace/test.d/ftrace/func-filter-pid.tc | 8 +-------
tools/testing/selftests/futex/functional/Makefile | 2 +-
tools/testing/selftests/lib.mk | 23
++++++++++++----------
tools/testing/selftests/net/Makefile | 4 ++--
tools/testing/selftests/openat2/helpers.c | 2 +-
tools/testing/selftests/openat2/resolve_test.c | 2 +-
tools/testing/selftests/rtc/Makefile | 2 +-
tools/testing/selftests/timens/Makefile | 2 +-
tools/testing/selftests/tpm2/test_smoke.sh | 13 ++++++++++--
tools/testing/selftests/tpm2/test_space.sh | 9 ++++++++-
11 files changed, 50 insertions(+), 29 deletions(-)
----------------------------------------------------------------