kernel.git/drivers/firmware/qcom_scm.c, branch linux-5.11.y

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

2021-05-14T08:49:44Z

[ 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:49:44Z

[ 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:49:44Z

[ 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

media: firmware: qcom_scm: Add memory protect virtual address ranges

2020-09-14T13:45:25Z

This adds a new SCM memprotect command to set virtual address ranges. Signed-off-by: Stanimir Varbanov Reviewed-by: Elliot Berman Acked-by: Bjorn Andersson Signed-off-by: Mauro Carvalho Chehab

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2020-08-06T23:50:07Z

Pull SCSI updates from James Bottomley: "This consists of the usual driver updates (ufs, qla2xxx, tcmu, lpfc, hpsa, zfcp, scsi_debug) and minor bug fixes. We also have a huge docbook fix update like most other subsystems and no major update to the core (the few non trivial updates are either minor fixes or removing an unused feature [scsi_sdb_cache])" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (307 commits) scsi: scsi_transport_srp: Sanitize scsi_target_block/unblock sequences scsi: ufs-mediatek: Apply DELAY_AFTER_LPM quirk to Micron devices scsi: ufs: Introduce device quirk "DELAY_AFTER_LPM" scsi: virtio-scsi: Correctly handle the case where all LUNs are unplugged scsi: scsi_debug: Implement tur_ms_to_ready parameter scsi: scsi_debug: Fix request sense scsi: lpfc: Fix typo in comment for ULP scsi: ufs-mediatek: Prevent LPM operation on undeclared VCC scsi: iscsi: Do not put host in iscsi_set_flashnode_param() scsi: hpsa: Correct ctrl queue depth scsi: target: tcmu: Make TMR notification optional scsi: target: tcmu: Implement tmr_notify callback scsi: target: tcmu: Fix and simplify timeout handling scsi: target: tcmu: Factor out new helper ring_insert_padding scsi: target: tcmu: Do not queue aborted commands scsi: target: tcmu: Use priv pointer in se_cmd scsi: target: Add tmr_notify backend function scsi: target: Modify core_tmr_abort_task() scsi: target: iscsi: Fix inconsistent debug message scsi: target: iscsi: Fix login error when receiving ...

scsi: firmware: qcom_scm: Add support for programming inline crypto keys

2020-07-25T02:09:54Z

Add support for the Inline Crypto Engine (ICE) key programming interface that's needed for the ufs-qcom driver to use inline encryption on Snapdragon SoCs. This interface consists of two SCM calls: one to program a key into a keyslot, and one to invalidate a keyslot. Although the UFS specification defines a standard way to do this, on these SoCs the Linux kernel isn't permitted to access the needed crypto configuration registers directly; these SCM calls must be used instead. Link: https://lore.kernel.org/r/20200710072013.177481-2-ebiggers@kernel.org Acked-by: Bjorn Andersson Signed-off-by: Eric Biggers Signed-off-by: Martin K. Petersen

firmware: qcom_scm: Add msm8994 compatible

2020-07-13T19:26:04Z

This change adds a compatible for msm8994, which requires no additional clocks for scm to probe correctly. Acked-by: Rob Herring Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20200624150107.76234-2-konradybcio@gmail.com Signed-off-by: Bjorn Andersson

firmware: qcom_scm: Fix legacy convention SCM accessors

2020-07-13T18:41:43Z

The move to a combined driver for the QCOM SCM hardware changed the io_writel and io_readl helpers to use non-atomic calls, despite the commit message saying that atomic was a better option. This breaks these helpers on hardware that uses the old legacy convention (access fails with a -95 return code). Switch back to using the atomic calls. Observed as a failure routing GPIO interrupts to the Apps processor on an IPQ8064; fix is confirmed as correctly allowing the interrupts to be routed and observed. Reviewed-by: Elliot Berman Fixes: 57d3b816718c ("firmware: qcom_scm: Remove thin wrappers") Cc: stable@vger.kernel.org Signed-off-by: Jonathan McDowell Link: https://lore.kernel.org/r/20200704172334.GA759@earth.li Signed-off-by: Bjorn Andersson

firmware: qcom_scm: fix bogous abuse of dma-direct internals

2020-04-21T06:20:00Z

As far as the device is concerned the dma address is the physical address. There is no need to convert it to a physical address, especially not using dma-direct internals that are not available to drivers and which will interact badly with IOMMUs. Last but not least the commit introducing it claimed to just fix a type issue, but actually changed behavior. Fixes: 6e37ccf78a532 ("firmware: qcom_scm: Use proper types for dma mappings") Reviewed-by: Bjorn Andersson Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20200414123136.441454-1-hch@lst.de Signed-off-by: Bjorn Andersson

firmware: qcom_scm: Remove unneeded conversion to bool

2020-04-20T19:51:55Z

The '>' expression itself is bool, no need to convert it to bool again. This fixes the following coccicheck warning: drivers/firmware/qcom_scm.c:946:25-30: WARNING: conversion to bool not needed here Reviewed-by: Bjorn Andersson Signed-off-by: Jason Yan Link: https://lore.kernel.org/r/20200420123516.7888-1-yanaijie@huawei.com Signed-off-by: Bjorn Andersson