aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-05-25i2c: sh_mobile: Use new clock calculation formulas for RZ/G2EGeert Uytterhoeven1-1/+1
When switching the Gen3 SoCs to the new clock calculation formulas, the match entry for RZ/G2E added in commit 51243b73455f2d12 ("i2c: sh_mobile: Add support for r8a774c0 (RZ/G2E)") was forgotten. Fixes: e8a27567509b2439 ("i2c: sh_mobile: use new clock calculation formulas for Gen3") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Fabrizio Castro <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-05-25i2c: I2C_HISI should depend on ACPIGeert Uytterhoeven1-1/+1
The HiSilicon Kunpeng I2C controller driver relies on ACPI to probe for its presence. Hence add a dependency on ACPI, to prevent asking the user about this driver when configuring a kernel without ACPI firmware support. Fixes: d62fbdb99a85730a ("i2c: add support for HiSilicon I2C controller") Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Yicong Yang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-05-25i2c: icy: Remove unused variable new_fwnode in icy_probe()Geert Uytterhoeven1-1/+0
The last user of new_fwnode was removed, leading to: drivers/i2c/busses/i2c-icy.c: In function ‘icy_probe’: drivers/i2c/busses/i2c-icy.c:126:24: warning: unused variable ‘new_fwnode’ [-Wunused-variable] 126 | struct fwnode_handle *new_fwnode; | ^~~~~~~~~~ Fixes: dd7a37102b79ae55 ("i2c: icy: Constify the software node") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Max Staudt <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-05-25i2c: qcom-geni: fix spelling mistake "unepxected" -> "unexpected"Colin Ian King1-1/+1
There is a spelling mistake in an error message string, fix it. Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Akash Asthana <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-05-25bpf: Fix BPF_LSM kconfig symbol dependencyDaniel Borkmann1-0/+2
Similarly as 6bdacdb48e94 ("bpf: Fix BPF_JIT kconfig symbol dependency") we need to detangle the hard BPF_LSM dependency on NET. This was previously implicit by its dependency on BPF_JIT which itself was dependent on NET (but without any actual/real hard dependency code-wise). Given the latter was lifted, so should be the former as BPF_LSMs could well exist on net-less systems. This therefore also fixes a randconfig build error recently reported by Randy: ld: kernel/bpf/bpf_lsm.o: in function `bpf_lsm_func_proto': bpf_lsm.c:(.text+0x1a0): undefined reference to `bpf_sk_storage_get_proto' ld: bpf_lsm.c:(.text+0x1b8): undefined reference to `bpf_sk_storage_delete_proto' [...] Fixes: b24abcff918a ("bpf, kconfig: Add consolidated menu entry for bpf with core options") Reported-by: Randy Dunlap <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Acked-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]>
2021-05-25s390/dasd: add missing discipline functionStefan Haberland3-3/+14
Fix crash with illegal operation exception in dasd_device_tasklet. Commit b72949328869 ("s390/dasd: Prepare for additional path event handling") renamed the verify_path function for ECKD but not for FBA and DIAG. This leads to a panic when the path verification function is called for a FBA or DIAG device. Fix by defining a wrapper function for dasd_generic_verify_path(). Fixes: b72949328869 ("s390/dasd: Prepare for additional path event handling") Cc: <[email protected]> #5.11 Reviewed-by: Jan Hoeppner <[email protected]> Signed-off-by: Stefan Haberland <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]>
2021-05-25Merge tag 'netfs-lib-fixes-20200525' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs Pull netfs fixes from David Howells: "A couple of fixes to the new netfs lib: - Pass the AOP flags through from netfs_write_begin() into grab_cache_page_write_begin(). - Automatically enable in Kconfig netfs lib rather than presenting an option for manual enablement" * tag 'netfs-lib-fixes-20200525' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: netfs: Make CONFIG_NETFS_SUPPORT auto-selected rather than manual netfs: Pass flags through to grab_cache_page_write_begin()
2021-05-25afs: Fix fall-through warnings for ClangGustavo A. R. Silva3-0/+10
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple fallthrough pseudo-keywords in places where the code is intended to fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Jeffrey Altman <[email protected]> cc: [email protected] cc: [email protected] Link: https://lore.kernel.org/r/51150b54e0b0431a2c401cd54f2c4e7f50e94601.1605896059.git.gustavoars@kernel.org/ # v1 Link: https://lore.kernel.org/r/20210420211615.GA51432@embeddedor/ # v2 Signed-off-by: Linus Torvalds <[email protected]>
2021-05-25selftests/bpf: Add test for l3 use of bpf_redirect_peerJussi Maki2-178/+405
Add a test case for using bpf_skb_change_head() in combination with bpf_redirect_peer() to redirect a packet from a L3 device to veth and back. The test uses a BPF program that adds L2 headers to the packet coming from a L3 device and then calls bpf_redirect_peer() to redirect the packet to a veth device. The test fails as skb->mac_len is not set properly and thus the ethernet headers are not properly skb_pull'd in cls_bpf_classify(), causing tcp_v4_rcv() to point the TCP header into middle of the IP header. Signed-off-by: Jussi Maki <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-05-25ALSA: hda/realtek: Chain in pop reduction fixup for ThinkStation P340Peter Ujfalusi1-1/+9
Lenovo ThinkStation P340 uses ALC623 codec (SSID 17aa:1048) and it produces bug plock/pop noise over line out (green jack on the back) which can be fixed by applying ALC269_FIXUP_NO_SHUTUP tot he machine. Convert the existing entry for the same SSID to chain to apply this fixup as well. Suggested-by: Takashi Iwai <[email protected]> Signed-off-by: Peter Ujfalusi <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-05-25bpftool: Add sock_release help info for cgroup attach/prog load commandLiu Jian5-7/+10
The help information was not added at the time when the function got added. Fix this and add the missing information to its cli, documentation and bash completion. Fixes: db94cc0b4805 ("bpftool: Add support for BPF_CGROUP_INET_SOCK_RELEASE") Signed-off-by: Liu Jian <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Reviewed-by: Quentin Monnet <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-05-25MIPS: Fix kernel hang under FUNCTION_GRAPH_TRACER and PREEMPT_TRACERTiezhu Yang1-6/+6
When update the latest mainline kernel with the following three configs, the kernel hangs during startup: (1) CONFIG_FUNCTION_GRAPH_TRACER=y (2) CONFIG_PREEMPT_TRACER=y (3) CONFIG_FTRACE_STARTUP_TEST=y When update the latest mainline kernel with the above two configs (1) and (2), the kernel starts normally, but it still hangs when execute the following command: echo "function_graph" > /sys/kernel/debug/tracing/current_tracer Without CONFIG_PREEMPT_TRACER=y, the above two kinds of kernel hangs disappeared, so it seems that CONFIG_PREEMPT_TRACER has some influences with function_graph tracer at the first glance. I use ejtag to find out the epc address is related with preempt_enable() in the file arch/mips/lib/mips-atomic.c, because function tracing can trace the preempt_{enable,disable} calls that are traced, replace them with preempt_{enable,disable}_notrace to prevent function tracing from going into an infinite loop, and then it can fix the kernel hang issue. By the way, it seems that this commit is a complement and improvement of commit f93a1a00f2bd ("MIPS: Fix crash that occurs when function tracing is enabled"). Signed-off-by: Tiezhu Yang <[email protected]> Cc: Steven Rostedt <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2021-05-25MIPS: ralink: export rt_sysc_membase for rt2880_wdt.cRandy Dunlap1-0/+2
rt2880_wdt.c uses (well, attempts to use) rt_sysc_membase. However, when this watchdog driver is built as a loadable module, there is a build error since the rt_sysc_membase symbol is not exported. Export it to quell the build error. ERROR: modpost: "rt_sysc_membase" [drivers/watchdog/rt2880_wdt.ko] undefined! Fixes: 473cf939ff34 ("watchdog: add ralink watchdog driver") Signed-off-by: Randy Dunlap <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Wim Van Sebroeck <[email protected]> Cc: John Crispin <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Guenter Roeck <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2021-05-25MIPS: launch.h: add include guard to prevent build errorsRandy Dunlap1-0/+5
arch/mips/include/asm/mips-boards/launch.h needs an include guard to prevent it from being #included more than once. Prevents these build errors: In file included from ../arch/mips/mti-malta/malta-amon.c:16: ../arch/mips/include/asm/mips-boards/launch.h:8:8: error: redefinition of 'struct cpulaunch' 8 | struct cpulaunch { | ^~~~~~~~~ In file included from ../arch/mips/include/asm/mips-cps.h:13, from ../arch/mips/include/asm/smp-ops.h:16, from ../arch/mips/include/asm/smp.h:21, from ../include/linux/smp.h:114, from ../arch/mips/mti-malta/malta-amon.c:12: ../arch/mips/include/asm/mips-boards/launch.h:8:8: note: originally defined here 8 | struct cpulaunch { | ^~~~~~~~~ make[3]: [../scripts/Makefile.build:273: arch/mips/mti-malta/malta-amon.o] Error 1 (ignored) Fixes: 6decd1aad15f ("MIPS: add support for buggy MT7621S core detection") Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Cc: [email protected] Cc: Ilya Lipnitskiy <[email protected]> Reviewed-by: Ilya Lipnitskiy <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2021-05-25MIPS: alchemy: xxs1500: add gpio-au1000.h header fileRandy Dunlap1-0/+1
board-xxs1500.c references 2 functions without declaring them, so add the header file to placate the build. ../arch/mips/alchemy/board-xxs1500.c: In function 'board_setup': ../arch/mips/alchemy/board-xxs1500.c:56:2: error: implicit declaration of function 'alchemy_gpio1_input_enable' [-Werror=implicit-function-declaration] 56 | alchemy_gpio1_input_enable(); ../arch/mips/alchemy/board-xxs1500.c:57:2: error: implicit declaration of function 'alchemy_gpio2_enable'; did you mean 'alchemy_uart_enable'? [-Werror=implicit-function-declaration] 57 | alchemy_gpio2_enable(); Fixes: 8e026910fcd4 ("MIPS: Alchemy: merge GPR/MTX-1/XXS1500 board code into single files") Signed-off-by: Randy Dunlap <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Cc: [email protected] Cc: Manuel Lauss <[email protected]> Cc: Ralf Baechle <[email protected]> Acked-by: Manuel Lauss <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2021-05-25arm64: mm: don't use CON and BLK mapping if KFENCE is enabledJisheng Zhang1-1/+2
When we added KFENCE support for arm64, we intended that it would force the entire linear map to be mapped at page granularity, but we only enforced this in arch_add_memory() and not in map_mem(), so memory mapped at boot time can be mapped at a larger granularity. When booting a kernel with KFENCE=y and RODATA_FULL=n, this results in the following WARNING at boot: [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at mm/memory.c:2462 apply_to_pmd_range+0xec/0x190 [ 0.000000] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.13.0-rc1+ #10 [ 0.000000] Hardware name: linux,dummy-virt (DT) [ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO BTYPE=--) [ 0.000000] pc : apply_to_pmd_range+0xec/0x190 [ 0.000000] lr : __apply_to_page_range+0x94/0x170 [ 0.000000] sp : ffffffc010573e20 [ 0.000000] x29: ffffffc010573e20 x28: ffffff801f400000 x27: ffffff801f401000 [ 0.000000] x26: 0000000000000001 x25: ffffff801f400fff x24: ffffffc010573f28 [ 0.000000] x23: ffffffc01002b710 x22: ffffffc0105fa450 x21: ffffffc010573ee4 [ 0.000000] x20: ffffff801fffb7d0 x19: ffffff801f401000 x18: 00000000fffffffe [ 0.000000] x17: 000000000000003f x16: 000000000000000a x15: ffffffc01060b940 [ 0.000000] x14: 0000000000000000 x13: 0098968000000000 x12: 0000000098968000 [ 0.000000] x11: 0000000000000000 x10: 0000000098968000 x9 : 0000000000000001 [ 0.000000] x8 : 0000000000000000 x7 : ffffffc010573ee4 x6 : 0000000000000001 [ 0.000000] x5 : ffffffc010573f28 x4 : ffffffc01002b710 x3 : 0000000040000000 [ 0.000000] x2 : ffffff801f5fffff x1 : 0000000000000001 x0 : 007800005f400705 [ 0.000000] Call trace: [ 0.000000] apply_to_pmd_range+0xec/0x190 [ 0.000000] __apply_to_page_range+0x94/0x170 [ 0.000000] apply_to_page_range+0x10/0x20 [ 0.000000] __change_memory_common+0x50/0xdc [ 0.000000] set_memory_valid+0x30/0x40 [ 0.000000] kfence_init_pool+0x9c/0x16c [ 0.000000] kfence_init+0x20/0x98 [ 0.000000] start_kernel+0x284/0x3f8 Fixes: 840b23986344 ("arm64, kfence: enable KFENCE for ARM64") Cc: <[email protected]> # 5.12.x Signed-off-by: Jisheng Zhang <[email protected]> Acked-by: Mark Rutland <[email protected]> Acked-by: Marco Elver <[email protected]> Tested-by: Marco Elver <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2021-05-25netfs: Make CONFIG_NETFS_SUPPORT auto-selected rather than manualDavid Howells1-1/+1
Make the netfs helper library selected automatically by the things that use it rather than being manually configured, even though it's required[1]. Fixes: 3a5829fefd3b ("netfs: Make a netfs helper module") Reported-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Jeff Layton <[email protected]> cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] Link: https://lore.kernel.org/r/CAMuHMdXJZ7iNQE964CdBOU=vRKVMFzo=YF_eiwsGgqzuvZ+TuA@mail.gmail.com [1] Link: https://lore.kernel.org/r/162090298141.3166007.2971118149366779916.stgit@warthog.procyon.org.uk # v1
2021-05-25netfs: Pass flags through to grab_cache_page_write_begin()David Howells1-1/+1
In netfs_write_begin(), pass the AOP flags through to grab_cache_page_write_begin() so that a request to use GFP_NOFS is honoured. Fixes: e1b1240c1ff5 ("netfs: Add write_begin helper") Reported-by: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] cc: [email protected] Link: https://lore.kernel.org/r/162090295383.3165945.13595101698295243662.stgit@warthog.procyon.org.uk # v1
2021-05-25drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4Imre Deak1-38/+33
The driver currently disables the LTTPR non-transparent link training mode for sinks with a DPCD_REV<1.4, based on the following description of the LTTPR DPCD register range in DP standard 2.0 (at the 0xF0000 register description): "" LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for DPCD r1.4 (or higher). """ The transparent link training mode should still work fine, however the implementation for this in some retimer FWs seems to be broken, see the References: link below. After discussions with DP standard authors the above "DPCD r1.4" does not refer to the DPCD revision (stored in the DPCD_REV reg at 0x00000), rather to the "LTTPR field data structure revision" stored in the 0xF0000 reg. An update request has been filed at vesa.org (see wg/Link/documentComment/3746) for the upcoming v2.1 specification to clarify the above description along the following lines: """ LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid only for LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 1.4 (or higher) """ Based on my tests Windows uses the non-transparent link training mode for DPCD_REV==1.2 sinks as well (so presumably for all DPCD_REVs), and forcing it to use transparent mode on ICL/TGL platforms leads to the same LT failure as reported at the References: link. Based on the above let's assume that the transparent link training mode is not well tested/supported and align the code to the correct interpretation of what the r1.4 version refers to. Reported-and-tested-by: Casey Harkins <[email protected]> Tested-by: Khaled Almahallawy <[email protected]> References: https://gitlab.freedesktop.org/drm/intel/-/issues/3415 Fixes: 264613b406eb ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4") Cc: <[email protected]> # v5.11+ Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Khaled Almahallawy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit cb4920cc40f630b5a247f4ed7d3dea66749df588) Signed-off-by: Jani Nikula <[email protected]>
2021-05-25xhci: Fix 5.12 regression of missing xHC cache clearing command after a StallMathias Nyman1-2/+6
If endpoints halts due to a stall then the dequeue pointer read from hardware may already be set ahead of the stalled TRB. After commit 674f8438c121 ("xhci: split handling halted endpoints into two steps") in 5.12 xhci driver won't issue a Set TR Dequeue if hardware dequeue pointer is already in the right place. Turns out the "Set TR Dequeue pointer" command is anyway needed as it in addition to moving the dequeue pointer also clears endpoint state and cache. Fixes: 674f8438c121 ("xhci: split handling halted endpoints into two steps") Cc: <[email protected]> # 5.12 Reported-by: Peter Ganzhorn <[email protected]> Tested-by: Peter Ganzhorn <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-05-25xhci: fix giving back URB with incorrect status regression in 5.12Mathias Nyman1-5/+1
5.12 kernel changes how xhci handles cancelled URBs and halted endpoints. Among these changes cancelled and stalled URBs are no longer given back before they are cleared from xHC hardware cache. These changes unfortunately cleared the -EPIPE status of a stalled transfer in one case before giving bak the URB, causing a USB card reader to fail from working. Fixes: 674f8438c121 ("xhci: split handling halted endpoints into two steps") Cc: <[email protected]> # 5.12 Reported-by: Peter Ganzhorn <[email protected]> Tested-by: Peter Ganzhorn <[email protected]> Signed-off-by: Mathias Nyman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2021-05-25drm/meson: fix shutdown crash when component not probedNeil Armstrong1-4/+5
When main component is not probed, by example when the dw-hdmi module is not loaded yet or in probe defer, the following crash appears on shutdown: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ... pc : meson_drv_shutdown+0x24/0x50 lr : platform_drv_shutdown+0x20/0x30 ... Call trace: meson_drv_shutdown+0x24/0x50 platform_drv_shutdown+0x20/0x30 device_shutdown+0x158/0x360 kernel_restart_prepare+0x38/0x48 kernel_restart+0x18/0x68 __do_sys_reboot+0x224/0x250 __arm64_sys_reboot+0x24/0x30 ... Simply check if the priv struct has been allocated before using it. Fixes: fa0c16caf3d7 ("drm: meson_drv add shutdown function") Reported-by: Stefan Agner <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Tested-by: Martin Blumenstingl <[email protected]> Reviewed-by: Martin Blumenstingl <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-05-25nvme-fabrics: decode host pathing error for connectHannes Reinecke1-0/+5
Add an additional decoding for 'host pathing error' during connect. Signed-off-by: Hannes Reinecke <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2021-05-25nvme-fc: short-circuit reconnect retriesHannes Reinecke1-8/+17
Returning an nvme status from nvme_fc_create_association() indicates that the association is established, and we should honour the DNR bit. If it's set a reconnect attempt will just return the same error, so we can short-circuit the reconnect attempts and fail the connection directly. Signed-off-by: Hannes Reinecke <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Himanshu Madhani <[email protected]> Reviewed-by: James Smart <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2021-05-25nvme: fix potential memory leaks in nvme_cdev_addGuoqing Jiang1-1/+3
We need to call put_device if cdev_device_add failed, otherwise kmemleak has below report. [<0000000024c71758>] kmem_cache_alloc_trace+0x233/0x480 [<00000000ad2813ed>] device_add+0x7ff/0xe10 [<0000000035bc54c4>] cdev_device_add+0x72/0xa0 [<000000006c9aa1e8>] nvme_cdev_add+0xa9/0xf0 [nvme_core] [<000000003c4d492d>] nvme_mpath_set_live+0x251/0x290 [nvme_core] [<00000000889a58da>] nvme_mpath_add_disk+0x268/0x320 [nvme_core] [<00000000192e7161>] nvme_alloc_ns+0x669/0xac0 [nvme_core] [<000000007a1a6041>] nvme_validate_or_alloc_ns+0x156/0x280 [nvme_core] [<000000003a763c35>] nvme_scan_work+0x221/0x3c0 [nvme_core] [<000000009ff10706>] process_one_work+0x5cf/0xb10 [<000000000644ee25>] worker_thread+0x7a/0x680 [<00000000285ebd2f>] kthread+0x1c6/0x210 [<00000000e297c6ea>] ret_from_fork+0x22/0x30 Fixes: 2637baed7801 ("nvme: introduce generic per-namespace chardev") Signed-off-by: Guoqing Jiang <[email protected]> Reviewed-by: Javier González <[email protected]> Reviewed-by: Sagi Grimberg <[email protected]> Reviewed-by: Chaitanya Kulkarni <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2021-05-25Merge tag 'asoc-fix-v5.13-rc3' of ↵Takashi Iwai25-149/+202
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.13 A collection of fixes that have come in since the merge window, mainly device specific things. The fixes to the generic cards from Morimoto-san are handling regressions that were introduced in the merge window on at least the Kontron sl28-var3-ads2.
2021-05-24Merge tag 'perf-tools-fixes-for-v5.13-2021-05-24' of ↵Linus Torvalds20-30/+71
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tool fixes from Arnaldo Carvalho de Melo: - Fix 'perf script' decoding of Intel PT traces for abort handling and sample instruction bytes. - Add missing PERF_IP_FLAG_CHARS for VM-Entry and VM-Exit to Intel PT 'perf script' decoder. - Fixes for the python based Intel PT trace viewer GUI. - Sync UAPI copies (unwire quotactl_path, some comment fixes). - Fix handling of missing kernel software events, such as the recently added 'cgroup-switches', and add the trivial glue for it in the tooling side, since it was added in this merge window. - Add missing initialization of zstd_data in 'perf buildid-list', detected with valgrind's memcheck. - Remove needless event enable/disable when all events uses BPF. - Fix libpfm4 support (63) test error for nested event groups. * tag 'perf-tools-fixes-for-v5.13-2021-05-24' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: perf stat: Skip evlist__[enable|disable] when all events uses BPF perf script: Add missing PERF_IP_FLAG_CHARS for VM-Entry and VM-Exit perf scripts python: exported-sql-viewer.py: Fix warning display perf scripts python: exported-sql-viewer.py: Fix Array TypeError perf scripts python: exported-sql-viewer.py: Fix copy to clipboard from Top Calls by elapsed Time report tools headers UAPI: Sync files changed by the quotactl_path unwiring tools headers UAPI: Sync linux/perf_event.h with the kernel sources tools headers UAPI: Sync linux/fs.h with the kernel sources perf parse-events: Check if the software events array slots are populated perf tools: Add 'cgroup-switches' software event perf intel-pt: Remove redundant setting of ptq->insn_len perf intel-pt: Fix sample instruction bytes perf intel-pt: Fix transaction abort handling perf test: Fix libpfm4 support (63) test error for nested event groups tools arch kvm: Sync kvm headers with the kernel sources perf buildid-list: Initialize zstd_data
2021-05-24xfs: validate extsz hints against rt extent size when rtinherit is setDarrick J. Wong5-0/+85
The RTINHERIT bit can be set on a directory so that newly created regular files will have the REALTIME bit set to store their data on the realtime volume. If an extent size hint (and EXTSZINHERIT) are set on the directory, the hint will also be copied into the new file. As pointed out in previous patches, for realtime files we require the extent size hint be an integer multiple of the realtime extent, but we don't perform the same validation on a directory with both RTINHERIT and EXTSZINHERIT set, even though the only use-case of that combination is to propagate extent size hints into new realtime files. This leads to inode corruption errors when the bad values are propagated. Because there may be existing filesystems with such a configuration, we cannot simply amend the inode verifier to trip on these directories and call it a day because that will cause previously "working" filesystems to start throwing errors abruptly. Note that it's valid to have directories with rtinherit set even if there is no realtime volume, in which case the problem does not manifest because rtinherit is ignored if there's no realtime device; and it's possible that someone set the flag, crashed, repaired the filesystem (which clears the hint on the realtime file) and continued. Therefore, mitigate this issue in several ways: First, if we try to write out an inode with both rtinherit/extszinherit set and an unaligned extent size hint, turn off the hint to correct the error. Second, if someone tries to misconfigure a directory via the fssetxattr ioctl, fail the ioctl. Third, reverify both extent size hint values when we propagate heritable inode attributes from parent to child, to prevent misconfigurations from spreading. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Carlos Maiolino <[email protected]> Reviewed-by: Brian Foster <[email protected]>
2021-05-24xfs: standardize extent size hint validationDarrick J. Wong2-73/+41
While chasing a bug involving invalid extent size hints being propagated into newly created realtime files, I noticed that the xfs_ioctl_setattr checks for the extent size hints weren't the same as the ones now encoded in libxfs and used for validation in repair and mkfs. Because the checks in libxfs are more stringent than the ones in the ioctl, it's possible for a live system to set inode flags that immediately result in corruption warnings. Specifically, it's possible to set an extent size hint on an rtinherit directory without checking if the hint is aligned to the realtime extent size, which makes no sense since that combination is used only to seed new realtime files. Replace the open-coded and inadequate checks with the libxfs verifier versions and update the code comments a bit. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]>
2021-05-24xfs: check free AG space when making per-AG reservationsDarrick J. Wong1-3/+15
The new online shrink code exposed a gap in the per-AG reservation code, which is that we only return ENOSPC to callers if the entire fs doesn't have enough free blocks. Except for debugging mode, the reservation init code doesn't ever check that there's enough free space in that AG to cover the reservation. Not having enough space is not considered an immediate fatal error that requires filesystem offlining because (a) it's shouldn't be possible to wind up in that state through normal file operations and (b) even if one did, freeing data blocks would recover the situation. However, online shrink now needs to know if shrinking would not leave enough space so that it can abort the shrink operation. Hence we need to promote this assertion into an actual error return. Observed by running xfs/168 with a 1k block size, though in theory this could happen with any configuration. Signed-off-by: Darrick J. Wong <[email protected]> Reviewed-by: Brian Foster <[email protected]> Reviewed-by: Carlos Maiolino <[email protected]> Reviewed-by: Gao Xiang <[email protected]>
2021-05-24Makefile: LTO: have linker check -Wframe-larger-thanNick Desaulniers1-0/+5
-Wframe-larger-than= requires stack frame information, which the frontend cannot provide. This diagnostic is emitted late during compilation once stack frame size is available. When building with LTO, the frontend simply lowers C to LLVM IR and does not have stack frame information, so it cannot emit this diagnostic. When the linker drives LTO, it restarts optimizations and lowers LLVM IR to object code. At that point, it has stack frame information but doesn't know to check for a specific max stack frame size. I consider this a bug in LLVM that we need to fix. There are some details we're working out related to LTO such as which value to use when there are multiple different values specified per TU, or how to propagate these to compiler synthesized routines properly, if at all. Until it's fixed, ensure we don't miss these. At that point we can wrap this in a compiler version guard or revert this based on the minimum support version of Clang. The error message is not generated during link: LTO vmlinux.o ld.lld: warning: stack size limit exceeded (8224) in foobarbaz Cc: Sami Tolvanen <[email protected]> Reported-by: Candle Sun <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Nick Desaulniers <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-05-24init: verify that function is initcall_t at compile-timeMarco Elver1-1/+2
In the spirit of making it hard to misuse an interface, add a compile-time assertion in the CONFIG_HAVE_ARCH_PREL32_RELOCATIONS case to verify the initcall function matches initcall_t, because the inline asm bypasses any type-checking the compiler would otherwise do. This will help developers catch incorrect API use in all configurations. A recent example of this is: https://lkml.kernel.org/r/[email protected] Signed-off-by: Marco Elver <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Reviewed-by: Sami Tolvanen <[email protected]> Tested-by: Paul E. McKenney <[email protected]> Signed-off-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-05-24net: dsa: microchip: enable phy errata workaround on 9567George McCollister1-0/+1
Also enable phy errata workaround on 9567 since has the same errata as the 9477 according to the manufacture's documentation. Signed-off-by: George McCollister <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: usb: fix memory leak in smsc75xx_bindPavel Skripkin1-2/+6
Syzbot reported memory leak in smsc75xx_bind(). The problem was is non-freed memory in case of errors after memory allocation. backtrace: [<ffffffff84245b62>] kmalloc include/linux/slab.h:556 [inline] [<ffffffff84245b62>] kzalloc include/linux/slab.h:686 [inline] [<ffffffff84245b62>] smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460 [<ffffffff82b5b2e6>] usbnet_probe+0x3b6/0xc30 drivers/net/usb/usbnet.c:1728 Fixes: d0cad871703b ("smsc75xx: SMSC LAN75xx USB gigabit ethernet adapter driver") Cc: [email protected] Reported-and-tested-by: [email protected] Signed-off-by: Pavel Skripkin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: hsr: fix mac_len checksGeorge McCollister5-21/+34
Commit 2e9f60932a2c ("net: hsr: check skb can contain struct hsr_ethhdr in fill_frame_info") added the following which resulted in -EINVAL always being returned: if (skb->mac_len < sizeof(struct hsr_ethhdr)) return -EINVAL; mac_len was not being set correctly so this check completely broke HSR/PRP since it was always 14, not 20. Set mac_len correctly and modify the mac_len checks to test in the correct places since sometimes it is legitimately 14. Fixes: 2e9f60932a2c ("net: hsr: check skb can contain struct hsr_ethhdr in fill_frame_info") Signed-off-by: George McCollister <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: appletalk: cops: Fix data race in cops_probe1Saubhik Mukherjee1-2/+2
In cops_probe1(), there is a write to dev->base_addr after requesting an interrupt line and registering the interrupt handler cops_interrupt(). The handler might be called in parallel to handle an interrupt. cops_interrupt() tries to read dev->base_addr leading to a potential data race. So write to dev->base_addr before calling request_irq(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Saubhik Mukherjee <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24thermal/ti-soc-thermal: Fix kernel-docYang Li1-1/+1
Fix function name in ti-bandgap.c kernel-doc comment to remove a warning. drivers/thermal/ti-soc-thermal/ti-bandgap.c:787: warning: expecting prototype for ti_bandgap_alert_init(). Prototype was for ti_bandgap_talert_init() instead. Reported-by: Abaci Robot <[email protected]> Signed-off-by: Yang Li <[email protected]> Acked-by: Suman Anna <[email protected]> Signed-off-by: Daniel Lezcano <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-05-24Merge branch 'sja1105-fixes'David S. Miller2-27/+70
Vladimir Oltean says: ==================== Fixes for SJA1105 DSA driver This series contains some minor fixes in the sja1105 driver: - improved error handling in the probe path - rejecting an invalid phy-mode specified in the device tree - register access fix for SJA1105P/Q/R/S for the virtual links through the dynamic reconfiguration interface - handling 2 bridge VLANs where the second is supposed to overwrite the first - making sure that the lack of a pvid results in the actual dropping of untagged traffic ==================== Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: dsa: sja1105: update existing VLANs from the bridge VLAN listVladimir Oltean1-4/+15
When running this sequence of operations: ip link add br0 type bridge vlan_filtering 1 ip link set swp4 master br0 bridge vlan add dev swp4 vid 1 We observe the traffic sent on swp4 is still untagged, even though the bridge has overwritten the existing VLAN entry: port vlan ids swp4 1 PVID br0 1 PVID Egress Untagged This happens because we didn't consider that the 'bridge vlan add' command just overwrites VLANs like it's nothing. We treat the 'vid 1 pvid untagged' and the 'vid 1' as two separate VLANs, and the first still has precedence when calling sja1105_build_vlan_table. Obviously there is a disagreement regarding semantics, and we end up doing something unexpected from the PoV of the bridge. Let's actually consider an "existing VLAN" to be one which is on the same port, and has the same VLAN ID, as one we already have, and update it if it has different flags than we do. The first blamed commit is the one introducing the bug, the second one is the latest on top of which the bugfix still applies. Fixes: ec5ae61076d0 ("net: dsa: sja1105: save/restore VLANs using a delta commit method") Fixes: 5899ee367ab3 ("net: dsa: tag_8021q: add a context structure") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: dsa: sja1105: use 4095 as the private VLAN for untagged trafficVladimir Oltean1-12/+10
One thing became visible when writing the blamed commit, and that was that STP and PTP frames injected by net/dsa/tag_sja1105.c using the deferred xmit mechanism are always classified to the pvid of the CPU port, regardless of whatever VLAN there might be in these packets. So a decision needed to be taken regarding the mechanism through which we should ensure that delivery of STP and PTP traffic is possible when we are in a VLAN awareness mode that involves tag_8021q. This is because tag_8021q is not concerned with managing the pvid of the CPU port, since as far as tag_8021q is concerned, no traffic should be sent as untagged from the CPU port. So we end up not actually having a pvid on the CPU port if we only listen to tag_8021q, and unless we do something about it. The decision taken at the time was to keep VLAN 1 in the list of priv->dsa_8021q_vlans, and make it a pvid of the CPU port. This ensures that STP and PTP frames can always be sent to the outside world. However there is a problem. If we do the following while we are in the best_effort_vlan_filtering=true mode: ip link add br0 type bridge vlan_filtering 1 ip link set swp2 master br0 bridge vlan del dev swp2 vid 1 Then untagged and pvid-tagged frames should be dropped. But we observe that they aren't, and this is because of the precaution we took that VID 1 is always installed on all ports. So clearly VLAN 1 is not good for this purpose. What about VLAN 0? Well, VLAN 0 is managed by the 8021q module, and that module wants to ensure that 802.1p tagged frames are always received by a port, and are always transmitted as VLAN-tagged (with VLAN ID 0). Whereas we want our STP and PTP frames to be untagged if the stack sent them as untagged - we don't want the driver to just decide out of the blue that it adds VID 0 to some packets. So what to do? Well, there is one other VLAN that is reserved, and that is 4095: $ ip link add link swp2 name swp2.4095 type vlan id 4095 Error: 8021q: Invalid VLAN id. $ bridge vlan add dev swp2 vid 4095 Error: bridge: Vlan id is invalid. After we made this change, VLAN 1 is indeed forwarded and/or dropped according to the bridge VLAN table, there are no further alterations done by the sja1105 driver. Fixes: ec5ae61076d0 ("net: dsa: sja1105: save/restore VLANs using a delta commit method") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: dsa: sja1105: error out on unsupported PHY modeVladimir Oltean1-0/+1
The driver continues probing when a port is configured for an unsupported PHY interface type, instead it should stop. Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: dsa: sja1105: add error handling in sja1105_setup()Vladimir Oltean1-3/+14
If any of sja1105_static_config_load(), sja1105_clocking_setup() or sja1105_devlink_setup() fails, we can't just return in the middle of sja1105_setup() or memory will leak. Add a cleanup path. Fixes: 0a7bdbc23d8a ("net: dsa: sja1105: move devlink param code to sja1105_devlink.c") Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: dsa: sja1105: call dsa_unregister_switch when allocating memory failsVladimir Oltean1-4/+11
Unlike other drivers which pretty much end their .probe() execution with dsa_register_switch(), the sja1105 does some extra stuff. When that fails with -ENOMEM, the driver is quick to return that, forgetting to call dsa_unregister_switch(). Not critical, but a bug nonetheless. Fixes: 4d7525085a9b ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc") Fixes: a68578c20a96 ("net: dsa: Make deferred_xmit private to sja1105") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: dsa: sja1105: fix VL lookup command packing for P/Q/R/SVladimir Oltean1-4/+19
At the beginning of the sja1105_dynamic_config.c file there is a diagram of the dynamic config interface layout: packed_buf | V +-----------------------------------------+------------------+ | ENTRY BUFFER | COMMAND BUFFER | +-----------------------------------------+------------------+ <----------------------- packed_size ------------------------> So in order to pack/unpack the command bits into the buffer, sja1105_vl_lookup_cmd_packing must first advance the buffer pointer by the length of the entry. This is similar to what the other *cmd_packing functions do. This bug exists because the command packing function for P/Q/R/S was copied from the E/T generation, and on E/T, the command was actually embedded within the entry buffer itself. Fixes: 94f94d4acfb2 ("net: dsa: sja1105: add static tables for virtual links") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24net: hso: fix control-request directionsJohan Hovold1-2/+2
The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Fix the tiocmset and rfkill requests which erroneously used usb_rcvctrlpipe(). Fixes: 72dc1c096c70 ("HSO: add option hso driver") Cc: [email protected] # 2.6.27 Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24r8152: check the informaton of the deviceHayes Wang1-5/+37
Verify some fields of the USB descriptor to make sure the driver could be used by the device. Besides, remove the check of endpoint number in rtl8152_probe(). usb_find_common_endpoints() includes it. BugLink: https://syzkaller.appspot.com/bug?id=912c9c373656996801b4de61f1e3cb326fe940aa Reported-by: [email protected] Fixes: c2198943e33b ("r8152: search the configuration of vendor mode") Signed-off-by: Hayes Wang <[email protected]> Reviewed-by: Johan Hovold <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24sch_dsmark: fix a NULL deref in qdisc_reset()Taehee Yoo1-1/+2
If Qdisc_ops->init() is failed, Qdisc_ops->reset() would be called. When dsmark_init(Qdisc_ops->init()) is failed, it possibly doesn't initialize dsmark_qdisc_data->q. But dsmark_reset(Qdisc_ops->reset()) uses dsmark_qdisc_data->q pointer wihtout any null checking. So, panic would occur. Test commands: sysctl net.core.default_qdisc=dsmark -w ip link add dummy0 type dummy ip link add vw0 link dummy0 type virt_wifi ip link set vw0 up Splat looks like: KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 3 PID: 684 Comm: ip Not tainted 5.12.0+ #910 RIP: 0010:qdisc_reset+0x2b/0x680 Code: 1f 44 00 00 48 b8 00 00 00 00 00 fc ff df 41 57 41 56 41 55 41 54 55 48 89 fd 48 83 c7 18 53 48 89 fa 48 c1 ea 03 48 83 ec 20 <80> 3c 02 00 0f 85 09 06 00 00 4c 8b 65 18 0f 1f 44 00 00 65 8b 1d RSP: 0018:ffff88800fda6bf8 EFLAGS: 00010282 RAX: dffffc0000000000 RBX: ffff8880050ed800 RCX: 0000000000000000 RDX: 0000000000000003 RSI: ffffffff99e34100 RDI: 0000000000000018 RBP: 0000000000000000 R08: fffffbfff346b553 R09: fffffbfff346b553 R10: 0000000000000001 R11: fffffbfff346b552 R12: ffffffffc0824940 R13: ffff888109e83800 R14: 00000000ffffffff R15: ffffffffc08249e0 FS: 00007f5042287680(0000) GS:ffff888119800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055ae1f4dbd90 CR3: 0000000006760002 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? rcu_read_lock_bh_held+0xa0/0xa0 dsmark_reset+0x3d/0xf0 [sch_dsmark] qdisc_reset+0xa9/0x680 qdisc_destroy+0x84/0x370 qdisc_create_dflt+0x1fe/0x380 attach_one_default_qdisc.constprop.41+0xa4/0x180 dev_activate+0x4d5/0x8c0 ? __dev_open+0x268/0x390 __dev_open+0x270/0x390 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Taehee Yoo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-05-24Merge branch 'for-5.13-fixes' of ↵Linus Torvalds7-20/+17
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup Pull cgroup fixes from Tejun Heo: - "cgroup_disable=" boot param was being applied too late confusing some subsystems. Fix it by moving application to __setup() time. - Comment spelling fixes. Included here to lower the chance of trivial future merge conflicts. * 'for-5.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup: fix spelling mistakes cgroup: disable controllers at parse time
2021-05-24Merge branch 'for-5.13-fixes' of ↵Linus Torvalds1-2/+10
git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq Pull workqueue fix from Tejun Heo: "One commit to fix spurious workqueue stall warnings across VM suspensions" * 'for-5.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: wq: handle VM suspension in stall detection
2021-05-24Merge tag 'spi-fix-v5.13-rc3' of ↵Linus Torvalds9-24/+64
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi Pull spi fixes from Mark Brown: "There's some device specific fixes here but also an unusually large number of fixes for the core, including both fixes for breakage introduced on ACPI systems while fixing the long standing confusion about the polarity of GPIO chip selects specified through DT, and fixes for ordering issues on unregistration which have been exposed through the wider usage of devm_." * tag 'spi-fix-v5.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: sc18is602: implement .max_{transfer,message}_size() for the controller spi: sc18is602: don't consider the chip select byte in sc18is602_check_transfer MAINTAINERS: Add Alain Volmat as STM32 SPI maintainer dt-bindings: spi: spi-mux: rename flash node spi: Don't have controller clean up spi device before driver unbind spi: Assume GPIO CS active high in ACPI case spi: sprd: Add missing MODULE_DEVICE_TABLE spi: Switch to signed types for *_native_cs SPI controller fields spi: take the SPI IO-mutex in the spi_set_cs_timing method spi: spi-fsl-dspi: Fix a resource leak in an error handling path spi: spi-zynq-qspi: Fix stack violation bug spi: spi-zynq-qspi: Fix kernel-doc warning spi: altera: Make SPI_ALTERA_CORE invisible spi: Fix spi device unregister flow
Powered by cgit, Gruvboxed by Blaster4385.