28 Sep, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220926100756.074519146@linuxfoundation.org
Tested-by: Shuah Khan
Link: https://lore.kernel.org/r/20220926163551.791017156@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Bagas Sanjaya
Tested-by: Linux Kernel Functional Testing
Tested-by: Sudip Mukherjee
Tested-by: Ron Economos
Tested-by: Guenter Roeck
Tested-by: Kelsey Steele
Tested-by: Jon Hunter
Signed-off-by: Greg Kroah-Hartman
23 Sep, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220921153646.931277075@linuxfoundation.org
Tested-by: Shuah Khan
Tested-by: Bagas Sanjaya
Tested-by: Jon Hunter
Tested-by: Sudip Mukherjee
Tested-by: Florian Fainelli
Tested-by: Ron Economos
Signed-off-by: Greg Kroah-Hartman
20 Sep, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220916100446.916515275@linuxfoundation.org
Tested-by: Guenter Roeck
Tested-by: Bagas Sanjaya
Tested-by: Ron Economos
Tested-by: Sudip Mukherjee
Tested-by: Florian Fainelli
Signed-off-by: Greg Kroah-Hartman
15 Sep, 2022
2 commits
-
Link: https://lore.kernel.org/r/20220913140357.323297659@linuxfoundation.org
Tested-by: Bagas Sanjaya =20
Tested-by: Sudip Mukherjee
Tested-by: Linux Kernel Functional Testing
Tested-by: Ron Economos
Tested-by: Jon Hunter
Tested-by: Guenter Roeck
Tested-by: Florian Fainelli
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 1b620d539ccc18a1aca1613d9ff078115a7891a1 ]
Previously 'make ARCH=um headers' stopped because of missing
arch/um/include/uapi/asm/Kbuild.The error is not shown since commit ed102bf2afed ("um: Fix W=1
missing-include-dirs warnings") added arch/um/include/uapi/asm/Kbuild.Hard-code the unsupported architecture, so it works like before.
Fixes: ed102bf2afed ("um: Fix W=1 missing-include-dirs warnings")
Signed-off-by: Masahiro Yamada
Acked-by: Richard Weinberger
Signed-off-by: Sasha Levin
08 Sep, 2022
3 commits
-
Signed-off-by: Greg Kroah-Hartman
-
Link: https://lore.kernel.org/r/20220906132821.713989422@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Linux Kernel Functional Testing
Tested-by: Shuah Khan
Tested-by: Guenter Roeck
Tested-by: Sudip Mukherjee
Tested-by: Bagas Sanjaya
Tested-by: Ron Economos
Signed-off-by: Greg Kroah-Hartman -
commit e27f05147bff21408c1b8410ad8e90cd286e7952 upstream.
Using new PAHOLE_FLAGS variable to pass extra arguments to
pahole for both vmlinux and modules BTF data generation.Adding new scripts/pahole-flags.sh script that detect and
prints pahole options.[ fixed issues found by kernel test robot ]
Signed-off-by: Jiri Olsa
Signed-off-by: Andrii Nakryiko
Acked-by: Andrii Nakryiko
Link: https://lore.kernel.org/bpf/20211029125729.70002-1-jolsa@kernel.org
Signed-off-by: Greg Kroah-Hartman
05 Sep, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220902121404.435662285@linuxfoundation.org
Tested-by: Jon Hunter
Tested-by: Florian Fainelli
Tested-by: Shuah Khan
Tested-by: Guenter Roeck
Tested-by: Linux Kernel Functional Testing
Tested-by: Bagas Sanjaya
Tested-by: Ron Economos
Tested-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
31 Aug, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220829105804.609007228@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Shuah Khan
Tested-by: Guenter Roeck
Tested-by: Linux Kernel Functional Testing
Tested-by: Bagas Sanjaya
Tested-by: Ron Economos
Tested-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
25 Aug, 2022
2 commits
-
Link: https://lore.kernel.org/r/20220823080059.091088642@linuxfoundation.org
Tested-by: Shuah Khan
Link: https://lore.kernel.org/r/20220824065913.068916566@linuxfoundation.org
Tested-by: Ron Economos
Tested-by: Guenter Roeck
Tested-by: Linux Kernel Functional Testing
Tested-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman -
commit 113147510b48e764e624e3d0e6707a1e48bc05a9 upstream.
Commit b2c885549122 ("kbuild: update modules.order only when contained
modules are updated") accidentally changed the modules order.Prior to that commit, the modules order was determined based on
vmlinux-dirs, which lists core-y/m, drivers-y/m, libs-y/m, in this order.Now, subdir-modorder lists them in a different order: core-y/m, libs-y/m,
drivers-y/m.Presumably, there was no practical issue because the modules in drivers
and libs are orthogonal, but there is no reason to have this distortion.Get back to the original order.
Fixes: b2c885549122 ("kbuild: update modules.order only when contained modules are updated")
Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman
21 Aug, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220819153711.658766010@linuxfoundation.org
Tested-by: Shuah Khan
Tested-by: Bagas Sanjaya
Tested-by: Sudip Mukherjee
Tested-by: Ron Economos
Link: https://lore.kernel.org/r/20220820182309.607584465@linuxfoundation.org
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
17 Aug, 2022
2 commits
-
Link: https://lore.kernel.org/r/20220815180337.130757997@linuxfoundation.org
Tested-by: Shuah Khan
Tested-by: Bagas Sanjaya
Link: https://lore.kernel.org/r/20220816124544.577833376@linuxfoundation.org
Tested-by: Linux Kernel Functional Testing
Tested-by: Guenter Roeck
Tested-by: Ron Economos
Signed-off-by: Greg Kroah-Hartman -
commit 0d362be5b14200b77ecc2127936a5ff82fbffe41 upstream.
Users of GNU ld (BFD) from binutils 2.39+ will observe multiple
instances of a new warning when linking kernels in the form:ld: warning: vmlinux: missing .note.GNU-stack section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker
ld: warning: vmlinux has a LOAD segment with RWX permissionsGenerally, we would like to avoid the stack being executable. Because
there could be a need for the stack to be executable, assembler sources
have to opt-in to this security feature via explicit creation of the
.note.GNU-stack feature (which compilers create by default) or command
line flag --noexecstack. Or we can simply tell the linker the
production of such sections is irrelevant and to link the stack as
--noexecstack.LLVM's LLD linker defaults to -z noexecstack, so this flag isn't
strictly necessary when linking with LLD, only BFD, but it doesn't hurt
to be explicit here for all linkers IMO. --no-warn-rwx-segments is
currently BFD specific and only available in the current latest release,
so it's wrapped in an ld-option check.While the kernel makes extensive usage of ELF sections, it doesn't use
permissions from ELF segments.Link: https://lore.kernel.org/linux-block/3af4127a-f453-4cf7-f133-a181cce06f73@kernel.dk/
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
Link: https://github.com/llvm/llvm-project/issues/57009
Reported-and-tested-by: Jens Axboe
Suggested-by: Fangrui Song
Signed-off-by: Nick Desaulniers
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
11 Aug, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220809175514.276643253@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Bagas Sanjaya
Tested-by: Linux Kernel Functional Testing
Tested-by: Sudip Mukherjee
Tested-by: Guenter Roeck
Tested-by: Jon Hunter
Tested-by: Shuah Khan
Tested-by: Ron Economos
Signed-off-by: Greg Kroah-Hartman
03 Aug, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220801114134.468284027@linuxfoundation.org
Tested-by: Jon Hunter
Tested-by: Florian Fainelli
Tested-by: Linux Kernel Functional Testing
Tested-by: Shuah Khan
Tested-by: Bagas Sanjaya
Tested-by: Guenter Roeck
Tested-by: Ron Economos
Tested-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
29 Jul, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220727161026.977588183@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Linux Kernel Functional Testing
Tested-by: Bagas Sanjaya
Tested-by: Jon Hunter
Tested-by: Shuah Khan
Link: https://lore.kernel.org/r/20220728133327.660846209@linuxfoundation.org
Tested-by: Jon Hunter
Tested-by: Guenter Roeck
Tested-by: Ron Economos
Tested-by: Bagas Sanjaya
Tested-by: Linux Kernel Functional Testing
Tested-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
23 Jul, 2022
4 commits
-
Link: https://lore.kernel.org/r/20220722091133.320803732@linuxfoundation.org
Tested-by: Bagas Sanjaya
Tested-by: Florian Fainelli
Tested-by: Linux Kernel Functional Testing
Tested-by: Guenter Roeck
Tested-by: Ron Economos
Tested-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman -
commit 68cf4f2a72ef8786e6b7af6fd9a89f27ac0f520d upstream.
In order to further enable commit:
bbe2df3f6b6d ("x86/alternative: Try inline spectre_v2=retpoline,amd")
add the new GCC flag -mindirect-branch-cs-prefix:
https://gcc.gnu.org/g:2196a681d7810ad8b227bf983f38ba716620545e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102952
https://bugs.llvm.org/show_bug.cgi?id=52323to RETPOLINE=y builds. This should allow fully inlining retpoline,amd
for GCC builds.Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-by: Kees Cook
Acked-by: Nick Desaulniers
Link: https://lkml.kernel.org/r/20211119165630.276205624@infradead.org
Signed-off-by: Greg Kroah-Hartman -
commit f43b9876e857c739d407bc56df288b0ebe1a9164 upstream.
Do fine-grained Kconfig for all the various retbleed parts.
NOTE: if your compiler doesn't support return thunks this will
silently 'upgrade' your mitigation to IBPB, you might not like this.Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
[cascardo: there is no CONFIG_OBJTOOL]
[cascardo: objtool calling and option parsing has changed]
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman -
commit 0b53c374b9eff2255a386f1f1cfb9a928e52a5ae upstream.
Utilize -mfunction-return=thunk-extern when available to have the
compiler replace RET instructions with direct JMPs to the symbol
__x86_return_thunk. This does not affect assembler (.S) sources, only C
sources.-mfunction-return=thunk-extern has been available since gcc 7.3 and
clang 15.Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Borislav Petkov
Reviewed-by: Nick Desaulniers
Reviewed-by: Josh Poimboeuf
Tested-by: Nick Desaulniers
Signed-off-by: Borislav Petkov
[cascardo: RETPOLINE_CFLAGS is at Makefile]
[cascardo: remove ANNOTATE_NOENDBR from __x86_return_thunk]
Signed-off-by: Thadeu Lima de Souza Cascardo
Signed-off-by: Greg Kroah-Hartman
22 Jul, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220719114656.750574879@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Guenter Roeck
Tested-by: Ron Economos
Tested-by: Jon Hunter
Tested-by: Bagas Sanjaya
Tested-by: Linux Kernel Functional Testing
Tested-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman
15 Jul, 2022
1 commit
-
Signed-off-by: Greg Kroah-Hartman
12 Jul, 2022
2 commits
-
Link: https://lore.kernel.org/r/20220711090604.055883544@linuxfoundation.org
Link: https://lore.kernel.org/r/20220711145306.494277196@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Shuah Khan
Tested-by: Ron Economos
Tested-by: Bagas Sanjaya
Link: https://lore.kernel.org/r/20220712071513.420542604@linuxfoundation.org
Tested-by: Jon Hunter
Tested-by: Bagas Sanjaya
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 86cffecdeaa278444870c8745ab166a65865dbf0 ]
GCC and Clang can use the "alloc_size" attribute to better inform the
results of __builtin_object_size() (for compile-time constant values).
Clang can additionally use alloc_size to inform the results of
__builtin_dynamic_object_size() (for run-time values).Because GCC sees the frequent use of struct_size() as an allocator size
argument, and notices it can return SIZE_MAX (the overflow indication),
it complains about these call sites overflowing (since SIZE_MAX is
greater than the default -Walloc-size-larger-than=PTRDIFF_MAX). This
isn't helpful since we already know a SIZE_MAX will be caught at
run-time (this was an intentional design). To deal with this, we must
disable this check as it is both a false positive and redundant. (Clang
does not have this warning option.)Unfortunately, just checking the -Wno-alloc-size-larger-than is not
sufficient to make the __alloc_size attribute behave correctly under
older GCC versions. The attribute itself must be disabled in those
situations too, as there appears to be no way to reliably silence the
SIZE_MAX constant expression cases for GCC versions less than 9.1:In file included from ./include/linux/resource_ext.h:11,
from ./include/linux/pci.h:40,
from drivers/net/ethernet/intel/ixgbe/ixgbe.h:9,
from drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c:4:
In function 'kmalloc_node',
inlined from 'ixgbe_alloc_q_vector' at ./include/linux/slab.h:743:9:
./include/linux/slab.h:618:9: error: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Werror=alloc-size-larger-than=]
return __kmalloc_node(size, flags, node);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/slab.h: In function 'ixgbe_alloc_q_vector':
./include/linux/slab.h:455:7: note: in a call to allocation function '__kmalloc_node' declared here
void *__kmalloc_node(size_t size, gfp_t flags, int node) __assume_slab_alignment __malloc;
^~~~~~~~~~~~~~Specifically:
'-Wno-alloc-size-larger-than' is not correctly handled by GCC < 9.1
https://godbolt.org/z/hqsfG7q84 (doesn't disable)
https://godbolt.org/z/P9jdrPTYh (doesn't admit to not knowing about option)
https://godbolt.org/z/465TPMWKb (only warns when other warnings appear)'-Walloc-size-larger-than=18446744073709551615' is not handled by GCC < 8.2
https://godbolt.org/z/73hh1EPxz (ignores numeric value)Since anything marked with __alloc_size would also qualify for marking
with __malloc, just include __malloc along with it to avoid redundant
markings. (Suggested by Linus Torvalds.)Finally, make sure checkpatch.pl doesn't get confused about finding the
__alloc_size attribute on functions. (Thanks to Joe Perches.)Link: https://lkml.kernel.org/r/20210930222704.2631604-3-keescook@chromium.org
Signed-off-by: Kees Cook
Tested-by: Randy Dunlap
Cc: Andy Whitcroft
Cc: Christoph Lameter
Cc: Daniel Micay
Cc: David Rientjes
Cc: Dennis Zhou
Cc: Dwaipayan Ray
Cc: Joe Perches
Cc: Joonsoo Kim
Cc: Lukas Bulwahn
Cc: Pekka Enberg
Cc: Tejun Heo
Cc: Vlastimil Babka
Cc: Alexandre Bounine
Cc: Gustavo A. R. Silva
Cc: Ira Weiny
Cc: Jing Xiangfeng
Cc: John Hubbard
Cc: kernel test robot
Cc: Matt Porter
Cc: Miguel Ojeda
Cc: Nathan Chancellor
Cc: Nick Desaulniers
Cc: Souptick Joarder
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
07 Jul, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220705115617.568350164@linuxfoundation.org
Tested-by: Jon Hunter
Tested-by: Florian Fainelli
Tested-by: Linux Kernel Functional Testing
Tested-by: Bagas Sanjaya
Tested-by: Ron Economos
Tested-by: Sudip Mukherjee
Tested-by: Guenter Roeck
Tested-by: Shuah Khan
Signed-off-by: Greg Kroah-Hartman
02 Jul, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220630133232.926711493@linuxfoundation.org
Tested-by: Jon Hunter
Tested-by: Shuah Khan
Tested-by: Florian Fainelli
Tested-by: Guenter Roeck
Tested-by: Bagas Sanjaya
Tested-by: Linux Kernel Functional Testing
Tested-by: Sudip Mukherjee
Tested-by: Christian Brauner (Microsoft)
Tested-by: Ron Economos
Signed-off-by: Greg Kroah-Hartman
29 Jun, 2022
2 commits
-
Link: https://lore.kernel.org/r/20220627111938.151743692@linuxfoundation.org
Tested-by: Jon Hunter
Tested-by: Florian Fainelli
Tested-by: Shuah Khan
Tested-by: Guenter Roeck
Tested-by: Bagas Sanjaya
Tested-by: Ron Economos
Tested-by: Sudip Mukherjee
Signed-off-by: Greg Kroah-Hartman -
commit 53632ba87d9f302a8d97a11ec2f4f4eec7bb75ea upstream.
If CONFIG_TRIM_UNUSED_KSYMS is enabled and the kernel is built from
a pristine state, the vmlinux is linked twice.Commit 3fdc7d3fe4c0 ("kbuild: link vmlinux only once for
CONFIG_TRIM_UNUSED_KSYMS") explains why this happens, but it did not fix
the issue at all.Now I realized I had applied a wrong patch.
In v1 patch [1], the autoksyms_recursive target correctly recurses to
"$(MAKE) -f $(srctree)/Makefile autoksyms_recursive".In v2 patch [2], I accidentally dropped the diff line, and it recurses to
"$(MAKE) -f $(srctree)/Makefile vmlinux".Restore the code I intended in v1.
[1]: https://lore.kernel.org/linux-kbuild/1521045861-22418-8-git-send-email-yamada.masahiro@socionext.com/
[2]: https://lore.kernel.org/linux-kbuild/1521166725-24157-8-git-send-email-yamada.masahiro@socionext.com/Fixes: 3fdc7d3fe4c0 ("kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS")
Signed-off-by: Masahiro Yamada
Tested-by: Sami Tolvanen
Reviewed-by: Nick Desaulniers
Signed-off-by: Greg Kroah-Hartman
25 Jun, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220623164322.288837280@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Shuah Khan
Tested-by: Bagas Sanjaya
Tested-by: Jon Hunter
Tested-by: Sudip Mukherjee
Tested-by: Ron Economos
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
22 Jun, 2022
2 commits
-
Link: https://lore.kernel.org/r/20220620124724.380838401@linuxfoundation.org
Tested-by: Fox Chen
Tested-by: Florian Fainelli
Tested-by: Guenter Roeck
Tested-by: Bagas Sanjaya
Tested-by: Ron Economos
Tested-by: Sudip Mukherjee
Tested-by: Jon Hunter
Tested-by: Shuah Khan
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 49beadbd47c270a00754c107a837b4f29df4c822 ]
While the concept of checking for dangling pointers to local variables
at function exit is really interesting, the gcc-12 implementation is not
compatible with reality, and results in false positives.For example, gcc sees us putting things on a local list head allocated
on the stack, which involves exactly those kinds of pointers to the
local stack entry:In function ‘__list_add’,
inlined from ‘list_add_tail’ at include/linux/list.h:102:2,
inlined from ‘rebuild_snap_realms’ at fs/ceph/snap.c:434:2:
include/linux/list.h:74:19: warning: storing the address of local variable ‘realm_queue’ in ‘*&realm_27(D)->rebuild_item.prev’ [-Wdangling-pointer=]
74 | new->prev = prev;
| ~~~~~~~~~~^~~~~~But then gcc - understandably - doesn't really understand the big
picture how the doubly linked list works, so doesn't see how we then end
up emptying said list head in a loop and the pointer we added has been
removed.Gcc also complains about us (intentionally) using this as a way to store
a kind of fake stack trace, egdrivers/acpi/acpica/utdebug.c:40:38: warning: storing the address of local variable ‘current_sp’ in ‘acpi_gbl_entry_stack_pointer’ [-Wdangling-pointer=]
40 | acpi_gbl_entry_stack_pointer = ¤t_sp;
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~which is entirely reasonable from a compiler standpoint, and we may want
to change those kinds of patterns, but not not.So this is one of those "it would be lovely if the compiler were to
complain about us leaving dangling pointers to the stack", but not this
way.Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
16 Jun, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220614183720.512073672@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Fox Chen
Tested-by: Shuah Khan
Tested-by: Bagas Sanjaya
Tested-by: Sudip Mukherjee
Tested-by: Allen Pais
Tested-by: Ron Economos
Tested-by: Linux Kernel Functional Testing
Tested-by: Guenter Roeck
Tested-by: Tyler Hicks
Tested-by: Jon Hunter
Signed-off-by: Greg Kroah-Hartman
15 Jun, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220613094922.843438024@linuxfoundation.org
Tested-by: Fox Chen
Tested-by: Bagas Sanjaya
Link: https://lore.kernel.org/r/20220613181847.216528857@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Shuah Khan
Tested-by: Fox Chen
Tested-by: Sudip Mukherjee
Tested-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman
09 Jun, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220607164934.766888869@linuxfoundation.org
Tested-by: Fox Chen
Tested-by: Shuah Khan
Tested-by: Sudip Mukherjee
Tested-by: Bagas Sanjaya
Tested-by: Linux Kernel Functional Testing
Tested-by: Guenter Roeck
Tested-by: Ron Economos
Signed-off-by: Greg Kroah-Hartman
06 Jun, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220603173820.663747061@linuxfoundation.org
Tested-by: Fox Chen
Tested-by: Sudip Mukherjee
Tested-by: Linux Kernel Functional Testing
Tested-by: Guenter Roeck
Tested-by: Bagas Sanjaya
Tested-by: Ron Economos
Signed-off-by: Greg Kroah-Hartman
30 May, 2022
1 commit
-
Link: https://lore.kernel.org/r/20220527084850.364560116@linuxfoundation.org
Tested-by: Guenter Roeck
Tested-by: Bagas Sanjaya
Tested-by: Linux Kernel Functional Testing
Signed-off-by: Greg Kroah-Hartman
25 May, 2022
2 commits
-
Signed-off-by: Greg Kroah-Hartman
-
Link: https://lore.kernel.org/r/20220523165823.492309987@linuxfoundation.org
Tested-by: Florian Fainelli
Tested-by: Shuah Khan
Tested-by: Linux Kernel Functional Testing
Tested-by: Fox Chen
Tested-by: Sudip Mukherjee
Tested-by: Ron Economos
Tested-by: Guenter Roeck
Tested-by: Khalid Masum
Signed-off-by: Greg Kroah-Hartman