aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-04-30MAINTAINERS: Add Vinod Koul as Generic PHY co-maintainerKishon Vijay Abraham I1-1/+2
Add Vinod Koul as Generic PHY Subsystem co-maintainer and move the linux-phy to a shared repository. Cc: Vinod Koul <[email protected]> Acked-By: Vinod Koul <[email protected]> Signed-off-by: Kishon Vijay Abraham I <[email protected]>
2020-04-30ALSA: opti9xx: shut up gcc-10 range warningArnd Bergmann2-6/+12
gcc-10 points out a few instances of suspicious integer arithmetic leading to value truncation: sound/isa/opti9xx/opti92x-ad1848.c: In function 'snd_opti9xx_configure': sound/isa/opti9xx/opti92x-ad1848.c:322:43: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_opti9xx_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow] 322 | (snd_opti9xx_read(chip, reg) & ~(mask)) | ((value) & (mask))) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/opti92x-ad1848.c:351:3: note: in expansion of macro 'snd_opti9xx_write_mask' 351 | snd_opti9xx_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff); | ^~~~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/miro.c: In function 'snd_miro_configure': sound/isa/opti9xx/miro.c:873:40: error: overflow in conversion from 'int' to 'unsigned char' changes value from '(int)snd_miro_read(chip, 3) & -256 | 240' to '240' [-Werror=overflow] 873 | (snd_miro_read(chip, reg) & ~(mask)) | ((value) & (mask))) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ sound/isa/opti9xx/miro.c:1010:3: note: in expansion of macro 'snd_miro_write_mask' 1010 | snd_miro_write_mask(chip, OPTi9XX_MC_REG(3), 0xf0, 0xff); | ^~~~~~~~~~~~~~~~~~~ These are all harmless here as only the low 8 bit are passed down anyway. Change the macros to inline functions to make the code more readable and also avoid the warning. Strictly speaking those functions also need locking to make the read/write pair atomic, but it seems unlikely that anyone would still run into that issue. Fixes: 1841f613fd2e ("[ALSA] Add snd-miro driver") Signed-off-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-04-30crypto: arch/nhpoly1305 - process in explicit 4k chunksJason A. Donenfeld4-4/+4
Rather than chunking via PAGE_SIZE, this commit changes the arch implementations to chunk in explicit 4k parts, so that calculations on maximum acceptable latency don't suddenly become invalid on platforms where PAGE_SIZE isn't 4k, such as arm64. Fixes: 0f961f9f670e ("crypto: x86/nhpoly1305 - add AVX2 accelerated NHPoly1305") Fixes: 012c82388c03 ("crypto: x86/nhpoly1305 - add SSE2 accelerated NHPoly1305") Fixes: a00fa0c88774 ("crypto: arm64/nhpoly1305 - add NEON-accelerated NHPoly1305") Fixes: 16aae3595a9d ("crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305") Cc: [email protected] Signed-off-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Eric Biggers <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-04-30crypto: arch/lib - limit simd usage to 4k chunksJason A. Donenfeld7-30/+65
The initial Zinc patchset, after some mailing list discussion, contained code to ensure that kernel_fpu_enable would not be kept on for more than a 4k chunk, since it disables preemption. The choice of 4k isn't totally scientific, but it's not a bad guess either, and it's what's used in both the x86 poly1305, blake2s, and nhpoly1305 code already (in the form of PAGE_SIZE, which this commit corrects to be explicitly 4k for the former two). Ard did some back of the envelope calculations and found that at 5 cycles/byte (overestimate) on a 1ghz processor (pretty slow), 4k means we have a maximum preemption disabling of 20us, which Sebastian confirmed was probably a good limit. Unfortunately the chunking appears to have been left out of the final patchset that added the glue code. So, this commit adds it back in. Fixes: 84e03fa39fbe ("crypto: x86/chacha - expose SIMD ChaCha routine as library function") Fixes: b3aad5bad26a ("crypto: arm64/chacha - expose arm64 ChaCha routine as library function") Fixes: a44a3430d71b ("crypto: arm/chacha - expose ARM ChaCha routine as library function") Fixes: d7d7b8535662 ("crypto: x86/poly1305 - wire up faster implementations for kernel") Fixes: f569ca164751 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") Fixes: a6b803b3ddc7 ("crypto: arm/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation") Fixes: ed0356eda153 ("crypto: blake2s - x86_64 SIMD implementation") Cc: Eric Biggers <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Cc: [email protected] Signed-off-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-04-29Merge branch 'wireguard-fixes'David S. Miller3-6/+5
Jason A. Donenfeld says: ==================== wireguard fixes for 5.7-rc4 This series contains two fixes and a cleanup for wireguard: 1) Removal of a spurious newline, from Sultan Alsawaf. 2) Fix for a memory leak in an error path, in which memory allocated prior to the error wasn't freed, reported by Sultan Alsawaf. 3) Fix to ECN support to use RFC6040 properly like all the other tunnel drivers, from Toke Høiland-Jørgensen. ==================== Signed-off-by: David S. Miller <[email protected]>
2020-04-29wireguard: receive: use tunnel helpers for decapsulating ECN markingsToke Høiland-Jørgensen1-4/+2
WireGuard currently only propagates ECN markings on tunnel decap according to the old RFC3168 specification. However, the spec has since been updated in RFC6040 to recommend slightly different decapsulation semantics. This was implemented in the kernel as a set of common helpers for ECN decapsulation, so let's just switch over WireGuard to using those, so it can benefit from this enhancement and any future tweaks. We do not drop packets with invalid ECN marking combinations, because WireGuard is frequently used to work around broken ISPs, which could be doing that. Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Reported-by: Olivier Tilmans <[email protected]> Cc: Dave Taht <[email protected]> Cc: Rodney W. Grimes <[email protected]> Signed-off-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-29wireguard: queueing: cleanup ptr_ring in error path of packet_queue_initJason A. Donenfeld1-1/+3
Prior, if the alloc_percpu of packet_percpu_multicore_worker_alloc failed, the previously allocated ptr_ring wouldn't be freed. This commit adds the missing call to ptr_ring_cleanup in the error case. Reported-by: Sultan Alsawaf <[email protected]> Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-29wireguard: send: remove errant newline from packet_encrypt_workerSultan Alsawaf1-1/+0
This commit removes a useless newline at the end of a scope, which doesn't add anything in the way of organization or readability. Signed-off-by: Sultan Alsawaf <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-29platform/chrome: cros_ec_sensorhub: Allocate sensorhub resource before ↵Gwendal Grignou3-61/+93
claiming sensors Allocate callbacks array before enumerating the sensors: The probe routine for these sensors (for instance cros_ec_sensors_probe) can be called within the sensorhub probe routine (cros_ec_sensors_probe()) Fixes: 145d59baff594 ("platform/chrome: cros_ec_sensorhub: Add FIFO support") Signed-off-by: Gwendal Grignou <[email protected]> Reported-by: Douglas Anderson <[email protected]> Tested-by: Douglas Anderson <[email protected]> Signed-off-by: Enric Balletbo i Serra <[email protected]>
2020-04-29HID: mcp2221: add gpiolib dependencyArnd Bergmann1-0/+1
Without gpiolib, this driver fails to link: arm-linux-gnueabi-ld: drivers/hid/hid-mcp2221.o: in function `mcp2221_probe': hid-mcp2221.c:(.text+0x1b0): undefined reference to `devm_gpiochip_add_data' arm-linux-gnueabi-ld: drivers/hid/hid-mcp2221.o: in function `mcp_gpio_get': hid-mcp2221.c:(.text+0x30c): undefined reference to `gpiochip_get_data' Fixes: 328de1c519c5 ("HID: mcp2221: add GPIO functionality support") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Rishi Gupta <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2020-04-29HID: i2c-hid: reset Synaptics SYNA2393 on resumeDaniel Playfair Cal2-0/+5
On the Dell XPS 9570, the Synaptics SYNA2393 touchpad generates spurious interrupts after resuming from suspend until it receives some input or is reset. Add it to the quirk I2C_HID_QUIRK_RESET_ON_RESUME so that it is reset when resuming from suspend. More information about the bug can be found in this mailing list discussion: https://www.spinics.net/lists/linux-input/msg59530.html Signed-off-by: Daniel Playfair Cal <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2020-04-29HID: wacom: Report 2nd-gen Intuos Pro S center button status over BTJason Gerecke1-3/+6
The state of the center button was not reported to userspace for the 2nd-gen Intuos Pro S when used over Bluetooth due to the pad handling code not being updated to support its reduced number of buttons. This patch uses the actual number of buttons present on the tablet to assemble a button state bitmap. Link: https://github.com/linuxwacom/xf86-input-wacom/issues/112 Fixes: cd47de45b855 ("HID: wacom: Add 2nd gen Intuos Pro Small support") Signed-off-by: Jason Gerecke <[email protected]> Cc: [email protected] # v5.3+ Signed-off-by: Jiri Kosina <[email protected]>
2020-04-29mptcp: replace mptcp_disconnect with a stubFlorian Westphal1-5/+6
Paolo points out that mptcp_disconnect is bogus: "lock_sock(sk); looks suspicious (lock should be already held by the caller) And call to: tcp_disconnect(sk, flags); too, sk is not a tcp socket". ->disconnect() gets called from e.g. inet_stream_connect when one tries to disassociate a connected socket again (to re-connect without closing the socket first). MPTCP however uses mptcp_stream_connect, not inet_stream_connect, for the mptcp-socket connect call. inet_stream_connect only gets called indirectly, for the tcp socket, so any ->disconnect() calls end up calling tcp_disconnect for that tcp subflow sk. This also explains why syzkaller has not yet reported a problem here. So for now replace this with a stub that doesn't do anything. Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/14 Acked-by: Paolo Abeni <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-29netfilter: nf_osf: avoid passing pointer to local varArnd Bergmann1-5/+7
gcc-10 points out that a code path exists where a pointer to a stack variable may be passed back to the caller: net/netfilter/nfnetlink_osf.c: In function 'nf_osf_hdr_ctx_init': cc1: warning: function may return address of local variable [-Wreturn-local-addr] net/netfilter/nfnetlink_osf.c:171:16: note: declared here 171 | struct tcphdr _tcph; | ^~~~~ I am not sure whether this can happen in practice, but moving the variable declaration into the callers avoids the problem. Fixes: 31a9c29210e2 ("netfilter: nf_osf: add struct nf_osf_hdr_ctx") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Florian Westphal <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2020-04-29net: dsa: mv88e6xxx: remove duplicate assignment of struct membersJason Yan1-4/+0
These struct members named 'phylink_validate' was assigned twice: static const struct mv88e6xxx_ops mv88e6190_ops = { ...... .phylink_validate = mv88e6390_phylink_validate, ...... .phylink_validate = mv88e6390_phylink_validate, }; static const struct mv88e6xxx_ops mv88e6190x_ops = { ...... .phylink_validate = mv88e6390_phylink_validate, ...... .phylink_validate = mv88e6390x_phylink_validate, }; static const struct mv88e6xxx_ops mv88e6191_ops = { ...... .phylink_validate = mv88e6390_phylink_validate, ...... .phylink_validate = mv88e6390_phylink_validate, }; static const struct mv88e6xxx_ops mv88e6290_ops = { ...... .phylink_validate = mv88e6390_phylink_validate, ...... .phylink_validate = mv88e6390_phylink_validate, }; Remove all the first one and leave the second one which are been used in fact. Be aware that for 'mv88e6190x_ops' the assignment functions is different while the others are all the same. This fixes the following coccicheck warning: drivers/net/dsa/mv88e6xxx/chip.c:3911:48-49: phylink_validate: first occurrence line 3965, second occurrence line 3967 drivers/net/dsa/mv88e6xxx/chip.c:3970:49-50: phylink_validate: first occurrence line 4024, second occurrence line 4026 drivers/net/dsa/mv88e6xxx/chip.c:4029:48-49: phylink_validate: first occurrence line 4082, second occurrence line 4085 drivers/net/dsa/mv88e6xxx/chip.c:4184:48-49: phylink_validate: first occurrence line 4238, second occurrence line 4242 Fixes: 4262c38dc42e ("net: dsa: mv88e6xxx: Add SERDES stats counters to all 6390 family members") Signed-off-by: Jason Yan <[email protected]> Reviewed-by: Russell King <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-29regulator: Revert "Use driver_deferred_probe_timeout for ↵John Stultz1-14/+11
regulator_init_complete_work" This reverts commit dca0b44957e5 ("regulator: Use driver_deferred_probe_timeout for regulator_init_complete_work"), as we ended up reverting the default deferred_probe_timeout value back to zero, to preserve behavior with 5.6 we need to decouple the regulator timeout which was previously 30 seconds. This avoids breaking some systems that depend on the regulator timeout but don't require the deferred probe timeout. Cc: [email protected] Cc: Linus Walleij <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Liam Girdwood <[email protected]> Cc: Bjorn Andersson <[email protected]> Cc: Saravana Kannan <[email protected]> Cc: Todd Kjos <[email protected]> Cc: Len Brown <[email protected]> Cc: Pavel Machek <[email protected]> Cc: Ulf Hansson <[email protected]> Cc: Kevin Hilman <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Rob Herring <[email protected]> Reported-by: Marek Szyprowski <[email protected]> Suggested-by: Mark Brown <[email protected]> Signed-off-by: John Stultz <[email protected]> Reviewed-by: Mark Brown <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-29Merge tag 'riscv-for-linus-5.7-rc4' of ↵Linus Torvalds6-15/+18
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: "A handful of fixes. Specifically: - fix linker argument to allow linking with lld - build fix for configurations without a frame pointer - a handful of build fixes related the SBI 0.1 vs 0.2 split - remove STRICT_KERNEL_RWX for !MMU, which isn't useful" * tag 'riscv-for-linus-5.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: select ARCH_HAS_STRICT_KERNEL_RWX only if MMU riscv: sbi: Fix undefined reference to sbi_shutdown tty: riscv: Using RISCV_SBI_V01 instead of RISCV_SBI riscv: sbi: Correct sbi_shutdown() and sbi_clear_ipi() export riscv: fix vdso build with lld RISC-V: stacktrace: Declare sp_in_global outside ifdef
2020-04-29Merge branch 'linus' of ↵Linus Torvalds3-7/+19
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fixes from Herbert Xu: "This fixes a bunch of bugs detected by KASAN in the caam driver" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: caam - fix the address of the last entry of S/G crypto: caam - fix use-after-free KASAN issue for RSA algorithms crypto: caam - fix use-after-free KASAN issue for HASH algorithms crypto: caam - fix use-after-free KASAN issue for AEAD algorithms crypto: caam - fix use-after-free KASAN issue for SKCIPHER algorithms
2020-04-29HID: usbhid: Fix race between usbhid_close() and usbhid_stop()Alan Stern2-8/+30
The syzbot fuzzer discovered a bad race between in the usbhid driver between usbhid_stop() and usbhid_close(). In particular, usbhid_stop() does: usb_free_urb(usbhid->urbin); ... usbhid->urbin = NULL; /* don't mess up next start */ and usbhid_close() does: usb_kill_urb(usbhid->urbin); with no mutual exclusion. If the two routines happen to run concurrently so that usb_kill_urb() is called in between the usb_free_urb() and the NULL assignment, it will access the deallocated urb structure -- a use-after-free bug. This patch adds a mutex to the usbhid private structure and uses it to enforce mutual exclusion of the usbhid_start(), usbhid_stop(), usbhid_open() and usbhid_close() callbacks. Reported-and-tested-by: [email protected] Signed-off-by: Alan Stern <[email protected]> CC: <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2020-04-29iommu: spapr_tce: Disable compile testing to fix build on book3s_32 configKrzysztof Kozlowski1-1/+1
Although SPAPR_TCE_IOMMU itself can be compile tested on certain PowerPC configurations, its presence makes arch/powerpc/kvm/Makefile to select modules which do not build in such configuration. The arch/powerpc/kvm/ modules use kvm_arch.spapr_tce_tables which exists only with CONFIG_PPC_BOOK3S_64. However these modules are selected when COMPILE_TEST and SPAPR_TCE_IOMMU are chosen leading to build failures: In file included from arch/powerpc/include/asm/book3s/64/mmu-hash.h:20:0, from arch/powerpc/kvm/book3s_64_vio_hv.c:22: arch/powerpc/include/asm/book3s/64/pgtable.h:17:0: error: "_PAGE_EXEC" redefined [-Werror] #define _PAGE_EXEC 0x00001 /* execute permission */ In file included from arch/powerpc/include/asm/book3s/32/pgtable.h:8:0, from arch/powerpc/include/asm/book3s/pgtable.h:8, from arch/powerpc/include/asm/pgtable.h:18, from include/linux/mm.h:95, from arch/powerpc/include/asm/io.h:29, from include/linux/io.h:13, from include/linux/irq.h:20, from arch/powerpc/include/asm/hardirq.h:6, from include/linux/hardirq.h:9, from include/linux/kvm_host.h:7, from arch/powerpc/kvm/book3s_64_vio_hv.c:12: arch/powerpc/include/asm/book3s/32/hash.h:29:0: note: this is the location of the previous definition #define _PAGE_EXEC 0x200 /* software: exec allowed */ Fixes: e93a1695d7fb ("iommu: Enable compile testing for some of drivers") Reported-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2020-04-29iommu/mediatek: Fix MTK_IOMMU dependenciesGeert Uytterhoeven1-1/+1
If NO_DMA=y (e.g. Sun-3 all{mod,yes}-config): drivers/iommu/dma-iommu.o: In function `iommu_dma_mmap': dma-iommu.c:(.text+0x836): undefined reference to `dma_pgprot' IOMMU_DMA must not be selected, unless HAS_DMA=y. Hence fix this by making MTK_IOMMU depend on HAS_DMA. While at it, remove the dependency on ARM || ARM64, as that is already implied by the dependency on ARCH_MEDIATEK. Fixes: e93a1695d7fb5513 ("iommu: Enable compile testing for some of drivers") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2020-04-29iommu: Fix the memory leak in dev_iommu_free()Kevin Hao1-0/+1
In iommu_probe_device(), we would invoke dev_iommu_free() to free the dev->iommu after the ->add_device() returns failure. But after commit 72acd9df18f1 ("iommu: Move iommu_fwspec to struct dev_iommu"), we also need to free the iommu_fwspec before the dev->iommu is freed. This fixes the following memory leak reported by kmemleak: unreferenced object 0xffff000bc836c700 (size 128): comm "swapper/0", pid 1, jiffies 4294896304 (age 782.120s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 d8 cd 9b ff 0b 00 ff ff ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000df34077b>] kmem_cache_alloc_trace+0x244/0x4b0 [<000000000e560ac0>] iommu_fwspec_init+0x7c/0xb0 [<0000000075eda275>] of_iommu_xlate+0x80/0xe8 [<00000000728d6bf9>] of_pci_iommu_init+0xb0/0xb8 [<00000000d001fe6f>] pci_for_each_dma_alias+0x48/0x190 [<000000006db6bbce>] of_iommu_configure+0x1ac/0x1d0 [<00000000634745f8>] of_dma_configure+0xdc/0x220 [<000000002cbc8ba0>] pci_dma_configure+0x50/0x78 [<00000000cdf6e193>] really_probe+0x8c/0x340 [<00000000fddddc46>] driver_probe_device+0x60/0xf8 [<0000000061bcdb51>] __device_attach_driver+0x8c/0xd0 [<000000009b9ff58e>] bus_for_each_drv+0x80/0xd0 [<000000004b9c8aa3>] __device_attach+0xec/0x148 [<00000000a5c13bf3>] device_attach+0x1c/0x28 [<000000005071e151>] pci_bus_add_device+0x58/0xd0 [<000000002d4f87d1>] pci_bus_add_devices+0x40/0x90 Fixes: 72acd9df18f1 ("iommu: Move iommu_fwspec to struct dev_iommu") Signed-off-by: Kevin Hao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2020-04-29drm/qxl: qxl_release use after freeVasily Averin4-11/+7
qxl_release should not be accesses after qxl_push_*_ring_release() calls: userspace driver can process submitted command quickly, move qxl_release into release_ring, generate interrupt and trigger garbage collector. It can lead to crashes in qxl driver or trigger memory corruption in some kmalloc-192 slab object Gerd Hoffmann proposes to swap the qxl_release_fence_buffer_objects() + qxl_push_{cursor,command}_ring_release() calls to close that race window. cc: [email protected] Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)") Signed-off-by: Vasily Averin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
2020-04-29drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()Vasily Averin1-1/+2
v2: removed TODO reminder Signed-off-by: Vasily Averin <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
2020-04-29interconnect: qcom: Move the static keyword to the front of declarationChenTao2-10/+10
Fix the following warning: Move the static keyword to the front of declaration of sdm845_icc_osm_l3 sdm845_aggre1_noc sc7180_icc_osm_l3 sdm845_aggre2_noc sdm845_config_noc sdm845_dc_noc sdm845_gladiator_noc sdm845_mem_noc sdm845_mmss_noc and sdm845_system_noc, resolve the following compiler warning that can be when building with warnings enabled (W=1): drivers/interconnect/qcom/osm-l3.c:81:1: warning: const static struct qcom_icc_desc sdm845_icc_osm_l3 = { drivers/interconnect/qcom/osm-l3.c:94:1: warning: const static struct qcom_icc_desc sc7180_icc_osm_l3 = { drivers/interconnect/qcom/sdm845.c:195:1: warning: const static struct qcom_icc_desc sdm845_aggre1_noc = { drivers/interconnect/qcom/sdm845.c:223:1: warning: const static struct qcom_icc_desc sdm845_aggre2_noc = { drivers/interconnect/qcom/sdm845.c:284:1: warning: const static struct qcom_icc_desc sdm845_config_noc = { drivers/interconnect/qcom/sdm845.c:300:1: warning: const static struct qcom_icc_desc sdm845_dc_noc = { drivers/interconnect/qcom/sdm845.c:318:1: warning: const static struct qcom_icc_desc sdm845_gladiator_noc = { drivers/interconnect/qcom/sdm845.c:353:1: warning: const static struct qcom_icc_desc sdm845_mem_noc = { drivers/interconnect/qcom/sdm845.c:387:1: warning: const static struct qcom_icc_desc sdm845_mmss_noc = { drivers/interconnect/qcom/sdm845.c:433:1: warning: const static struct qcom_icc_desc sdm845_system_noc = { Reported-by: Hulk Robot <[email protected]> Signed-off-by: ChenTao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-29MAINTAINERS: remove entry after hp100 driver removalLukas Bulwahn1-5/+0
Commit a10079c66290 ("staging: remove hp100 driver") removed all files from ./drivers/staging/hp/, but missed to adjust MAINTAINERS. Since then, ./scripts/get_maintainer.pl --self-test=patterns complains: warning: no file matches F: drivers/staging/hp/hp100.* So, drop HP100 Driver entry in MAINTAINERS now. Signed-off-by: Lukas Bulwahn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-29ALSA: hda/hdmi: fix without unlocked before returnWu Bo1-1/+3
Fix the following coccicheck warning: sound/pci/hda/patch_hdmi.c:1852:2-8: preceding lock on line 1846 After add sanity check to pass klockwork check, The spdif_mutex should be unlock before return true in check_non_pcm_per_cvt(). Fixes: 960a581e22d9 ("ALSA: hda: fix some klockwork scan warnings") Signed-off-by: Wu Bo <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2020-04-28scsi: ibmvscsi: Fix WARN_ON during event pool releaseTyrel Datwyler1-4/+0
While removing an ibmvscsi client adapter a WARN_ON like the following is seen in the kernel log: drmgr: drmgr: -r -c slot -s U9080.M9S.783AEC8-V11-C11 -w 5 -d 1 WARNING: CPU: 9 PID: 24062 at ../kernel/dma/mapping.c:311 dma_free_attrs+0x78/0x110 Supported: No, Unreleased kernel CPU: 9 PID: 24062 Comm: drmgr Kdump: loaded Tainted: G X 5.3.18-12-default NIP: c0000000001fa758 LR: c0000000001fa744 CTR: c0000000001fa6e0 REGS: c0000002173375d0 TRAP: 0700 Tainted: G X (5.3.18-12-default) MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 28088282 XER: 20000000 CFAR: c0000000001fbf0c IRQMASK: 1 GPR00: c0000000001fa744 c000000217337860 c00000000161ab00 0000000000000000 GPR04: 0000000000000000 c000011e12250000 0000000018010000 0000000000000000 GPR08: 0000000000000000 0000000000000001 0000000000000001 c0080000190f4fa8 GPR12: c0000000001fa6e0 c000000007fc2a00 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 000000011420e310 0000000000000000 0000000000000000 0000000018010000 GPR28: c00000000159de50 c000011e12250000 0000000000006600 c000011e5c994848 NIP [c0000000001fa758] dma_free_attrs+0x78/0x110 LR [c0000000001fa744] dma_free_attrs+0x64/0x110 Call Trace: [c000000217337860] [000000011420e310] 0x11420e310 (unreliable) [c0000002173378b0] [c0080000190f0280] release_event_pool+0xd8/0x120 [ibmvscsi] [c000000217337930] [c0080000190f3f74] ibmvscsi_remove+0x6c/0x160 [ibmvscsi] [c000000217337960] [c0000000000f3cac] vio_bus_remove+0x5c/0x100 [c0000002173379a0] [c00000000087a0a4] device_release_driver_internal+0x154/0x280 [c0000002173379e0] [c0000000008777cc] bus_remove_device+0x11c/0x220 [c000000217337a60] [c000000000870fc4] device_del+0x1c4/0x470 [c000000217337b10] [c0000000008712a0] device_unregister+0x30/0xa0 [c000000217337b80] [c0000000000f39ec] vio_unregister_device+0x2c/0x60 [c000000217337bb0] [c00800001a1d0964] dlpar_remove_slot+0x14c/0x250 [rpadlpar_io] [c000000217337c50] [c00800001a1d0bcc] remove_slot_store+0xa4/0x110 [rpadlpar_io] [c000000217337cd0] [c000000000c091a0] kobj_attr_store+0x30/0x50 [c000000217337cf0] [c00000000057c934] sysfs_kf_write+0x64/0x90 [c000000217337d10] [c00000000057be10] kernfs_fop_write+0x1b0/0x290 [c000000217337d60] [c000000000488c4c] __vfs_write+0x3c/0x70 [c000000217337d80] [c00000000048c648] vfs_write+0xd8/0x260 [c000000217337dd0] [c00000000048ca8c] ksys_write+0xdc/0x130 [c000000217337e20] [c00000000000b488] system_call+0x5c/0x70 Instruction dump: 7c840074 f8010010 f821ffb1 20840040 eb830218 7c8407b4 48002019 60000000 2fa30000 409e003c 892d0988 792907e0 <0b090000> 2fbd0000 419e0028 2fbc0000 ---[ end trace 5955b3c0cc079942 ]--- rpadlpar_io: slot U9080.M9S.783AEC8-V11-C11 removed This is tripped as a result of irqs being disabled during the call to dma_free_coherent() by release_event_pool(). At this point in the code path we have quiesced the adapter and it is overly paranoid to be holding the host lock. [mkp: fixed build warning reported by sfr] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tyrel Datwyler <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-04-28dm multipath: use updated MPATHF_QUEUE_IO on mapping for bio-based mpathGabriel Krisman Bertazi1-2/+4
When adding devices that don't have a scsi_dh on a BIO based multipath, I was able to consistently hit the warning below and lock-up the system. The problem is that __map_bio reads the flag before it potentially being modified by choose_pgpath, and ends up using the older value. The WARN_ON below is not trivially linked to the issue. It goes like this: The activate_path delayed_work is not initialized for non-scsi_dh devices, but we always set MPATHF_QUEUE_IO, asking for initialization. That is fine, since MPATHF_QUEUE_IO would be cleared in choose_pgpath. Nevertheless, only for BIO-based mpath, we cache the flag before calling choose_pgpath, and use the older version when deciding if we should initialize the path. Therefore, we end up trying to initialize the paths, and calling the non-initialized activate_path work. [ 82.437100] ------------[ cut here ]------------ [ 82.437659] WARNING: CPU: 3 PID: 602 at kernel/workqueue.c:1624 __queue_delayed_work+0x71/0x90 [ 82.438436] Modules linked in: [ 82.438911] CPU: 3 PID: 602 Comm: systemd-udevd Not tainted 5.6.0-rc6+ #339 [ 82.439680] RIP: 0010:__queue_delayed_work+0x71/0x90 [ 82.440287] Code: c1 48 89 4a 50 81 ff 00 02 00 00 75 2a 4c 89 cf e9 94 d6 07 00 e9 7f e9 ff ff 0f 0b eb c7 0f 0b 48 81 7a 58 40 74 a8 94 74 a7 <0f> 0b 48 83 7a 48 00 74 a5 0f 0b eb a1 89 fe 4c 89 cf e9 c8 c4 07 [ 82.441719] RSP: 0018:ffffb738803977c0 EFLAGS: 00010007 [ 82.442121] RAX: ffffa086389f9740 RBX: 0000000000000002 RCX: 0000000000000000 [ 82.442718] RDX: ffffa086350dd930 RSI: ffffa0863d76f600 RDI: 0000000000000200 [ 82.443484] RBP: 0000000000000200 R08: 0000000000000000 R09: ffffa086350dd970 [ 82.444128] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa086350dd930 [ 82.444773] R13: ffffa0863d76f600 R14: 0000000000000000 R15: ffffa08636738008 [ 82.445427] FS: 00007f6abfe9dd40(0000) GS:ffffa0863dd80000(0000) knlGS:00000 [ 82.446040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 82.446478] CR2: 0000557d288db4e8 CR3: 0000000078b36000 CR4: 00000000000006e0 [ 82.447104] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 82.447561] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 82.448012] Call Trace: [ 82.448164] queue_delayed_work_on+0x6d/0x80 [ 82.448472] __pg_init_all_paths+0x7b/0xf0 [ 82.448714] pg_init_all_paths+0x26/0x40 [ 82.448980] __multipath_map_bio.isra.0+0x84/0x210 [ 82.449267] __map_bio+0x3c/0x1f0 [ 82.449468] __split_and_process_non_flush+0x14a/0x1b0 [ 82.449775] __split_and_process_bio+0xde/0x340 [ 82.450045] ? dm_get_live_table+0x5/0xb0 [ 82.450278] dm_process_bio+0x98/0x290 [ 82.450518] dm_make_request+0x54/0x120 [ 82.450778] generic_make_request+0xd2/0x3e0 [ 82.451038] ? submit_bio+0x3c/0x150 [ 82.451278] submit_bio+0x3c/0x150 [ 82.451492] mpage_readpages+0x129/0x160 [ 82.451756] ? bdev_evict_inode+0x1d0/0x1d0 [ 82.452033] read_pages+0x72/0x170 [ 82.452260] __do_page_cache_readahead+0x1ba/0x1d0 [ 82.452624] force_page_cache_readahead+0x96/0x110 [ 82.452903] generic_file_read_iter+0x84f/0xae0 [ 82.453192] ? __seccomp_filter+0x7c/0x670 [ 82.453547] new_sync_read+0x10e/0x190 [ 82.453883] vfs_read+0x9d/0x150 [ 82.454172] ksys_read+0x65/0xe0 [ 82.454466] do_syscall_64+0x4e/0x210 [ 82.454828] entry_SYSCALL_64_after_hwframe+0x49/0xbe [...] [ 82.462501] ---[ end trace bb39975e9cf45daa ]--- Cc: [email protected] Signed-off-by: Gabriel Krisman Bertazi <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2020-04-28drm/i915: Use proper fault mask in interrupt postinstall tooMatt Roper1-4/+2
The IRQ postinstall handling had open-coded pipe fault mask selection that never got updated for gen11. Switch it to use gen8_de_pipe_fault_mask() to ensure we don't miss updates for new platforms. Cc: José Roberto de Souza <[email protected]> Fixes: d506a65d56fd ("drm/i915: Catch GTT fault errors for gen11+ planes") Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Ville Syrjälä <[email protected]> (cherry picked from commit 869129ee0c624a78c74e50b51635e183196cd2c6) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-04-28Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds2-20/+16
Pull vfs fixes from Al Viro: "Two old bugs..." * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: propagate_one(): mnt_set_mountpoint() needs mount_lock dlmfs_file_write(): fix the bogosity in handling non-zero *ppos
2020-04-28Fix use after free in get_tree_bdev()David Howells1-1/+1
Commit 6fcf0c72e4b9, a fix to get_tree_bdev() put a missing blkdev_put() in the wrong place, before a warnf() that displays the bdev under consideration rather after it. This results in a silent lockup in printk("%pg") called via warnf() from get_tree_bdev() under some circumstances when there's a race with the blockdev being frozen. This can be caused by xfstests/tests/generic/085 in combination with Lukas Czerner's ext4 mount API conversion patchset. It looks like it ought to occur with other users of get_tree_bdev() such as XFS, but apparently doesn't. Fix this by switching the order of the lines. Fixes: 6fcf0c72e4b9 ("vfs: add missing blkdev_put() in get_tree_bdev()") Reported-by: Lukas Czerner <[email protected]> Signed-off-by: David Howells <[email protected]> cc: Ian Kent <[email protected]> cc: Al Viro <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-04-28net/x25: Fix null-ptr-deref in x25_disconnectYueHaibing1-4/+6
We should check null before do x25_neigh_put in x25_disconnect, otherwise may cause null-ptr-deref like this: #include <sys/socket.h> #include <linux/x25.h> int main() { int sck_x25; sck_x25 = socket(AF_X25, SOCK_SEQPACKET, 0); close(sck_x25); return 0; } BUG: kernel NULL pointer dereference, address: 00000000000000d8 CPU: 0 PID: 4817 Comm: t2 Not tainted 5.7.0-rc3+ #159 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3- RIP: 0010:x25_disconnect+0x91/0xe0 Call Trace: x25_release+0x18a/0x1b0 __sock_release+0x3d/0xc0 sock_close+0x13/0x20 __fput+0x107/0x270 ____fput+0x9/0x10 task_work_run+0x6d/0xb0 exit_to_usermode_loop+0x102/0x110 do_syscall_64+0x23c/0x260 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Reported-by: [email protected] Fixes: 4becb7ee5b3d ("net/x25: Fix x25_neigh refcnt leak when x25 disconnect") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-28net/ena: Fix build warning in ena_xdp_set()Gavin Shan1-1/+1
This fixes the following build warning in ena_xdp_set(), which is observed on aarch64 with 64KB page size. In file included from ./include/net/inet_sock.h:19, from ./include/net/ip.h:27, from drivers/net/ethernet/amazon/ena/ena_netdev.c:46: drivers/net/ethernet/amazon/ena/ena_netdev.c: In function \ ‘ena_xdp_set’: \ drivers/net/ethernet/amazon/ena/ena_netdev.c:557:6: warning: \ format ‘%lu’ \ expects argument of type ‘long unsigned int’, but argument 4 \ has type ‘int’ \ [-Wformat=] "Failed to set xdp program, the current MTU (%d) is \ larger than the maximum allowed MTU (%lu) while xdp is on", Signed-off-by: Gavin Shan <[email protected]> Acked-by: Shay Agroskin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-28drm/amd/display: Use cursor locking to prevent flip delaysAric Cyr16-45/+88
[Why] Current locking scheme for cursor can result in a flip missing its vsync, deferring it for one or more vsyncs. Result is a potential for stuttering when cursor is moved. [How] Use cursor update lock so that flips are not blocked while cursor is being programmed. Signed-off-by: Aric Cyr <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Aurabindo Pillai <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-04-28drm/amd/display: Update downspread percent to match spreadsheet for DCN2.1Sung Lee1-1/+1
[WHY] The downspread percentage was copied over from a previous version of the display_mode_lib spreadsheet. This value has been updated, and the previous value is too high to allow for such modes as 4K120hz. The new value is sufficient for such modes. [HOW] Update the value in dcn21_resource to match the spreadsheet. Signed-off-by: Sung Lee <[email protected]> Reviewed-by: Yongqiang Sun <[email protected]> Acked-by: Aurabindo Pillai <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-04-28drm/amd/display: Defer cursor update around VUPDATE for all ASICNicholas Kazlauskas1-14/+14
[Why] Fixes the following scenario: - Flip has been prepared sometime during the frame, update pending - Cursor update happens right when VUPDATE would happen - OPTC lock acquired, VUPDATE is blocked until next frame - Flip is delayed potentially infinitely With the igt@kms_cursor_legacy cursor-vs-flip-legacy test we can observe nearly *13* frames of delay for some flips on Navi. [How] Apply the Raven workaround generically. When close enough to VUPDATE block cursor updates from occurring from the dc_stream_set_cursor_* helpers. This could perhaps be a little smarter by checking if there were pending updates or flips earlier in the frame on the HUBP side before applying the delay, but this should be fine for now. This fixes the kms_cursor_legacy test. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Aurabindo Pillai <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-04-28drm/amd/display: fix rn soc bb updateDmytro Laktyushkin1-43/+28
Currently RN SOC bounding box update assumes we will get at least 2 clock states from SMU. This isn't always true and because of special casing on first clock state we end up with low disp, dpp, dsc and phy clocks. This change removes the special casing allowing the first state to acquire correct clocks. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Eric Yang <[email protected]> Acked-by: Aurabindo Pillai <[email protected]> Acked-by: Tony Cheng <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-04-28drm/amd/display: check if REFCLK_CNTL register is presentDmytro Laktyushkin1-1/+2
Check before programming the register since it isn't present on all IPs using this code. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Eric Bernstein <[email protected]> Acked-by: Aurabindo Pillai <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-04-28Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds11-32/+47
Pull rdma fixes from Jason Gunthorpe: "A couple of regressions were found in rc1, as well as another set of races and bugs: - A regression where RDMA_CM_EVENT_REJECTED was lost in some cases - Bad error handling in the CM, uverbs, rvt, siw and i40iw - Kernel stack memory leak to user space in mlx4 - Missing data in a uapi query for mlx5 - Three races found by syzkaller in the ib core code" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: RDMA/core: Fix race between destroy and release FD object IB/rdmavt: Always return ERR_PTR from rvt_create_mmap_info() RDMA/core: Fix overwriting of uobj in case of error RDMA/core: Prevent mixed use of FDs between shared ufiles RDMA/uverbs: Fix a race with disassociate and exit_mmap() RDMA/mlx5: Set GRH fields in query QP on RoCE RDMA/siw: Fix potential siw_mem refcnt leak in siw_fastreg_mr() RDMA/mlx4: Initialize ib_spec on the stack RDMA/cm: Fix an error check in cm_alloc_id_priv() RDMA/cm: Fix missing RDMA_CM_EVENT_REJECTED event after receiving REJ message i40iw: fix null pointer dereference on a null wqe pointer
2020-04-28Merge tag 'nfs-rdma-for-5.7-2' of ↵Trond Myklebust3-13/+17
git://git.linux-nfs.org/projects/anna/linux-nfs NFSoRDMA Client Fixes for Linux 5.7 Bugfixes: - Restore wake-up-all to rpcrdma_cm_event_handler() - Otherwise the client won't respond to server disconnect requests - Fix tracepoint use-after-free race - Fix usage of xdr_stream_encode_item_{present, absent} - These functions return a size on success, and not 0 Signed-off-by: Trond Myklebust <[email protected]>
2020-04-28NFSv4.1: fix handling of backchannel binding in BIND_CONN_TO_SESSIONOlga Kornievskaia3-0/+15
Currently, if the client sends BIND_CONN_TO_SESSION with NFS4_CDFC4_FORE_OR_BOTH but only gets NFS4_CDFS4_FORE back it ignores that it wasn't able to enable a backchannel. To make sure, the client sends BIND_CONN_TO_SESSION as the first operation on the connections (ie., no other session compounds haven't been sent before), and if the client's request to bind the backchannel is not satisfied, then reset the connection and retry. Cc: [email protected] Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
2020-04-28SUNRPC: defer slow parts of rpc_free_client() to a workqueue.NeilBrown2-5/+24
The rpciod workqueue is on the write-out path for freeing dirty memory, so it is important that it never block waiting for memory to be allocated - this can lead to a deadlock. rpc_execute() - which is often called by an rpciod work item - calls rcp_task_release_client() which can lead to rpc_free_client(). rpc_free_client() makes two calls which could potentially block wating for memory allocation. rpc_clnt_debugfs_unregister() calls into debugfs and will block while any of the debugfs files are being accessed. In particular it can block while any of the 'open' methods are being called and all of these use malloc for one thing or another. So this can deadlock if the memory allocation waits for NFS to complete some writes via rpciod. rpc_clnt_remove_pipedir() can take the inode_lock() and while it isn't obvious that memory allocations can happen while the lock it held, it is safer to assume they might and to not let rpciod call rpc_clnt_remove_pipedir(). So this patch moves these two calls (together with the final kfree() and rpciod_down()) into a work-item to be run from the system work-queue. rpciod can continue its important work, and the final stages of the free can happen whenever they happen. I have seen this deadlock on a 4.12 based kernel where debugfs used synchronize_srcu() when removing objects. synchronize_srcu() requires a workqueue and there were no free workther threads and none could be allocated. While debugsfs no longer uses SRCU, I believe the deadlock is still possible. Signed-off-by: NeilBrown <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
2020-04-28drm/amdgpu: bump version for invalidate L2 before SDMA IBsMarek Olšák1-1/+2
This fixes GPU hangs due to cache coherency issues. Bump the driver version. Split out from the original patch. Signed-off-by: Marek Olšák <[email protected]> Reviewed-by: Christian König <[email protected]> Tested-by: Pierre-Eric Pelloux-Prayer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-04-28drm/amdgpu: invalidate L2 before SDMA IBs (v2)Marek Olšák2-1/+29
This fixes GPU hangs due to cache coherency issues. v2: Split the version bump to a separate patch Signed-off-by: Marek Olšák <[email protected]> Reviewed-by: Christian König <[email protected]> Tested-by: Pierre-Eric Pelloux-Prayer <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-04-28drm/amdgpu: add tiling flags from MesaMarek Olšák1-0/+4
DCC_INDEPENDENT_128B is needed for displayble DCC on gfx10. SCANOUT is not needed by the kernel, but Mesa uses it. Signed-off-by: Marek Olšák <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-04-28drm/amd/powerplay: avoid using pm_en before it is initialized revisedTiecheng Zhou1-2/+4
hwmgr->pm_en is initialized at hwmgr_hw_init. during amdgpu_device_init, there is amdgpu_asic_reset that calls to soc15_asic_reset (for V320 usecase, Vega10 asic), in which: 1) soc15_asic_reset_method calls to pp_get_asic_baco_capability (pm_en) 2) soc15_asic_baco_reset calls to pp_set_asic_baco_state (pm_en) pm_en is used in the above two cases while it has not yet been initialized So avoid using pm_en in the above two functions for V320 passthrough. Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Tiecheng Zhou <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-04-28Revert "drm/amd/powerplay: avoid using pm_en before it is initialized"Tiecheng Zhou1-2/+1
This reverts commit c5207876232649ca5e5ddd6f966d2da75ffded8f. The commit being reverted changed the wrong place, it should have changed in func get_asic_baco_capability. Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Tiecheng Zhou <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-04-28thunderbolt: Check return value of tb_sw_read() in usb4_switch_op()Mika Westerberg1-0/+3
The function misses checking return value of tb_sw_read() before it accesses the value that was read. Fix this by checking the return value first. Fixes: b04079837b20 ("thunderbolt: Add initial support for USB4") Signed-off-by: Mika Westerberg <[email protected]> Reviewed-by: Yehezkel Bernat <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28dmaengine: dmatest: Fix process hang when reading 'wait' parameterAndy Shevchenko1-1/+1
If we do % echo 1 > /sys/module/dmatest/parameters/run [ 115.851124] dmatest: Could not start test, no channels configured % echo dma8chan7 > /sys/module/dmatest/parameters/channel [ 127.563872] dmatest: Added 1 threads using dma8chan7 % cat /sys/module/dmatest/parameters/wait ... !!! HANG !!! ... The culprit is the commit 6138f967bccc ("dmaengine: dmatest: Use fixed point div to calculate iops") which makes threads not to run, but pending and being kicked off by writing to the 'run' node. However, it forgot to consider 'wait' routine to avoid above mentioned case. In order to fix this, check for really running threads, i.e. with pending and done flags unset. It's pity the culprit commit hadn't updated documentation and tested all possible scenarios. Fixes: 6138f967bccc ("dmaengine: dmatest: Use fixed point div to calculate iops") Cc: Seraj Alijan <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]>