- May 04, 2020
-
-
Alexander Tsoy authored
commit 9f35a312 upstream. It should be safe to ignore clock validity check result if the following conditions are met: - only one single sample rate is supported; - the terminal is directly connected to the clock source; - the clock type is internal. This is to deal with some Denon DJ controllers that always reports that clock is invalid. Tested-by:
Tobias Oszlanyi <toszlanyi@yahoo.de> Signed-off-by:
Alexander Tsoy <alexander@tsoy.me> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200212235450.697348-1-alexander@tsoy.me Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Saurav Girepunje authored
commit 1d4961d9 upstream. Use true/false for bool type return in uac_clock_source_is_valid(). Signed-off-by:
Saurav Girepunje <saurav.girepunje@gmail.com> Link: https://lore.kernel.org/r/20191029175200.GA7320@saurav Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Arvind Sankar authored
commit 93f9d1a4 upstream. The Audioengine D1 (0x2912:0x30c8) does support reading the sample rate, but it returns the rate in byte-reversed order. When setting sampling rate, the driver produces these warning messages: [168840.944226] usb 3-2.2: current rate 4500480 is different from the runtime rate 44100 [168854.930414] usb 3-2.2: current rate 8436480 is different from the runtime rate 48000 [168905.185825] usb 3-2.1.2: current rate 30465 is different from the runtime rate 96000 As can be seen from the hexadecimal conversion, the current rate read back is byte-reversed from the rate that was set. 44100 == 0x00ac44, 4500480 == 0x44ac00 48000 == 0x00bb80, 8436480 == 0x80bb00 96000 == 0x017700, 30465 == 0x007701 Rather than implementing a new quirk to reverse the order, just skip checking the rate to avoid spamming the log. Signed-off-by:
Arvind Sankar <nivedita@alum.mit.edu> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200211162235.1639889-1-nivedita@alum.mit.edu Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Takashi Iwai authored
commit 7dafba37 upstream. MSI-GL73 laptop with ALC1220 codec requires a similar workaround for Clevo laptops to enforce the DAC/mixer connection path. Set up a quirk entry for that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=204159 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200212081047.27727-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Kailang Yang authored
commit 2b3b6497 upstream. Add supported Headset Button for ALC215/ALC285/ALC289. Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/948f70b4488f4cc2b629a39ce4e4be33@realtek.com Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Benjamin Tissoires authored
commit 5179a9df upstream. The Yoga 11e is using LEN0049, but it doesn't have a trackstick. Thus, there is no need to create a software top buttons row. However, it seems that the device works under SMBus, so keep it as part of the smbus_pnp_ids. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200115013023.9710-1-benjamin.tissoires@redhat.com Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Gaurav Agrawal authored
commit b8a3d819 upstream. Add touchpad LEN2044 to the list, as it is capable of working with psmouse.synaptics_intertouch=1 Signed-off-by:
Gaurav Agrawal <agrawalgaurav@gnome.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/CADdtggVzVJq5gGNmFhKSz2MBwjTpdN5YVOdr4D3Hkkv=KZRc9g@mail.gmail.com Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Lyude Paul authored
commit bf502391 upstream. This supports RMI4 and everything seems to work, including the touchpad buttons. So, let's enable this by default. Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200204194322.112638-1-lyude@redhat.com Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Stephen Smalley authored
commit 0188d5c0 upstream. commit bda0be7a ("security: make inode_follow_link RCU-walk aware") passed down the rcu flag to the SELinux AVC, but failed to adjust the test in slow_avc_audit() to also return -ECHILD on LSM_AUDIT_DATA_DENTRY. Previously, we only returned -ECHILD if generating an audit record with LSM_AUDIT_DATA_INODE since this was only relevant from inode_permission. Move the handling of MAY_NOT_BLOCK to avc_audit() and its inlined equivalent in selinux_inode_permission() immediately after we determine that audit is required, and always fall back to ref-walk in this case. Fixes: bda0be7a ("security: make inode_follow_link RCU-walk aware") Reported-by:
Will Deacon <will@kernel.org> Suggested-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Qing Xu authored
commit b70261a2 upstream. mwifiex_cmd_append_vsie_tlv() calls memcpy() without checking the destination size may trigger a buffer overflower, which a local user could use to cause denial of service or the execution of arbitrary code. Fix it by putting the length check before calling memcpy(). Signed-off-by:
Qing Xu <m1s5p6688@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Qing Xu authored
commit 3a9b153c upstream. mwifiex_ret_wmm_get_status() calls memcpy() without checking the destination size.Since the source is given from remote AP which contains illegal wmm elements , this may trigger a heap buffer overflow. Fix it by putting the length check before calling memcpy(). Signed-off-by:
Qing Xu <m1s5p6688@gmail.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Jerome Brunet authored
commit b1b3f062 upstream. UART2 peripheral is missing from the regmap fixup table of the g12a family clock controller. As it is, any access to this clock would Oops, which is not great. Add the clock to the table to fix the problem. Fixes: 085a4ea9 ("clk: meson: g12a: add peripheral clock controller") Reported-by:
Dmitry Shmidt <dimitrysh@google.com> Tested-by:
Dmitry Shmidt <dimitrysh@google.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Tested-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
Jerome Brunet <jbrunet@baylibre.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Bartosz Golaszewski authored
commit cb7a374a upstream. MAX77650 MFD driver uses regmap_irq API but doesn't select the required REGMAP_IRQ option in Kconfig. This can cause the following build error if regmap irq is not enabled implicitly by someone else: ld: drivers/mfd/max77650.o: in function `max77650_i2c_probe': max77650.c:(.text+0xcb): undefined reference to `devm_regmap_add_irq_chip' ld: max77650.c:(.text+0xdb): undefined reference to `regmap_irq_get_domain' make: *** [Makefile:1079: vmlinux] Error 1 Fix it by adding the missing option. Fixes: d0f60334 ("mfd: Add new driver for MAX77650 PMIC") Reported-by:
Paul Gazzillo <paul@pgazz.com> Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Ben Whitten authored
commit 2e31aab0 upstream. When checking if a register block is writable we must ensure that the block does not start with or contain a non incrementing register. Fixes: 8b9f9d4d ("regmap: verify if register is writeable before writing operations") Signed-off-by:
Ben Whitten <ben.whitten@gmail.com> Link: https://lore.kernel.org/r/20200118205625.14532-1-ben.whitten@gmail.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Geert Uytterhoeven authored
commit 805f6357 upstream. The FN_SDSELF_B and FN_SD1_CLK_B enum IDs are used twice, which means one set of users must be wrong. Replace them by the correct enum IDs. Fixes: 87f8c988 ("sh-pfc: Add r8a7778 pinmux support") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191218194812.12741-2-geert+renesas@glider.be Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Geert Uytterhoeven authored
commit a34cd9df upstream. R-Car Gen3 Hardware Manual Errata for Rev. 2.00 of October 24, 2019 changed the configuration bits for drive and bias control for the DU_DOTCLKIN3 pin on R-Car M3-N, to match the same pin on R-Car H3. Update the driver to reflect this. After this, the handling of drive and bias control for the various DU_DOTCLKINx pins is consistent across all of the R-Car H3, M3-W, M3-W+, and M3-N SoCs. Fixes: 86c045c2 ("pinctrl: sh-pfc: r8a77965: Replace DU_DOTCLKIN2 by DU_DOTCLKIN3") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191113101653.28428-1-geert+renesas@glider.be Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Stephen Smalley authored
commit 98aa0034 upstream. commit 2db154b3 ("vfs: syscall: Add move_mount(2) to move mounts around") introduced a new move_mount(2) system call and a corresponding new LSM security_move_mount hook but did not implement this hook for any existing LSM. This creates a regression for SELinux with respect to consistent checking of mounts; the existing selinux_mount hook checks mounton permission to the mount point path. Provide a SELinux hook implementation for move_mount that applies this same check for consistency. In the future we may wish to add a new move_mount filesystem permission and check as well, but this addresses the immediate regression. Fixes: 2db154b3 ("vfs: syscall: Add move_mount(2) to move mounts around") Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov> Reviewed-by:
Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Stephen Smalley authored
commit 1a37079c upstream. This reverts commit e46e01ee ("selinux: stop passing MAY_NOT_BLOCK to the AVC upon follow_link"). The correct fix is to instead fall back to ref-walk if audit is required irrespective of the specific audit data type. This is done in the next commit. Fixes: e46e01ee ("selinux: stop passing MAY_NOT_BLOCK to the AVC upon follow_link") Reported-by:
Will Deacon <will@kernel.org> Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov> Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Gustavo A. R. Silva authored
commit 0d962e06 upstream. Enclose multiple macro parameters in parentheses in order to make such macros safer and fix the Clang warning below: drivers/media/i2c/adv748x/adv748x-afe.c:452:12: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] ret = sdp_clrset(state, ADV748X_SDP_FRP, ADV748X_SDP_FRP_MASK, enable ? ctrl->val - 1 : 0); Fixes: 3e89586a ("media: i2c: adv748x: add adv748x driver") Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Christophe Roullier authored
commit 85fdc63f upstream. If the watchdog hardware is already enabled during the boot process, when the Linux watchdog driver loads, it should start/reset the watchdog and tell the watchdog framework. As a result, ping can be generated from the watchdog framework (if CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set), until the userspace watchdog daemon takes over control Fixes:4332d113 ("watchdog: Add STM32 IWDG driver") Signed-off-by:
Christophe Roullier <christophe.roullier@st.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20191122132246.8473-1-christophe.roullier@st.com Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Horia Geantă authored
commit 53146d15 upstream. Fixes: 8d818c10 ("crypto: caam/qi2 - add DPAA2-CAAM driver") Signed-off-by:
Horia Geantă <horia.geanta@nxp.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Eric Biggers authored
commit b529f198 upstream. HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only fail due to -ENOMEM. But atmel_sha_hmac_setkey() incorrectly treated any error as a "bad key length" error. Fix it to correctly propagate the -ENOMEM error code and not set any tfm result flags. Fixes: 81d8750b ("crypto: atmel-sha - add support to hmac(shaX)") Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Reviewed-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Eric Biggers authored
commit b828f905 upstream. ->setkey() is supposed to retun -EINVAL for invalid key lengths, not -1. Fixes: a21eb94f ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver") Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Lars Persson <lars.persson@axis.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Acked-by:
Lars Persson <lars.persson@axis.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Eric Biggers authored
commit eb455dbd upstream. Currently if the comparison fuzz tests encounter an encryption error when generating an skcipher or AEAD test vector, they will still test the decryption side (passing it the uninitialized ciphertext buffer) and expect it to fail with the same error. This is sort of broken because it's not well-defined usage of the API to pass an uninitialized buffer, and furthermore in the AEAD case it's acceptable for the decryption error to be EBADMSG (meaning "inauthentic input") even if the encryption error was something else like EINVAL. Fix this for skcipher by explicitly initializing the ciphertext buffer on error, and for AEAD by skipping the decryption test on error. Reported-by:
Pascal Van Leeuwen <pvanleeuwen@verimatrix.com> Fixes: d435e10e ("crypto: testmgr - fuzz skciphers against their generic implementation") Fixes: 40153b10 ("crypto: testmgr - fuzz AEADs against their generic implementation") Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Arnd Bergmann authored
commit 6b5ca646 upstream. On arm32, we get warnings about high stack usage in some of the functions: crypto/testmgr.c:2269:12: error: stack frame size of 1032 bytes in function 'alg_test_aead' [-Werror,-Wframe-larger-than=] static int alg_test_aead(const struct alg_test_desc *desc, const char *driver, ^ crypto/testmgr.c:1693:12: error: stack frame size of 1312 bytes in function '__alg_test_hash' [-Werror,-Wframe-larger-than=] static int __alg_test_hash(const struct hash_testvec *vecs, ^ On of the larger objects on the stack here is struct testvec_config, so change that to dynamic allocation. Fixes: 40153b10 ("crypto: testmgr - fuzz AEADs against their generic implementation") Fixes: d435e10e ("crypto: testmgr - fuzz skciphers against their generic implementation") Fixes: 9a8a6b3f ("crypto: testmgr - fuzz hashes against their generic implementation") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Eric Biggers <ebiggers@kernel.org> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
YueHaibing authored
commit f33113b5 upstream. The unsigned variable log_num is being assigned a return value from the call to sharpsl_nand_get_logical_num that can return -EINVAL. Detected using Coccinelle: ./drivers/mtd/parsers/sharpslpart.c:207:6-13: WARNING: Unsigned expression compared with zero: log_num > 0 Fixes: 8a4580e4 ("mtd: sharpslpart: Add sharpslpart partition parser") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Nathan Chancellor authored
commit 0e7ca83e upstream. Clang warns: ../drivers/mtd/nand/onenand/onenand_base.c:1269:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] while (!ret) { ^ ../drivers/mtd/nand/onenand/onenand_base.c:1266:2: note: previous statement is here if (column + thislen > writesize) ^ 1 warning generated. This warning occurs because there is a space before the tab of the while loop. There are spaces at the beginning of a lot of the lines in this block, remove them so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. Fixes: a8de85d5 ("[MTD] OneNAND: Implement read-while-load") Link: https://github.com/ClangBuiltLinux/linux/issues/794 Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Suzuki K Poulose authored
commit 52f73c38 upstream. We detect the absence of FP/SIMD after an incapable CPU is brought up, and by then we have kernel threads running already with TIF_FOREIGN_FPSTATE set which could be set for early userspace applications (e.g, modprobe triggered from initramfs) and init. This could cause the applications to loop forever in do_nofity_resume() as we never clear the TIF flag, once we now know that we don't support FP. Fix this by making sure that we clear the TIF_FOREIGN_FPSTATE flag for tasks which may have them set, as we would have done in the normal case, but avoiding touching the hardware state (since we don't support any). Also to make sure we handle the cases seemlessly we categorise the helper functions to two : 1) Helpers for common core code, which calls into take appropriate actions without knowing the current FPSIMD state of the CPU/task. e.g fpsimd_restore_current_state(), fpsimd_flush_task_state(), fpsimd_save_and_flush_cpu_state(). We bail out early for these functions, taking any appropriate actions (e.g, clearing the TIF flag) where necessary to hide the handling from core code. 2) Helpers used when the presence of FP/SIMD is apparent. i.e, save/restore the FP/SIMD register state, modify the CPU/task FP/SIMD state. e.g, fpsimd_save(), task_fpsimd_load() - save/restore task FP/SIMD registers fpsimd_bind_task_to_cpu() \ - Update the "state" metadata for CPU/task. fpsimd_bind_state_to_cpu() / fpsimd_update_current_state() - Update the fp/simd state for the current task from memory. These must not be called in the absence of FP/SIMD. Put in a WARNING to make sure they are not invoked in the absence of FP/SIMD. KVM also uses the TIF_FOREIGN_FPSTATE flag to manage the FP/SIMD state on the CPU. However, without FP/SIMD support we trap all accesses and inject undefined instruction. Thus we should never "load" guest state. Add a sanity check to make sure this is valid. Fixes: 82e0191a ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Julien Grall authored
commit 6dcdefcd upstream. When the kernel is compiled with CONFIG_KERNEL_MODE_NEON, some part of the kernel may be able to use FPSIMD/SVE. This is for instance the case for crypto code. Any use of FPSIMD/SVE in the kernel are clearly marked by using the function kernel_neon_{begin, end}. Furthermore, this can only be used when may_use_simd() returns true. The current implementation of may_use_simd() allows softirq to use FPSIMD/SVE unless it is currently in use (i.e kernel_neon_busy is true). When in use, softirqs usually fall back to a software method. At the moment, as a softirq may use FPSIMD/SVE, softirqs are disabled when touching the FPSIMD/SVE context. This has the drawback to disable all softirqs even if they are not using FPSIMD/SVE. Since a softirq is supposed to check may_use_simd() anyway before attempting to use FPSIMD/SVE, there is limited reason to keep softirq disabled when touching the FPSIMD/SVE context. Instead, we can simply disable preemption and mark the FPSIMD/SVE context as in use by setting CPU's fpsimd_context_busy flag. Two new helpers {get, put}_cpu_fpsimd_context are introduced to mark the area using FPSIMD/SVE context and they are used to replace local_bh_{disable, enable}. The functions kernel_neon_{begin, end} are also re-implemented to use the new helpers. Additionally, double-underscored versions of the helpers are provided to called when preemption is already disabled. These are only relevant on paths where irqs are disabled anyway, so they are not needed for correctness in the current code. Let's use them anyway though: this marks critical sections clearly and will help to avoid mistakes during future maintenance. The change has been benchmarked on Linux 5.1-rc4 with defconfig. On Juno2: * hackbench 100 process 1000 (10 times) * .7% quicker On ThunderX 2: * hackbench 1000 process 1000 (20 times) * 3.4% quicker Reviewed-by:
Dave Martin <dave.martin@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Julien Grall authored
commit 54b8c7cb upstream. The only external user of fpsimd_save() and fpsimd_flush_cpu_state() is the KVM FPSIMD code. A following patch will introduce a mechanism to acquire owernship of the FPSIMD/SVE context for performing context management operations. Rather than having to export the new helpers to get/put the context, we can just introduce a new function to combine fpsimd_save() and fpsimd_flush_cpu_state(). This has also the advantage to remove any external call of fpsimd_save() and fpsimd_flush_cpu_state(), so they can be turned static. Lastly, the new function can also be used in the PM notifier. Reviewed-by:
Dave Martin <Dave.Martin@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Julien Grall authored
commit 6fa9b41f upstream. The function sve_flush_cpu_state() has been removed in commit 21cdd7fd ("KVM: arm64: Remove eager host SVE state saving"). So remove the associated prototype in asm/fpsimd.h. Reviewed-by:
Dave Martin <Dave.Martin@arm.com> Acked-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Alexandru Elisei authored
commit 4a267aa7 upstream. According to the ARM ARM, registers CNT{P,V}_TVAL_EL0 have bits [63:32] RES0 [1]. When reading the register, the value is truncated to the least significant 32 bits [2], and on writes, TimerValue is treated as a signed 32-bit integer [1, 2]. When the guest behaves correctly and writes 32-bit values, treating TVAL as an unsigned 64 bit register works as expected. However, things start to break down when the guest writes larger values, because (u64)0x1_ffff_ffff = 8589934591. but (s32)0x1_ffff_ffff = -1, and the former will cause the timer interrupt to be asserted in the future, but the latter will cause it to be asserted now. Let's treat TVAL as a signed 32-bit register on writes, to match the behaviour described in the architecture, and the behaviour experimentally exhibited by the virtual timer on a non-vhe host. [1] Arm DDI 0487E.a, section D13.8.18 [2] Arm DDI 0487E.a, section D11.2.4 Signed-off-by:
Alexandru Elisei <alexandru.elisei@arm.com> [maz: replaced the read-side mask with lower_32_bits] Signed-off-by:
Marc Zyngier <maz@kernel.org> Fixes: 8fa76162 ("KVM: arm/arm64: arch_timer: Fix CNTP_TVAL calculation") Link: https://lore.kernel.org/r/20200127103652.2326-1-alexandru.elisei@arm.com Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Eric Auger authored
commit 3837407c upstream. The specification says PMSWINC increments PMEVCNTR<n>_EL1 by 1 if PMEVCNTR<n>_EL0 is enabled and configured to count SW_INCR. For PMEVCNTR<n>_EL0 to be enabled, we need both PMCNTENSET to be set for the corresponding event counter but we also need the PMCR.E bit to be set. Fixes: 7a0adc70 ("arm64: KVM: Add access handler for PMSWINC register") Signed-off-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Reviewed-by:
Andrew Murray <andrew.murray@arm.com> Acked-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200124142535.29386-2-eric.auger@redhat.com Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
James Morse authored
commit 21aecdbd upstream. KVM's inject_abt64() injects an external-abort into an aarch64 guest. The KVM_CAP_ARM_INJECT_EXT_DABT is intended to do exactly this, but for an aarch32 guest inject_abt32() injects an implementation-defined exception, 'Lockdown fault'. Change this to external abort. For non-LPAE we now get the documented: | Unhandled fault: external abort on non-linefetch (0x008) at 0x9c800f00 and for LPAE: | Unhandled fault: synchronous external abort (0x210) at 0x9c800f00 Fixes: 74a64a98 ("KVM: arm/arm64: Unify 32bit fault injection") Reported-by:
Beata Michalska <beata.michalska@linaro.org> Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200121123356.203000-3-james.morse@arm.com Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
James Morse authored
commit 018f22f9 upstream. Beata reports that KVM_SET_VCPU_EVENTS doesn't inject the expected exception to a non-LPAE aarch32 guest. The host intends to inject DFSR.FS=0x14 "IMPLEMENTATION DEFINED fault (Lockdown fault)", but the guest receives DFSR.FS=0x04 "Fault on instruction cache maintenance". This fault is hooked by do_translation_fault() since ARMv6, which goes on to silently 'handle' the exception, and restart the faulting instruction. It turns out, when TTBCR.EAE is clear DFSR is split, and FS[4] has to shuffle up to DFSR[10]. As KVM only does this in one place, fix up the static values. We now get the expected: | Unhandled fault: lock abort (0x404) at 0x9c800f00 Fixes: 74a64a98 ("KVM: arm/arm64: Unify 32bit fault injection") Reported-by:
Beata Michalska <beata.michalska@linaro.org> Signed-off-by:
James Morse <james.morse@arm.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200121123356.203000-2-james.morse@arm.com Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Gavin Shan authored
commit cf2d23e0 upstream. kvm_test_age_hva() is called upon mmu_notifier_test_young(), but wrong address range has been passed to handle_hva_to_gpa(). With the wrong address range, no young bits will be checked in handle_hva_to_gpa(). It means zero is always returned from mmu_notifier_test_young(). This fixes the issue by passing correct address range to the underly function handle_hva_to_gpa(), so that the hardware young (access) bit will be visited. Fixes: 35307b9a ("arm/arm64: KVM: Implement Stage-2 page aging") Signed-off-by:
Gavin Shan <gshan@redhat.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20200121055659.19560-1-gshan@redhat.com Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Suzuki K Poulose authored
commit c9d66999 upstream. When fp/simd is not supported on the system, fail the operations of FP/SIMD regsets. Fixes: 82e0191a ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Suzuki K Poulose authored
commit 7559950a upstream. We set the compat_elf_hwcap bits unconditionally on arm64 to include the VFP and NEON support. However, the FP/SIMD unit is optional on Arm v8 and thus could be missing. We already handle this properly in the kernel, but still advertise to the COMPAT applications that the VFP is available. Fix this to make sure we only advertise when we really have them. Fixes: 82e0191a ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Suzuki K Poulose authored
commit 449443c0 upstream. The NO_FPSIMD capability is defined with scope SYSTEM, which implies that the "absence" of FP/SIMD on at least one CPU is detected only after all the SMP CPUs are brought up. However, we use the status of this capability for every context switch. So, let us change the scope to LOCAL_CPU to allow the detection of this capability as and when the first CPU without FP is brought up. Also, the current type allows hotplugged CPU to be brought up without FP/SIMD when all the current CPUs have FP/SIMD and we have the userspace up. Fix both of these issues by changing the capability to BOOT_RESTRICTED_LOCAL_CPU_FEATURE. Fixes: 82e0191a ("arm64: Support systems without FP/ASIMD") Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Reviewed-by:
Ard Biesheuvel <ardb@kernel.org> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-
Eric Auger authored
commit 8c58be34 upstream. Saving/restoring an unmapped collection is a valid scenario. For example this happens if a MAPTI command was sent, featuring an unmapped collection. At the moment the CTE fails to be restored. Only compare against the number of online vcpus if the rdist base is set. Fixes: ea1ad53e ("KVM: arm64: vgic-its: Collection table save/restore") Signed-off-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
Marc Zyngier <maz@kernel.org> Reviewed-by:
Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191213094237.19627-1-eric.auger@redhat.com Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com>
-