commit e32f4fa1b24d825b2560ca9cfbfd9df44a4310b4 Author: Greg Kroah-Hartman Date: Sat Sep 5 11:22:51 2020 +0200 Linux 5.4.63 Tested-by: Shuah Khan Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 5153710a5eccb294e6e17b76b58615f5a5d0d298 Author: Bodo Stroesser Date: Thu Jun 18 15:16:31 2020 +0200 scsi: target: tcmu: Optimize use of flush_dcache_page commit 3c58f737231e2c8cbf543a09d84d8c8e80e05e43 upstream. (scatter|gather)_data_area() need to flush dcache after writing data to or before reading data from a page in uio data area. The two routines are able to handle data transfer to/from such a page in fragments and flush the cache after each fragment was copied by calling the wrapper tcmu_flush_dcache_range(). That means: 1) flush_dcache_page() can be called multiple times for the same page. 2) Calling flush_dcache_page() indirectly using the wrapper does not make sense, because each call of the wrapper is for one single page only and the calling routine already has the correct page pointer. Change (scatter|gather)_data_area() such that, instead of calling tcmu_flush_dcache_range() before/after each memcpy, it now calls flush_dcache_page() before unmapping a page (when writing is complete for that page) or after mapping a page (when starting to read the page). After this change only calls to tcmu_flush_dcache_range() for addresses in vmalloc'ed command ring are left over. The patch was tested on ARM with kernel 4.19.118 and 5.7.2 Link: https://lore.kernel.org/r/20200618131632.32748-2-bstroesser@ts.fujitsu.com Tested-by: JiangYu Tested-by: Daniel Meyerholt Acked-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit bb9949fdfddd6233d190a54ff863ec07f8c528dc Author: Bodo Stroesser Date: Thu May 28 21:31:08 2020 +0200 scsi: target: tcmu: Fix size in calls to tcmu_flush_dcache_range commit 8c4e0f212398cdd1eb4310a5981d06a723cdd24f upstream. 1) If remaining ring space before the end of the ring is smaller then the next cmd to write, tcmu writes a padding entry which fills the remaining space at the end of the ring. Then tcmu calls tcmu_flush_dcache_range() with the size of struct tcmu_cmd_entry as data length to flush. If the space filled by the padding was smaller then tcmu_cmd_entry, tcmu_flush_dcache_range() is called for an address range reaching behind the end of the vmalloc'ed ring. tcmu_flush_dcache_range() in a loop calls flush_dcache_page(virt_to_page(start)); for every page being part of the range. On x86 the line is optimized out by the compiler, as flush_dcache_page() is empty on x86. But I assume the above can cause trouble on other architectures that really have a flush_dcache_page(). For paddings only the header part of an entry is relevant due to alignment rules the header always fits in the remaining space, if padding is needed. So tcmu_flush_dcache_range() can safely be called with sizeof(entry->hdr) as the length here. 2) After it has written a command to cmd ring, tcmu calls tcmu_flush_dcache_range() using the size of a struct tcmu_cmd_entry as data length to flush. But if a command needs many iovecs, the real size of the command may be bigger then tcmu_cmd_entry, so a part of the written command is not flushed then. Link: https://lore.kernel.org/r/20200528193108.9085-1-bstroesser@ts.fujitsu.com Acked-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6d2e274f60fc1a74ce9d6699490baba25ac8ad96 Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:56 2020 -0700 sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186 commit 391d89dba8c290859a3e29430d0b9e32c358bb0d upstream. commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support") SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the beginning of its support in driver. Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead of SDCLK and this quirk should not be set. So, this patch remove this quirk for Tegra186. Fixes: 4346b7c7941d ("mmc: tegra: Add Tegra186 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Acked-by: Adrian Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-3-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0176db2f2ad5218a7cf5ad51690bec3ff767ecfe Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:55 2020 -0700 sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210 commit e33588adcaa925c18ee2ea253161fb0317fa2329 upstream. commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support") SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the beginning of Tegra210 support in the driver. Tegra210 SDMMC hardware by default uses timeout clock (TMCLK) instead of SDCLK and this quirk should not be set. So, this patch remove this quirk for Tegra210. Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Acked-by: Adrian Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-2-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit eda97e9d90db817bb71a1f73119f38cd6d986bb6 Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:58 2020 -0700 arm64: tegra: Add missing timeout clock to Tegra210 SDMMC commit 679f71fa0db2d777f39c7a5af7f7c0689fc713fa upstream. commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support") Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra SDMMC advertises 12Mhz as timeout clock frequency in host capability register. So, this clock should be kept enabled by SDMMC driver. Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-5-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 5cd8c5979e727121248541e9322356f90cbcb46e Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:59 2020 -0700 arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes commit baba217d2c4446b6eef309d81d8776cb5c68cb55 upstream. commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support") Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host capability register and uses it by default. So, this clock should be kept enabled by the SDMMC driver. Fixes: 39cb62cb8973 ("arm64: tegra: Add Tegra186 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-6-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ef8b5f333780de34a973f5f41142bf240263bb5b Author: Sowjanya Komatineni Date: Thu Aug 27 10:21:00 2020 -0700 arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes commit c956c0cd4f6f4aac4f095621b1c4e1c5ee1df877 upstream. commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host capability register. So, this clock should be kept enabled by SDMMC driver. Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-7-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 9d806d68bf97e862ce7652573bdaac5ce13ed9a2 Author: Sowjanya Komatineni Date: Thu Aug 27 10:20:57 2020 -0700 dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later commit f7f86e8ac0ad7cd6792a80137f5a550924966916 upstream. commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data timeout. So, this patch adds "tmclk" to Tegra sdhci clock property in the device tree binding. Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Cc: stable # 5.4 Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-4-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d2ac42e61ecdcdeee12b1d3a0e6bc39f01033fe2 Author: James Morse Date: Fri Aug 21 15:07:07 2020 +0100 KVM: arm64: Set HCR_EL2.PTW to prevent AT taking synchronous exception commit 71a7f8cb1ca4ca7214a700b1243626759b6c11d4 upstream. AT instructions do a translation table walk and return the result, or the fault in PAR_EL1. KVM uses these to find the IPA when the value is not provided by the CPU in HPFAR_EL1. If a translation table walk causes an external abort it is taken as an exception, even if it was due to an AT instruction. (DDI0487F.a's D5.2.11 "Synchronous faults generated by address translation instructions") While we previously made KVM resilient to exceptions taken due to AT instructions, the device access causes mismatched attributes, and may occur speculatively. Prevent this, by forbidding a walk through memory described as device at stage2. Now such AT instructions will report a stage2 fault. Such a fault will cause KVM to restart the guest. If the AT instructions always walk the page tables, but guest execution uses the translation cached in the TLB, the guest can't make forward progress until the TLB entry is evicted. This isn't a problem, as since commit 5dcd0fdbb492 ("KVM: arm64: Defer guest entry when an asynchronous exception is pending"), KVM will return to the host to process IRQs allowing the rest of the system to keep running. Cc: stable@vger.kernel.org # Reviewed-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Andre Przywara Signed-off-by: Greg Kroah-Hartman commit ffad02f9e3ea10f88d7e8f4fd4149e6e0898312c Author: James Morse Date: Fri Aug 21 15:07:06 2020 +0100 KVM: arm64: Survive synchronous exceptions caused by AT instructions commit 88a84ccccb3966bcc3f309cdb76092a9892c0260 upstream. KVM doesn't expect any synchronous exceptions when executing, any such exception leads to a panic(). AT instructions access the guest page tables, and can cause a synchronous external abort to be taken. The arm-arm is unclear on what should happen if the guest has configured the hardware update of the access-flag, and a memory type in TCR_EL1 that does not support atomic operations. B2.2.6 "Possible implementation restrictions on using atomic instructions" from DDI0487F.a lists synchronous external abort as a possible behaviour of atomic instructions that target memory that isn't writeback cacheable, but the page table walker may behave differently. Make KVM robust to synchronous exceptions caused by AT instructions. Add a get_user() style helper for AT instructions that returns -EFAULT if an exception was generated. While KVM's version of the exception table mixes synchronous and asynchronous exceptions, only one of these can occur at each location. Re-enter the guest when the AT instructions take an exception on the assumption the guest will take the same exception. This isn't guaranteed to make forward progress, as the AT instructions may always walk the page tables, but guest execution may use the translation cached in the TLB. This isn't a problem, as since commit 5dcd0fdbb492 ("KVM: arm64: Defer guest entry when an asynchronous exception is pending"), KVM will return to the host to process IRQs allowing the rest of the system to keep running. Cc: stable@vger.kernel.org # Reviewed-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Andre Przywara Signed-off-by: Greg Kroah-Hartman commit 1744237ca0473a7df6ffa9b108d027ea87835653 Author: James Morse Date: Fri Aug 21 15:07:05 2020 +0100 KVM: arm64: Add kvm_extable for vaxorcism code commit e9ee186bb735bfc17fa81dbc9aebf268aee5b41e upstream. KVM has a one instruction window where it will allow an SError exception to be consumed by the hypervisor without treating it as a hypervisor bug. This is used to consume asynchronous external abort that were caused by the guest. As we are about to add another location that survives unexpected exceptions, generalise this code to make it behave like the host's extable. KVM's version has to be mapped to EL2 to be accessible on nVHE systems. The SError vaxorcism code is a one instruction window, so has two entries in the extable. Because the KVM code is copied for VHE and nVHE, we end up with four entries, half of which correspond with code that isn't mapped. Cc: # 5.4.x Signed-off-by: James Morse Reviewed-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Andre Przywara Signed-off-by: Greg Kroah-Hartman commit 538caddbe635d3ca18e0f02276e76c124eb3c604 Author: Lucas Stach Date: Wed Feb 26 16:27:08 2020 +0100 drm/etnaviv: fix TS cache flushing on GPUs with BLT engine commit f232d9ec029ce3e2543b05213e2979e01e503408 upstream. As seen in the Vivante kernel driver, most GPUs with the BLT engine have a broken TS cache flush. The workaround is to temporarily set the BLT command to CLEAR_IMAGE, without actually executing the clear. Apparently this state change is enough to trigger the required TS cache flush. As the BLT engine is completely asychronous, we also need a few more stall states to synchronize the flush with the frontend. Root-caused-by: Jonathan Marek Signed-off-by: Lucas Stach Cc: Walter Lozano Signed-off-by: Greg Kroah-Hartman commit 80743b4bde09fe4fcc9d6c02523e03f3e6eb5844 Author: Andrey Grodzovsky Date: Tue Oct 29 11:03:05 2019 -0400 drm/sched: Fix passing zero to 'PTR_ERR' warning v2 commit d7c5782acd354bdb5ed0fa10e1e397eaed558390 upstream. Fix a static code checker warning. v2: Drop PTR_ERR_OR_ZERO. Signed-off-by: Andrey Grodzovsky Reviewed-by: Emily Deng Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: Walter Lozano Signed-off-by: Greg Kroah-Hartman commit 6cadd1e2d8c5890b3f5fd24c63234c9ccc6066e6 Author: Kim Phillips Date: Tue Sep 1 16:58:53 2020 -0500 perf record/stat: Explicitly call out event modifiers in the documentation commit e48a73a312ebf19cc3d72aa74985db25c30757c1 upstream. Event modifiers are not mentioned in the perf record or perf stat manpages. Add them to orient new users more effectively by pointing them to the perf list manpage for details. Fixes: 2055fdaf8703 ("perf list: Document precise event sampling for AMD IBS") Signed-off-by: Kim Phillips Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Ian Rogers Cc: Jin Yao Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Paul Clarke Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Tony Jones Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20200901215853.276234-1-kim.phillips@amd.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 4bae1afed43212ee3ec64f2bdc9e39e800974e7e Author: Marc Zyngier Date: Tue Sep 1 10:52:33 2020 +0100 HID: core: Sanitize event code and type when mapping input commit 35556bed836f8dc07ac55f69c8d17dce3e7f0e25 upstream. When calling into hid_map_usage(), the passed event code is blindly stored as is, even if it doesn't fit in the associated bitmap. This event code can come from a variety of sources, including devices masquerading as input devices, only a bit more "programmable". Instead of taking the event code at face value, check that it actually fits the corresponding bitmap, and if it doesn't: - spit out a warning so that we know which device is acting up - NULLify the bitmap pointer so that we catch unexpected uses Code paths that can make use of untrusted inputs can now check that the mapping was indeed correct and bail out if not. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman commit 667514df10a08e4a65cb88f5fd5ffeccd027c4af Author: Marc Zyngier Date: Sat Aug 29 12:26:01 2020 +0100 HID: core: Correctly handle ReportSize being zero commit bce1305c0ece3dc549663605e567655dd701752c upstream. It appears that a ReportSize value of zero is legal, even if a bit non-sensical. Most of the HID code seems to handle that gracefully, except when computing the total size in bytes. When fed as input to memset, this leads to some funky outcomes. Detect the corner case and correctly compute the size. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman