aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-04-29platform/chrome: cros_ec_sensorhub: Allocate sensorhub resource before ↵Gwendal Grignou2-61/+92
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-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 Torvalds2-2/+2
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-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-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-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/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]>
2020-04-28driver core: Ensure wait_for_device_probe() waits until the ↵John Stultz1-0/+5
deferred_probe_timeout fires In commit c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic"), we set the default driver_deferred_probe_timeout value to 30 seconds to allow for drivers that are missing dependencies to have some time so that the dependency may be loaded from userland after initcalls_done is set. However, Yoshihiro Shimoda reported that on his device that expects to have unmet dependencies (due to "optional links" in its devicetree), was failing to mount the NFS root. In digging further, it seemed the problem was that while the device properly probes after waiting 30 seconds for any missing modules to load, the ip_auto_config() had already failed, resulting in NFS to fail. This was due to ip_auto_config() calling wait_for_device_probe() which doesn't wait for the driver_deferred_probe_timeout to fire. This patch tries to fix the issue by creating a waitqueue for the driver_deferred_probe_timeout, and calling wait_event() to make sure driver_deferred_probe_timeout is zero in wait_for_device_probe() to make sure all the probing is finished. The downside to this solution is that kernel functionality that uses wait_for_device_probe(), will block until the driver_deferred_probe_timeout fires, regardless of if there is any missing dependencies. However, the previous patch reverts the default timeout value to zero, so this side-effect will only affect users who specify a driver_deferred_probe_timeout= value as a boot argument, where the additional delay would be beneficial to allow modules to load later during boot. Thanks to Geert for chasing down that ip_auto_config was why NFS was failing in this case! Cc: "David S. Miller" <[email protected]> Cc: Alexey Kuznetsov <[email protected]> Cc: Hideaki YOSHIFUJI <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Rob Herring <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Yoshihiro Shimoda <[email protected]> Cc: Robin Murphy <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Naresh Kamboju <[email protected]> Cc: Basil Eljuse <[email protected]> Cc: Ferry Toth <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Anders Roxell <[email protected]> Cc: [email protected] Reported-by: Yoshihiro Shimoda <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Tested-by: Yoshihiro Shimoda <[email protected]> Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic") Signed-off-by: John Stultz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28driver core: Use dev_warn() instead of dev_WARN() for deferred_probe_timeout ↵John Stultz1-1/+1
warnings In commit c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic") and following changes the logic was changes slightly so that if there is no driver to match whats found in the dtb, we wait the sepcified seconds for modules to be loaded by userland, and then timeout, where as previously we'd print "ignoring dependency for device, assuming no driver" and immediately return -ENODEV after initcall_done. However, in the timeout case (which previously existed but was practicaly un-used without a boot argument), the timeout message uses dev_WARN(). This means folks are now seeing a big backtrace in their boot logs if there a entry in their dts that doesn't have a driver. To fix this, lets use dev_warn(), instead of dev_WARN() to match the previous error path. Cc: "David S. Miller" <[email protected]> Cc: Alexey Kuznetsov <[email protected]> Cc: Hideaki YOSHIFUJI <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Rob Herring <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Yoshihiro Shimoda <[email protected]> Cc: Robin Murphy <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Naresh Kamboju <[email protected]> Cc: Basil Eljuse <[email protected]> Cc: Ferry Toth <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Anders Roxell <[email protected]> Cc: [email protected] Reviewed-by: Yoshihiro Shimoda <[email protected]> Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic") Signed-off-by: John Stultz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28driver core: Revert default driver_deferred_probe_timeout value to 0John Stultz1-11/+2
This patch addresses a regression in 5.7-rc1+ In commit c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic"), we both cleaned up the logic and also set the default driver_deferred_probe_timeout value to 30 seconds to allow for drivers that are missing dependencies to have some time so that the dependency may be loaded from userland after initcalls_done is set. However, Yoshihiro Shimoda reported that on his device that expects to have unmet dependencies (due to "optional links" in its devicetree), was failing to mount the NFS root. In digging further, it seemed the problem was that while the device properly probes after waiting 30 seconds for any missing modules to load, the ip_auto_config() had already failed, resulting in NFS to fail. This was due to ip_auto_config() calling wait_for_device_probe() which doesn't wait for the driver_deferred_probe_timeout to fire. Fixing that issue is possible, but could also introduce 30 second delays in bootups for users who don't have any missing dependencies, which is not ideal. So I think the best solution to avoid any regressions is to revert back to a default timeout value of zero, and allow systems that need to utilize the timeout in order for userland to load any modules that supply misisng dependencies in the dts to specify the timeout length via the exiting documented boot argument. Thanks to Geert for chasing down that ip_auto_config was why NFS was failing in this case! Cc: "David S. Miller" <[email protected]> Cc: Alexey Kuznetsov <[email protected]> Cc: Hideaki YOSHIFUJI <[email protected]> Cc: Jakub Kicinski <[email protected]> Cc: Rafael J. Wysocki <[email protected]> Cc: Rob Herring <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Yoshihiro Shimoda <[email protected]> Cc: Robin Murphy <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Sudeep Holla <[email protected]> Cc: Andy Shevchenko <[email protected]> Cc: Naresh Kamboju <[email protected]> Cc: Basil Eljuse <[email protected]> Cc: Ferry Toth <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Anders Roxell <[email protected]> Reported-by: Yoshihiro Shimoda <[email protected]> Tested-by: Yoshihiro Shimoda <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Fixes: c8c43cee29f6 ("driver core: Fix driver_deferred_probe_check_state() logic") Signed-off-by: John Stultz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28component: Silence bind error on -EPROBE_DEFERJames Hilliard1-3/+5
If a component fails to bind due to -EPROBE_DEFER we should not log an error as this is not a real failure. Fixes messages like: vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops): -517 vc4-drm soc:gpu: master bind failed: -517 Signed-off-by: James Hilliard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28driver core: Fix handling of fw_devlink=permissiveSaravana Kannan1-1/+6
When commit 8375e74f2bca ("driver core: Add fw_devlink kernel commandline option") added fw_devlink, it didn't implement "permissive" mode correctly. That commit got the device links flags correct to make sure unprobed suppliers don't block the probing of a consumer. However, if a consumer is waiting for mandatory suppliers to register, that could still block a consumer from probing. This commit fixes that by making sure in permissive mode, all suppliers to a consumer are treated as a optional suppliers. So, even if a consumer is waiting for suppliers to register and link itself (using the DL_FLAG_SYNC_STATE_ONLY flag) to the supplier, the consumer is never blocked from probing. Fixes: 8375e74f2bca ("driver core: Add fw_devlink kernel commandline option") Reported-by: Marek Szyprowski <[email protected]> Signed-off-by: Saravana Kannan <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28amba: Initialize dma_parms for amba devicesUlf Hansson1-0/+1
It's currently the amba driver's responsibility to initialize the pointer, dma_parms, for its corresponding struct device. The benefit with this approach allows us to avoid the initialization and to not waste memory for the struct device_dma_parameters, as this can be decided on a case by case basis. However, it has turned out that this approach is not very practical. Not only does it lead to open coding, but also to real errors. In principle callers of dma_set_max_seg_size() doesn't check the error code, but just assumes it succeeds. For these reasons, let's do the initialization from the common amba bus at the device registration point. This also follows the way the PCI devices are being managed, see pci_device_add(). Suggested-by: Christoph Hellwig <[email protected]> Cc: Russell King <[email protected]> Cc: <[email protected]> Tested-by: Haibo Chen <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28driver core: platform: Initialize dma_parms for platform devicesUlf Hansson1-0/+2
It's currently the platform driver's responsibility to initialize the pointer, dma_parms, for its corresponding struct device. The benefit with this approach allows us to avoid the initialization and to not waste memory for the struct device_dma_parameters, as this can be decided on a case by case basis. However, it has turned out that this approach is not very practical. Not only does it lead to open coding, but also to real errors. In principle callers of dma_set_max_seg_size() doesn't check the error code, but just assumes it succeeds. For these reasons, let's do the initialization from the common platform bus at the device registration point. This also follows the way the PCI devices are being managed, see pci_device_add(). Suggested-by: Christoph Hellwig <[email protected]> Cc: <[email protected]> Tested-by: Haibo Chen <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28most: core: use function subsys_initcall()Christian Gromm1-1/+1
This patch replaces function module_init() with subsys_initcall(). It is needed to ensure that the core module of the driver is initialized before a component tries to register with the core. This leads to a NULL pointer dereference if the driver is configured as in-tree. Signed-off-by: Christian Gromm <[email protected]> Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28bus: mhi: core: Fix a NULL vs IS_ERR check in mhi_create_devices()Dan Carpenter1-1/+1
The mhi_alloc_device() function never returns NULL, it returns error pointers. Fixes: da1c4f856924 ("bus: mhi: core: Add support for creating and destroying MHI devices") Signed-off-by: Dan Carpenter <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/20200407093133.GM68494@mwanda Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-04-28Revert "i2c: tegra: Better handle case where CPU0 is busy for a long time"Wolfram Sang1-15/+12
This reverts commit a900aeac253729411cf33c6cb598c152e9e4137f because regressions were showing up. Suggested-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/dmaengine/[email protected]/ Signed-off-by: Wolfram Sang <[email protected]>
2020-04-28Revert "i2c: tegra: Synchronize DMA before termination"Wolfram Sang1-9/+0
This reverts commit 8814044fe0fa182abc9ff818d3da562de98bc9a7 because regressions were showing up. Suggested-by: Thierry Reding <[email protected]> Link: https://lore.kernel.org/dmaengine/[email protected]/ Signed-off-by: Wolfram Sang <[email protected]>
2020-04-28i2c: iproc: generate stop event for slave writesRayagonda Kokatanur1-0/+3
When slave status is I2C_SLAVE_RX_END, generate I2C_SLAVE_STOP event to i2c_client. Fixes: c245d94ed106 ("i2c: iproc: Add multi byte read-write support for slave mode") Signed-off-by: Rayagonda Kokatanur <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2020-04-28drm/qxl: qxl_release leak in qxl_hw_surface_alloc()Vasily Averin1-2/+3
Cc: [email protected] Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations") 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-28drm/qxl: qxl_release leak in qxl_draw_dirty_fb()Vasily Averin1-2/+3
ret should be changed to release allocated struct qxl_release Cc: [email protected] Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations") 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-28drm/virtio: only destroy created contextsGurchetan Singh1-11/+6
This can happen if userspace doesn't issue any 3D ioctls before closing the DRM fd. Fixes: 72b48ae800da ("drm/virtio: enqueue virtio_gpu_create_context after the first 3D ioctl") Signed-off-by: Gurchetan Singh <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]>
2020-04-27scsi: ibmvfc: Don't send implicit logouts prior to NPIV loginBrian King1-0/+5
Commit ed830385a2b1 ("scsi: ibmvfc: Avoid loss of all paths during SVC node reboot") introduced a regression where when the client resets or re-enables its CRQ with the hypervisor there is a chance that if the server side doesn't issue its INIT handshake quick enough the client can issue an Implicit Logout prior to doing an NPIV Login. The server treats this scenario as a protocol violation and closes the CRQ on its end forcing the client through a reset that gets the client host state and next host action out of agreement leading to a BUG assert. ibmvfc 30000003: Partner initialization complete ibmvfc 30000002: Partner initialization complete ibmvfc 30000002: Host partner adapter deregistered or failed (rc=2) ibmvfc 30000002: Partner initialized ------------[ cut here ]------------ kernel BUG at ../drivers/scsi/ibmvscsi/ibmvfc.c:4489! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Supported: No, Unreleased kernel CPU: 16 PID: 1290 Comm: ibmvfc_0 Tainted: G OE X 5.3.18-12-default NIP: c00800000d84a2b4 LR: c00800000d84a040 CTR: c00800000d84a2a0 REGS: c00000000cb57a00 TRAP: 0700 Tainted: G OE X (5.3.18-12-default) MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24000848 XER: 00000001 CFAR: c00800000d84a070 IRQMASK: 1 GPR00: c00800000d84a040 c00000000cb57c90 c00800000d858e00 0000000000000000 GPR04: 0000000000000000 0000000000000000 0000000000000000 00000000000000a0 GPR08: c00800000d84a074 0000000000000001 0000000000000014 c00800000d84d7d0 GPR12: 0000000000000000 c00000001ea28200 c00000000016cd98 0000000000000000 GPR16: c00800000d84b7b8 0000000000000000 0000000000000000 c00000542c706d68 GPR20: 0000000000000005 c00000542c706d88 5deadbeef0000100 5deadbeef0000122 GPR24: 000000000000000c 000000000000000b c00800000d852180 0000000000000001 GPR28: 0000000000000000 c00000542c706da0 c00000542c706860 c00000542c706828 NIP [c00800000d84a2b4] ibmvfc_work+0x3ac/0xc90 [ibmvfc] LR [c00800000d84a040] ibmvfc_work+0x138/0xc90 [ibmvfc] This scenario can be prevented by rejecting any attempt to send an Implicit Logout if the client adapter is not logged in yet. Link: https://lore.kernel.org/r/[email protected] Fixes: ed830385a2b1 ("scsi: ibmvfc: Avoid loss of all paths during SVC node reboot") Signed-off-by: Brian King <[email protected]> Signed-off-by: Tyrel Datwyler <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-04-27Merge tag 'hyperv-fixes-signed' of ↵Linus Torvalds3-16/+37
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull Hyper-V fixes from Wei Liu: - Two patches from Dexuan fixing suspension bugs - Three cleanup patches from Andy and Michael * tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: hyper-v: Remove internal types from UAPI header hyper-v: Use UUID API for exporting the GUID x86/hyperv: Suspend/resume the VP assist page for hibernation Drivers: hv: Move AEOI determination to architecture dependent code Drivers: hv: vmbus: Fix Suspend-to-Idle for Generation-2 VM
2020-04-27net/sonic: Fix a resource leak in an error handling path in 'jazz_sonic_probe()'Christophe JAILLET1-2/+4
A call to 'dma_alloc_coherent()' is hidden in 'sonic_alloc_descriptors()', called from 'sonic_probe1()'. This is correctly freed in the remove function, but not in the error handling path of the probe function. Fix it and add the missing 'dma_free_coherent()' call. While at it, rename a label in order to be slightly more informative. Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2020-04-27net: tc35815: Fix phydev supported/advertising maskAnthony Felice1-1/+1
Commit 3c1bcc8614db ("net: ethernet: Convert phydev advertize and supported from u32 to link mode") updated ethernet drivers to use a linkmode bitmap. It mistakenly dropped a bitwise negation in the tc35815 ethernet driver on a bitmask to set the supported/advertising flags. Found by Anthony via code inspection, not tested as I do not have the required hardware. Fixes: 3c1bcc8614db ("net: ethernet: Convert phydev advertize and supported from u32 to link mode") Signed-off-by: Anthony Felice <[email protected]> Reviewed-by: Akshay Bhat <[email protected]> Reviewed-by: Heiner Kallweit <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.