user/sven/linux.git/drivers/firmware, branch v5.12.8

firmware: arm_scpi: Prevent the ternary sign expansion bug

2021-05-26T10:59:02Z

[ Upstream commit d9cd78edb2e6b7e26747c0ec312be31e7ef196fe ] How the type promotion works in ternary expressions is a bit tricky. The problem is that scpi_clk_get_val() returns longs, "ret" is a int which holds a negative error code, and le32_to_cpu() is an unsigned int. We want the negative error code to be cast to a negative long. But because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and becomes a high positive and then it is promoted to long and it is still a high positive value. Fix this by getting rid of the ternary. Link: https://lore.kernel.org/r/YIE7pdqV/h10tEAK@mwanda Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Reviewed-by: Cristian Marussi Signed-off-by: Dan Carpenter [sudeep.holla: changed to return 0 as clock rate on error] Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

firmware: qcom-scm: Fix QCOM_SCM configuration

2021-05-14T08:52:30Z

[ Upstream commit 2954a6f12f250890ec2433cec03ba92784d613e8 ] When CONFIG_QCOM_SCM is y and CONFIG_HAVE_ARM_SMCCC is not set, compiling errors are encountered as follows: drivers/firmware/qcom_scm-smc.o: In function `__scm_smc_do_quirk': qcom_scm-smc.c:(.text+0x36): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call': qcom_scm-legacy.c:(.text+0xe2): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call_atomic': qcom_scm-legacy.c:(.text+0x1f0): undefined reference to `__arm_smccc_smc' Note that __arm_smccc_smc is defined when HAVE_ARM_SMCCC is y. So add dependency on HAVE_ARM_SMCCC in QCOM_SCM configuration. Fixes: 916f743da354 ("firmware: qcom: scm: Move the scm driver to drivers/firmware") Reported-by: Hulk Robot Signed-off-by: He Ying Link: https://lore.kernel.org/r/20210406094200.60952-1-heying24@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

firmware: qcom_scm: Workaround lack of "is available" call on SC7180

2021-05-14T08:52:26Z

[ Upstream commit 257f2935cbbf14b16912c635fcd8ff43345c953b ] Some SC7180 firmwares don't implement the QCOM_SCM_INFO_IS_CALL_AVAIL API, so we can't probe the calling convention. We detect the legacy calling convention on these firmwares, because the availability call always fails and legacy is the fallback. This leads to problems where the rmtfs driver fails to probe, because it tries to assign memory with a bad calling convention, which then leads to modem failing to load and all networking, even wifi, to fail. Ouch! Let's force the calling convention to be what it always is on this SoC, i.e. arm64. Of course, the calling convention is not the same thing as implementing the QCOM_SCM_INFO_IS_CALL_AVAIL API. The absence of the "is this call available" API from the firmware means that any call to __qcom_scm_is_call_available() fails. This is OK for now though because none of the calls that are checked for existence are implemented on firmware running on sc7180. If such a call needs to be checked for existence in the future, we presume that firmware will implement this API and then things will "just work". Cc: Elliot Berman Cc: Brian Masney Cc: Stephan Gerhold Cc: Jeffrey Hugo Cc: Douglas Anderson Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210223214539.1336155-4-swboyd@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

firmware: qcom_scm: Reduce locking section for __get_convention()

2021-05-14T08:52:26Z

[ Upstream commit f6ea568f0ddcdfad52807110ed8983e610f0e03b ] We shouldn't need to hold this spinlock here around the entire SCM call into the firmware and back. Instead, we should be able to query the firmware, potentially in parallel with other CPUs making the same convention detection firmware call, and then grab the lock to update the calling convention detected. The convention doesn't change at runtime so calling into firmware more than once is possibly wasteful but simpler. Besides, this is the slow path, not the fast path where we've already detected the convention used. More importantly, this allows us to add more logic here to workaround the case where the firmware call to check for availability isn't implemented in the firmware at all. In that case we can check the firmware node compatible string and force a calling convention. Note that we remove the 'has_queried' logic that is repeated twice. That could lead to the calling convention being printed multiple times to the kernel logs if the bool is true but __query_convention() is running on multiple CPUs. We also shorten the time where the lock is held, but we keep the lock held around the printk because it doesn't seem hugely important to drop it for that. Cc: Elliot Berman Cc: Brian Masney Cc: Stephan Gerhold Cc: Jeffrey Hugo Cc: Douglas Anderson Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

firmware: qcom_scm: Make __qcom_scm_is_call_available() return bool

2021-05-14T08:52:26Z

[ Upstream commit 9d11af8b06a811c5c4878625f51ce109e2af4e80 ] Make __qcom_scm_is_call_available() return bool instead of int. The function has "is" in the name, so it should return a bool to indicate the truth of the call being available. Unfortunately, it can return a number < 0 which also looks "true", but not all callers expect that and thus they think a call is available when really the check to see if the call is available failed to figure it out. Reviewed-by: Bjorn Andersson Cc: Elliot Berman Cc: Brian Masney Cc: Stephan Gerhold Cc: Jeffrey Hugo Cc: Douglas Anderson Fixes: 0f206514749b ("scsi: firmware: qcom_scm: Add support for programming inline crypto keys") Fixes: 0434a4061471 ("firmware: qcom: scm: add support to restore secure config to qcm_scm-32") Fixes: b0a1614fb1f5 ("firmware: qcom: scm: add OCMEM lock/unlock interface") Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20210223214539.1336155-2-swboyd@chromium.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

firmware: xilinx: Fix dereferencing freed memory

2021-05-14T08:52:14Z

[ Upstream commit f1f21bece82c76a56a96988ec7d51ccc033d8949 ] Fix smatch warning: drivers/firmware/xilinx/zynqmp.c:1288 zynqmp_firmware_remove() error: dereferencing freed memory 'feature_data' Use hash_for_each_safe for safe removal of hash entry. Fixes: acfdd18591ea ("firmware: xilinx: Use hash-table for api feature check") Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Tejas Patel Signed-off-by: Rajan Vaja Link: https://lore.kernel.org/r/1612765883-22018-1-git-send-email-rajan.vaja@xilinx.com Signed-off-by: Michal Simek Signed-off-by: Sasha Levin

efi/libstub: Add $(CLANG_FLAGS) to x86 flags

2021-05-12T06:39:35Z

[ Upstream commit 58d746c119dfa28e72fc35aacaf3d2a3ac625cd0 ] When cross compiling x86 on an ARM machine with clang, there are several errors along the lines of: arch/x86/include/asm/page_64.h:52:7: error: invalid output constraint '=D' in asm This happens because the x86 flags in the EFI stub are not derived from KBUILD_CFLAGS like the other architectures are and the clang flags that set the target architecture ('--target=') and the path to the GNU cross tools ('--prefix=') are not present, meaning that the host architecture is targeted. These flags are available as $(CLANG_FLAGS) from the main Makefile so add them to the cflags for x86 so that cross compiling works as expected. Signed-off-by: Nathan Chancellor Signed-off-by: Borislav Petkov Acked-by: Ard Biesheuvel Link: https://lkml.kernel.org/r/20210326000435.4785-4-nathan@kernel.org Signed-off-by: Sasha Levin

treewide: change my e-mail address, fix my name

2021-04-09T21:54:23Z

Change my e-mail address to kabel@kernel.org, and fix my name in non-code parts (add diacritical mark). Link: https://lkml.kernel.org/r/20210325171123.28093-2-kabel@kernel.org Signed-off-by: Marek Behún Cc: Bartosz Golaszewski Cc: Greg Kroah-Hartman Cc: Jassi Brar Cc: Linus Walleij Cc: Pavel Machek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge tag 'efi-urgent-for-v5.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/urgent

2021-03-19T13:23:46Z

Pull EFI fixes from Ard Biesheuvel: "- another missing RT_PROP table related fix, to ensure that the efivarfs pseudo filesystem fails gracefully if variable services are unsupported - use the correct alignment for literal EFI GUIDs - fix a use after unmap issue in the memreserve code" Signed-off-by: Ingo Molnar

firmware/efi: Fix a use after bug in efi_mem_reserve_persistent

2021-03-19T06:44:27Z

In the for loop in efi_mem_reserve_persistent(), prsv = rsv->next use the unmapped rsv. Use the unmapped pages will cause segment fault. Fixes: 18df7577adae6 ("efi/memreserve: deal with memreserve entries in unmapped memory") Signed-off-by: Lv Yunlong Signed-off-by: Ard Biesheuvel