Centos-kernel-stream-9/drivers/firmware/qcom/qcom_scm.c

2163 lines
54 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0-only
/* Copyright (c) 2010,2015,2019 The Linux Foundation. All rights reserved.
* Copyright (C) 2015 Linaro Ltd.
*/
#include <linux/arm-smccc.h>
#include <linux/bitfield.h>
#include <linux/bits.h>
#include <linux/cleanup.h>
#include <linux/clk.h>
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
#include <linux/completion.h>
#include <linux/cpumask.h>
#include <linux/dma-mapping.h>
#include <linux/err.h>
#include <linux/export.h>
#include <linux/firmware/qcom/qcom_scm.h>
#include <linux/firmware/qcom/qcom_tzmem.h>
#include <linux/init.h>
#include <linux/interconnect.h>
#include <linux/interrupt.h>
#include <linux/kstrtox.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_address.h>
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/of_reserved_mem.h>
#include <linux/platform_device.h>
#include <linux/reset-controller.h>
#include <linux/sizes.h>
#include <linux/types.h>
#include "qcom_scm.h"
#include "qcom_tzmem.h"
static u32 download_mode;
#define SCM_HAS_CORE_CLK BIT(0)
#define SCM_HAS_IFACE_CLK BIT(1)
#define SCM_HAS_BUS_CLK BIT(2)
struct qcom_scm {
struct device *dev;
struct clk *core_clk;
struct clk *iface_clk;
struct clk *bus_clk;
struct icc_path *path;
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
struct completion waitq_comp;
struct reset_controller_dev reset;
/* control access to the interconnect path */
struct mutex scm_bw_lock;
int scm_vote_count;
u64 dload_mode_addr;
struct qcom_tzmem_pool *mempool;
};
struct qcom_scm_current_perm_info {
__le32 vmid;
__le32 perm;
__le64 ctx;
__le32 ctx_size;
__le32 unused;
};
struct qcom_scm_mem_map_info {
__le64 mem_addr;
__le64 mem_size;
};
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
/**
* struct qcom_scm_qseecom_resp - QSEECOM SCM call response.
* @result: Result or status of the SCM call. See &enum qcom_scm_qseecom_result.
* @resp_type: Type of the response. See &enum qcom_scm_qseecom_resp_type.
* @data: Response data. The type of this data is given in @resp_type.
*/
struct qcom_scm_qseecom_resp {
u64 result;
u64 resp_type;
u64 data;
};
enum qcom_scm_qseecom_result {
QSEECOM_RESULT_SUCCESS = 0,
QSEECOM_RESULT_INCOMPLETE = 1,
QSEECOM_RESULT_BLOCKED_ON_LISTENER = 2,
QSEECOM_RESULT_FAILURE = 0xFFFFFFFF,
};
enum qcom_scm_qseecom_resp_type {
QSEECOM_SCM_RES_APP_ID = 0xEE01,
QSEECOM_SCM_RES_QSEOS_LISTENER_ID = 0xEE02,
};
enum qcom_scm_qseecom_tz_owner {
QSEECOM_TZ_OWNER_SIP = 2,
QSEECOM_TZ_OWNER_TZ_APPS = 48,
QSEECOM_TZ_OWNER_QSEE_OS = 50
};
enum qcom_scm_qseecom_tz_svc {
QSEECOM_TZ_SVC_APP_ID_PLACEHOLDER = 0,
QSEECOM_TZ_SVC_APP_MGR = 1,
QSEECOM_TZ_SVC_INFO = 6,
};
enum qcom_scm_qseecom_tz_cmd_app {
QSEECOM_TZ_CMD_APP_SEND = 1,
QSEECOM_TZ_CMD_APP_LOOKUP = 3,
};
enum qcom_scm_qseecom_tz_cmd_info {
QSEECOM_TZ_CMD_INFO_VERSION = 3,
};
#define QSEECOM_MAX_APP_NAME_SIZE 64
firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling JIRA: https://issues.redhat.com/browse/RHEL-73299 commit f489f6c6eb26482010470d77bad3901a3de1b166 Author: Qingqing Zhou <quic_qqzhou@quicinc.com> Date: Wed Oct 23 00:51:48 2024 +0530 firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling When enabling SHM bridge, QTEE returns 0 and sets error 4 in result to qcom_scm for unsupported platforms. Currently, tzmem interprets this as an unknown error rather than recognizing it as an unsupported platform. Error log: [ 0.177224] qcom_scm firmware:scm: error (____ptrval____): Failed to enable the TrustZone memory allocator [ 0.177244] qcom_scm firmware:scm: probe with driver qcom_scm failed with error 4 To address this, modify the function call qcom_scm_shm_bridge_enable() to remap result to indicate an unsupported error. This way, tzmem will correctly identify it as an unsupported platform case instead of reporting it as an error. Fixes: 178e19c0df1b ("firmware: qcom: scm: add support for SHM bridge operations") Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com> Co-developed-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Signed-off-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20241022192148.1626633-1-quic_kuldsing@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:59:29 +00:00
#define SHMBRIDGE_RESULT_NOTSUPP 4
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
/* Each bit configures cold/warm boot address for one of the 4 CPUs */
static const u8 qcom_scm_cpu_cold_bits[QCOM_SCM_BOOT_MAX_CPUS] = {
0, BIT(0), BIT(3), BIT(5)
};
static const u8 qcom_scm_cpu_warm_bits[QCOM_SCM_BOOT_MAX_CPUS] = {
BIT(2), BIT(1), BIT(4), BIT(6)
};
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
#define QCOM_SMC_WAITQ_FLAG_WAKE_ONE BIT(0)
#define QCOM_SMC_WAITQ_FLAG_WAKE_ALL BIT(1)
#define QCOM_DLOAD_MASK GENMASK(5, 4)
#define QCOM_DLOAD_NODUMP 0
#define QCOM_DLOAD_FULLDUMP 1
#define QCOM_DLOAD_MINIDUMP 2
#define QCOM_DLOAD_BOTHDUMP 3
static const char * const qcom_scm_convention_names[] = {
[SMC_CONVENTION_UNKNOWN] = "unknown",
[SMC_CONVENTION_ARM_32] = "smc arm 32",
[SMC_CONVENTION_ARM_64] = "smc arm 64",
[SMC_CONVENTION_LEGACY] = "smc legacy",
};
static const char * const download_mode_name[] = {
[QCOM_DLOAD_NODUMP] = "off",
[QCOM_DLOAD_FULLDUMP] = "full",
[QCOM_DLOAD_MINIDUMP] = "mini",
[QCOM_DLOAD_BOTHDUMP] = "full,mini",
};
static struct qcom_scm *__scm;
static int qcom_scm_clk_enable(void)
{
int ret;
ret = clk_prepare_enable(__scm->core_clk);
if (ret)
goto bail;
ret = clk_prepare_enable(__scm->iface_clk);
if (ret)
goto disable_core;
ret = clk_prepare_enable(__scm->bus_clk);
if (ret)
goto disable_iface;
return 0;
disable_iface:
clk_disable_unprepare(__scm->iface_clk);
disable_core:
clk_disable_unprepare(__scm->core_clk);
bail:
return ret;
}
static void qcom_scm_clk_disable(void)
{
clk_disable_unprepare(__scm->core_clk);
clk_disable_unprepare(__scm->iface_clk);
clk_disable_unprepare(__scm->bus_clk);
}
static int qcom_scm_bw_enable(void)
{
int ret = 0;
if (!__scm->path)
return 0;
if (IS_ERR(__scm->path))
return -EINVAL;
mutex_lock(&__scm->scm_bw_lock);
if (!__scm->scm_vote_count) {
ret = icc_set_bw(__scm->path, 0, UINT_MAX);
if (ret < 0) {
dev_err(__scm->dev, "failed to set bandwidth request\n");
goto err_bw;
}
}
__scm->scm_vote_count++;
err_bw:
mutex_unlock(&__scm->scm_bw_lock);
return ret;
}
static void qcom_scm_bw_disable(void)
{
if (IS_ERR_OR_NULL(__scm->path))
return;
mutex_lock(&__scm->scm_bw_lock);
if (__scm->scm_vote_count-- == 1)
icc_set_bw(__scm->path, 0, 0);
mutex_unlock(&__scm->scm_bw_lock);
}
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
enum qcom_scm_convention qcom_scm_convention = SMC_CONVENTION_UNKNOWN;
static DEFINE_SPINLOCK(scm_query_lock);
struct qcom_tzmem_pool *qcom_scm_get_tzmem_pool(void)
{
firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool() JIRA: https://issues.redhat.com/browse/RHEL-73299 commit b628510397b5cafa1f5d3e848a28affd1c635302 Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Date: Mon Dec 9 15:27:55 2024 +0100 firmware: qcom: scm: Fix missing read barrier in qcom_scm_get_tzmem_pool() Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq completion variable initialization") introduced a write barrier in probe function to store global '__scm' variable. We all known barriers are paired (see memory-barriers.txt: "Note that write barriers should normally be paired with read or address-dependency barriers"), therefore accessing it from concurrent contexts requires read barrier. Previous commit added such barrier in qcom_scm_is_available(), so let's use that directly. Lack of this read barrier can result in fetching stale '__scm' variable value, NULL, and dereferencing it. Note that barrier in qcom_scm_is_available() satisfies here the control dependency. Fixes: ca61d6836e6f ("firmware: qcom: scm: fix a NULL-pointer dereference") Fixes: 449d0d84bcd8 ("firmware: qcom: scm: smc: switch to using the SCM allocator") Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-2-9061013c8d92@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:59:33 +00:00
if (!qcom_scm_is_available())
return NULL;
return __scm->mempool;
}
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
static enum qcom_scm_convention __get_convention(void)
{
unsigned long flags;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_INFO,
.cmd = QCOM_SCM_INFO_IS_CALL_AVAIL,
.args[0] = SCM_SMC_FNID(QCOM_SCM_SVC_INFO,
QCOM_SCM_INFO_IS_CALL_AVAIL) |
(ARM_SMCCC_OWNER_SIP << ARM_SMCCC_OWNER_SHIFT),
.arginfo = QCOM_SCM_ARGS(1),
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
enum qcom_scm_convention probed_convention;
int ret;
firmware: qcom_scm: Workaround lack of "is available" call on SC7180 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-4-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:36 +00:00
bool forced = false;
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
if (likely(qcom_scm_convention != SMC_CONVENTION_UNKNOWN))
return qcom_scm_convention;
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
/*
* Device isn't required as there is only one argument - no device
* needed to dma_map_single to secure world
*/
probed_convention = SMC_CONVENTION_ARM_64;
ret = __scm_smc_call(NULL, &desc, probed_convention, &res, true);
if (!ret && res.result[0] == 1)
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
goto found;
firmware: qcom_scm: Workaround lack of "is available" call on SC7180 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-4-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:36 +00:00
/*
* Some SC7180 firmwares didn't implement the
* QCOM_SCM_INFO_IS_CALL_AVAIL call, so we fallback to forcing ARM_64
* calling conventions on these firmwares. Luckily we don't make any
* early calls into the firmware on these SoCs so the device pointer
* will be valid here to check if the compatible matches.
*/
if (of_device_is_compatible(__scm ? __scm->dev->of_node : NULL, "qcom,scm-sc7180")) {
forced = true;
goto found;
}
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
probed_convention = SMC_CONVENTION_ARM_32;
ret = __scm_smc_call(NULL, &desc, probed_convention, &res, true);
if (!ret && res.result[0] == 1)
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
goto found;
probed_convention = SMC_CONVENTION_LEGACY;
found:
spin_lock_irqsave(&scm_query_lock, flags);
if (probed_convention != qcom_scm_convention) {
qcom_scm_convention = probed_convention;
firmware: qcom_scm: Workaround lack of "is available" call on SC7180 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-4-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:36 +00:00
pr_info("qcom_scm: convention: %s%s\n",
qcom_scm_convention_names[qcom_scm_convention],
forced ? " (forced)" : "");
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
}
spin_unlock_irqrestore(&scm_query_lock, flags);
return qcom_scm_convention;
}
/**
* qcom_scm_call() - Invoke a syscall in the secure world
* @dev: device
* @desc: Descriptor structure containing arguments and return values
* @res: Structure containing results from SMC/HVC call
*
* Sends a command to the SCM and waits for the command to finish processing.
* This should *only* be called in pre-emptible context.
*/
static int qcom_scm_call(struct device *dev, const struct qcom_scm_desc *desc,
struct qcom_scm_res *res)
{
might_sleep();
switch (__get_convention()) {
case SMC_CONVENTION_ARM_32:
case SMC_CONVENTION_ARM_64:
return scm_smc_call(dev, desc, res, false);
case SMC_CONVENTION_LEGACY:
return scm_legacy_call(dev, desc, res);
default:
pr_err("Unknown current SCM calling convention.\n");
return -EINVAL;
}
}
/**
* qcom_scm_call_atomic() - atomic variation of qcom_scm_call()
* @dev: device
* @desc: Descriptor structure containing arguments and return values
* @res: Structure containing results from SMC/HVC call
*
* Sends a command to the SCM and waits for the command to finish processing.
* This can be called in atomic context.
*/
static int qcom_scm_call_atomic(struct device *dev,
const struct qcom_scm_desc *desc,
struct qcom_scm_res *res)
{
switch (__get_convention()) {
case SMC_CONVENTION_ARM_32:
case SMC_CONVENTION_ARM_64:
return scm_smc_call(dev, desc, res, true);
case SMC_CONVENTION_LEGACY:
return scm_legacy_call_atomic(dev, desc, res);
default:
pr_err("Unknown current SCM calling convention.\n");
return -EINVAL;
}
}
static bool __qcom_scm_is_call_available(struct device *dev, u32 svc_id,
u32 cmd_id)
{
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_INFO,
.cmd = QCOM_SCM_INFO_IS_CALL_AVAIL,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
desc.arginfo = QCOM_SCM_ARGS(1);
switch (__get_convention()) {
case SMC_CONVENTION_ARM_32:
case SMC_CONVENTION_ARM_64:
desc.args[0] = SCM_SMC_FNID(svc_id, cmd_id) |
(ARM_SMCCC_OWNER_SIP << ARM_SMCCC_OWNER_SHIFT);
break;
case SMC_CONVENTION_LEGACY:
desc.args[0] = SCM_LEGACY_FNID(svc_id, cmd_id);
break;
default:
pr_err("Unknown SMC convention being used\n");
return false;
}
ret = qcom_scm_call(dev, &desc, &res);
return ret ? false : !!res.result[0];
}
static int qcom_scm_set_boot_addr(void *entry, const u8 *cpu_bits)
{
int cpu;
unsigned int flags = 0;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_BOOT,
.cmd = QCOM_SCM_BOOT_SET_ADDR,
.arginfo = QCOM_SCM_ARGS(2),
.owner = ARM_SMCCC_OWNER_SIP,
};
for_each_present_cpu(cpu) {
if (cpu >= QCOM_SCM_BOOT_MAX_CPUS)
return -EINVAL;
flags |= cpu_bits[cpu];
}
desc.args[0] = flags;
desc.args[1] = virt_to_phys(entry);
return qcom_scm_call_atomic(__scm ? __scm->dev : NULL, &desc, NULL);
}
static int qcom_scm_set_boot_addr_mc(void *entry, unsigned int flags)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_BOOT,
.cmd = QCOM_SCM_BOOT_SET_ADDR_MC,
.owner = ARM_SMCCC_OWNER_SIP,
.arginfo = QCOM_SCM_ARGS(6),
.args = {
virt_to_phys(entry),
/* Apply to all CPUs in all affinity levels */
~0ULL, ~0ULL, ~0ULL, ~0ULL,
flags,
},
};
/* Need a device for DMA of the additional arguments */
if (!__scm || __get_convention() == SMC_CONVENTION_LEGACY)
return -EOPNOTSUPP;
return qcom_scm_call(__scm->dev, &desc, NULL);
}
/**
* qcom_scm_set_warm_boot_addr() - Set the warm boot address for all cpus
* @entry: Entry point function for the cpus
*
* Set the Linux entry point for the SCM to transfer control to when coming
* out of a power down. CPU power down may be executed on cpuidle or hotplug.
*/
int qcom_scm_set_warm_boot_addr(void *entry)
{
if (qcom_scm_set_boot_addr_mc(entry, QCOM_SCM_BOOT_MC_FLAG_WARMBOOT))
/* Fallback to old SCM call */
return qcom_scm_set_boot_addr(entry, qcom_scm_cpu_warm_bits);
return 0;
}
EXPORT_SYMBOL_GPL(qcom_scm_set_warm_boot_addr);
/**
* qcom_scm_set_cold_boot_addr() - Set the cold boot address for all cpus
* @entry: Entry point function for the cpus
*/
int qcom_scm_set_cold_boot_addr(void *entry)
{
if (qcom_scm_set_boot_addr_mc(entry, QCOM_SCM_BOOT_MC_FLAG_COLDBOOT))
/* Fallback to old SCM call */
return qcom_scm_set_boot_addr(entry, qcom_scm_cpu_cold_bits);
return 0;
}
EXPORT_SYMBOL_GPL(qcom_scm_set_cold_boot_addr);
/**
* qcom_scm_cpu_power_down() - Power down the cpu
* @flags: Flags to flush cache
*
* This is an end point to power down cpu. If there was a pending interrupt,
* the control would return from this function, otherwise, the cpu jumps to the
* warm boot entry point set for this cpu upon reset.
*/
void qcom_scm_cpu_power_down(u32 flags)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_BOOT,
.cmd = QCOM_SCM_BOOT_TERMINATE_PC,
.args[0] = flags & QCOM_SCM_FLUSH_FLAG_MASK,
.arginfo = QCOM_SCM_ARGS(1),
.owner = ARM_SMCCC_OWNER_SIP,
};
qcom_scm_call_atomic(__scm ? __scm->dev : NULL, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_cpu_power_down);
int qcom_scm_set_remote_state(u32 state, u32 id)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_BOOT,
.cmd = QCOM_SCM_BOOT_SET_REMOTE_STATE,
.arginfo = QCOM_SCM_ARGS(2),
.args[0] = state,
.args[1] = id,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
int ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
return ret ? : res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_set_remote_state);
static int qcom_scm_disable_sdi(void)
{
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_BOOT,
.cmd = QCOM_SCM_BOOT_SDI_CONFIG,
.args[0] = 1, /* Disable watchdog debug */
.args[1] = 0, /* Disable SDI */
.arginfo = QCOM_SCM_ARGS(2),
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
ret = qcom_scm_clk_enable();
if (ret)
return ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
qcom_scm_clk_disable();
return ret ? : res.result[0];
}
static int __qcom_scm_set_dload_mode(struct device *dev, bool enable)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_BOOT,
.cmd = QCOM_SCM_BOOT_SET_DLOAD_MODE,
.arginfo = QCOM_SCM_ARGS(2),
.args[0] = QCOM_SCM_BOOT_SET_DLOAD_MODE,
.owner = ARM_SMCCC_OWNER_SIP,
};
desc.args[1] = enable ? QCOM_SCM_BOOT_SET_DLOAD_MODE : 0;
return qcom_scm_call_atomic(__scm->dev, &desc, NULL);
}
static int qcom_scm_io_rmw(phys_addr_t addr, unsigned int mask, unsigned int val)
{
unsigned int old;
unsigned int new;
int ret;
ret = qcom_scm_io_readl(addr, &old);
if (ret)
return ret;
new = (old & ~mask) | (val & mask);
return qcom_scm_io_writel(addr, new);
}
static void qcom_scm_set_download_mode(u32 dload_mode)
{
int ret = 0;
if (__scm->dload_mode_addr) {
ret = qcom_scm_io_rmw(__scm->dload_mode_addr, QCOM_DLOAD_MASK,
FIELD_PREP(QCOM_DLOAD_MASK, dload_mode));
} else if (__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_BOOT,
QCOM_SCM_BOOT_SET_DLOAD_MODE)) {
ret = __qcom_scm_set_dload_mode(__scm->dev, !!dload_mode);
} else if (dload_mode) {
dev_err(__scm->dev,
"No available mechanism for setting download mode\n");
}
if (ret)
dev_err(__scm->dev, "failed to set download mode: %d\n", ret);
}
/**
* qcom_scm_pas_init_image() - Initialize peripheral authentication service
* state machine for a given peripheral, using the
* metadata
* @peripheral: peripheral id
* @metadata: pointer to memory containing ELF header, program header table
* and optional blob of data used for authenticating the metadata
* and the rest of the firmware
* @size: size of the metadata
* @ctx: optional metadata context
*
* Return: 0 on success.
*
* Upon successful return, the PAS metadata context (@ctx) will be used to
* track the metadata allocation, this needs to be released by invoking
* qcom_scm_pas_metadata_release() by the caller.
*/
int qcom_scm_pas_init_image(u32 peripheral, const void *metadata, size_t size,
struct qcom_scm_pas_metadata *ctx)
{
dma_addr_t mdata_phys;
void *mdata_buf;
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_PIL,
.cmd = QCOM_SCM_PIL_PAS_INIT_IMAGE,
.arginfo = QCOM_SCM_ARGS(2, QCOM_SCM_VAL, QCOM_SCM_RW),
.args[0] = peripheral,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
/*
* During the scm call memory protection will be enabled for the meta
* data blob, so make sure it's physically contiguous, 4K aligned and
* non-cachable to avoid XPU violations.
*
* For PIL calls the hypervisor creates SHM Bridges for the blob
* buffers on behalf of Linux so we must not do it ourselves hence
* not using the TZMem allocator here.
*
* If we pass a buffer that is already part of an SHM Bridge to this
* call, it will fail.
*/
mdata_buf = dma_alloc_coherent(__scm->dev, size, &mdata_phys,
GFP_KERNEL);
if (!mdata_buf)
return -ENOMEM;
memcpy(mdata_buf, metadata, size);
ret = qcom_scm_clk_enable();
if (ret)
goto out;
ret = qcom_scm_bw_enable();
if (ret)
return ret;
desc.args[1] = mdata_phys;
ret = qcom_scm_call(__scm->dev, &desc, &res);
qcom_scm_bw_disable();
qcom_scm_clk_disable();
out:
if (ret < 0 || !ctx) {
dma_free_coherent(__scm->dev, size, mdata_buf, mdata_phys);
} else if (ctx) {
ctx->ptr = mdata_buf;
ctx->phys = mdata_phys;
ctx->size = size;
}
return ret ? : res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_pas_init_image);
/**
* qcom_scm_pas_metadata_release() - release metadata context
* @ctx: metadata context
*/
void qcom_scm_pas_metadata_release(struct qcom_scm_pas_metadata *ctx)
{
if (!ctx->ptr)
return;
dma_free_coherent(__scm->dev, ctx->size, ctx->ptr, ctx->phys);
ctx->ptr = NULL;
ctx->phys = 0;
ctx->size = 0;
}
EXPORT_SYMBOL_GPL(qcom_scm_pas_metadata_release);
/**
* qcom_scm_pas_mem_setup() - Prepare the memory related to a given peripheral
* for firmware loading
* @peripheral: peripheral id
* @addr: start address of memory area to prepare
* @size: size of the memory area to prepare
*
* Returns 0 on success.
*/
int qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr, phys_addr_t size)
{
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_PIL,
.cmd = QCOM_SCM_PIL_PAS_MEM_SETUP,
.arginfo = QCOM_SCM_ARGS(3),
.args[0] = peripheral,
.args[1] = addr,
.args[2] = size,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
ret = qcom_scm_clk_enable();
if (ret)
return ret;
ret = qcom_scm_bw_enable();
if (ret)
return ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
qcom_scm_bw_disable();
qcom_scm_clk_disable();
return ret ? : res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_pas_mem_setup);
/**
* qcom_scm_pas_auth_and_reset() - Authenticate the given peripheral firmware
* and reset the remote processor
* @peripheral: peripheral id
*
* Return 0 on success.
*/
int qcom_scm_pas_auth_and_reset(u32 peripheral)
{
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_PIL,
.cmd = QCOM_SCM_PIL_PAS_AUTH_AND_RESET,
.arginfo = QCOM_SCM_ARGS(1),
.args[0] = peripheral,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
ret = qcom_scm_clk_enable();
if (ret)
return ret;
ret = qcom_scm_bw_enable();
if (ret)
return ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
qcom_scm_bw_disable();
qcom_scm_clk_disable();
return ret ? : res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_pas_auth_and_reset);
/**
* qcom_scm_pas_shutdown() - Shut down the remote processor
* @peripheral: peripheral id
*
* Returns 0 on success.
*/
int qcom_scm_pas_shutdown(u32 peripheral)
{
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_PIL,
.cmd = QCOM_SCM_PIL_PAS_SHUTDOWN,
.arginfo = QCOM_SCM_ARGS(1),
.args[0] = peripheral,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
ret = qcom_scm_clk_enable();
if (ret)
return ret;
ret = qcom_scm_bw_enable();
if (ret)
return ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
qcom_scm_bw_disable();
qcom_scm_clk_disable();
return ret ? : res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_pas_shutdown);
/**
* qcom_scm_pas_supported() - Check if the peripheral authentication service is
* available for the given peripherial
* @peripheral: peripheral id
*
* Returns true if PAS is supported for this peripheral, otherwise false.
*/
bool qcom_scm_pas_supported(u32 peripheral)
{
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_PIL,
.cmd = QCOM_SCM_PIL_PAS_IS_SUPPORTED,
.arginfo = QCOM_SCM_ARGS(1),
.args[0] = peripheral,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
if (!__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_PIL,
QCOM_SCM_PIL_PAS_IS_SUPPORTED))
return false;
ret = qcom_scm_call(__scm->dev, &desc, &res);
return ret ? false : !!res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_pas_supported);
static int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_PIL,
.cmd = QCOM_SCM_PIL_PAS_MSS_RESET,
.arginfo = QCOM_SCM_ARGS(2),
.args[0] = reset,
.args[1] = 0,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
int ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
return ret ? : res.result[0];
}
static int qcom_scm_pas_reset_assert(struct reset_controller_dev *rcdev,
unsigned long idx)
{
if (idx != 0)
return -EINVAL;
return __qcom_scm_pas_mss_reset(__scm->dev, 1);
}
static int qcom_scm_pas_reset_deassert(struct reset_controller_dev *rcdev,
unsigned long idx)
{
if (idx != 0)
return -EINVAL;
return __qcom_scm_pas_mss_reset(__scm->dev, 0);
}
static const struct reset_control_ops qcom_scm_pas_reset_ops = {
.assert = qcom_scm_pas_reset_assert,
.deassert = qcom_scm_pas_reset_deassert,
};
int qcom_scm_io_readl(phys_addr_t addr, unsigned int *val)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_IO,
.cmd = QCOM_SCM_IO_READ,
.arginfo = QCOM_SCM_ARGS(1),
.args[0] = addr,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
int ret;
ret = qcom_scm_call_atomic(__scm->dev, &desc, &res);
if (ret >= 0)
*val = res.result[0];
return ret < 0 ? ret : 0;
}
EXPORT_SYMBOL_GPL(qcom_scm_io_readl);
int qcom_scm_io_writel(phys_addr_t addr, unsigned int val)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_IO,
.cmd = QCOM_SCM_IO_WRITE,
.arginfo = QCOM_SCM_ARGS(2),
.args[0] = addr,
.args[1] = val,
.owner = ARM_SMCCC_OWNER_SIP,
};
return qcom_scm_call_atomic(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_io_writel);
/**
* qcom_scm_restore_sec_cfg_available() - Check if secure environment
* supports restore security config interface.
*
* Return true if restore-cfg interface is supported, false if not.
*/
bool qcom_scm_restore_sec_cfg_available(void)
{
return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_MP,
QCOM_SCM_MP_RESTORE_SEC_CFG);
}
EXPORT_SYMBOL_GPL(qcom_scm_restore_sec_cfg_available);
int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_MP,
.cmd = QCOM_SCM_MP_RESTORE_SEC_CFG,
.arginfo = QCOM_SCM_ARGS(2),
.args[0] = device_id,
.args[1] = spare,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
int ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
return ret ? : res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_restore_sec_cfg);
int qcom_scm_iommu_secure_ptbl_size(u32 spare, size_t *size)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_MP,
.cmd = QCOM_SCM_MP_IOMMU_SECURE_PTBL_SIZE,
.arginfo = QCOM_SCM_ARGS(1),
.args[0] = spare,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
int ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
if (size)
*size = res.result[0];
return ret ? : res.result[1];
}
EXPORT_SYMBOL_GPL(qcom_scm_iommu_secure_ptbl_size);
int qcom_scm_iommu_secure_ptbl_init(u64 addr, u32 size, u32 spare)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_MP,
.cmd = QCOM_SCM_MP_IOMMU_SECURE_PTBL_INIT,
.arginfo = QCOM_SCM_ARGS(3, QCOM_SCM_RW, QCOM_SCM_VAL,
QCOM_SCM_VAL),
.args[0] = addr,
.args[1] = size,
.args[2] = spare,
.owner = ARM_SMCCC_OWNER_SIP,
};
int ret;
ret = qcom_scm_call(__scm->dev, &desc, NULL);
/* the pg table has been initialized already, ignore the error */
if (ret == -EPERM)
ret = 0;
return ret;
}
EXPORT_SYMBOL_GPL(qcom_scm_iommu_secure_ptbl_init);
int qcom_scm_iommu_set_cp_pool_size(u32 spare, u32 size)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_MP,
.cmd = QCOM_SCM_MP_IOMMU_SET_CP_POOL_SIZE,
.arginfo = QCOM_SCM_ARGS(2),
.args[0] = size,
.args[1] = spare,
.owner = ARM_SMCCC_OWNER_SIP,
};
return qcom_scm_call(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_iommu_set_cp_pool_size);
int qcom_scm_mem_protect_video_var(u32 cp_start, u32 cp_size,
u32 cp_nonpixel_start,
u32 cp_nonpixel_size)
{
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_MP,
.cmd = QCOM_SCM_MP_VIDEO_VAR,
.arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_VAL, QCOM_SCM_VAL,
QCOM_SCM_VAL, QCOM_SCM_VAL),
.args[0] = cp_start,
.args[1] = cp_size,
.args[2] = cp_nonpixel_start,
.args[3] = cp_nonpixel_size,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
ret = qcom_scm_call(__scm->dev, &desc, &res);
return ret ? : res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_mem_protect_video_var);
static int __qcom_scm_assign_mem(struct device *dev, phys_addr_t mem_region,
size_t mem_sz, phys_addr_t src, size_t src_sz,
phys_addr_t dest, size_t dest_sz)
{
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_MP,
.cmd = QCOM_SCM_MP_ASSIGN,
.arginfo = QCOM_SCM_ARGS(7, QCOM_SCM_RO, QCOM_SCM_VAL,
QCOM_SCM_RO, QCOM_SCM_VAL, QCOM_SCM_RO,
QCOM_SCM_VAL, QCOM_SCM_VAL),
.args[0] = mem_region,
.args[1] = mem_sz,
.args[2] = src,
.args[3] = src_sz,
.args[4] = dest,
.args[5] = dest_sz,
.args[6] = 0,
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
ret = qcom_scm_call(dev, &desc, &res);
return ret ? : res.result[0];
}
/**
* qcom_scm_assign_mem() - Make a secure call to reassign memory ownership
* @mem_addr: mem region whose ownership need to be reassigned
* @mem_sz: size of the region.
* @srcvm: vmid for current set of owners, each set bit in
* flag indicate a unique owner
* @newvm: array having new owners and corresponding permission
* flags
* @dest_cnt: number of owners in next set.
*
* Return negative errno on failure or 0 on success with @srcvm updated.
*/
int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz,
u64 *srcvm,
const struct qcom_scm_vmperm *newvm,
unsigned int dest_cnt)
{
struct qcom_scm_current_perm_info *destvm;
struct qcom_scm_mem_map_info *mem_to_map;
phys_addr_t mem_to_map_phys;
phys_addr_t dest_phys;
phys_addr_t ptr_phys;
size_t mem_to_map_sz;
size_t dest_sz;
size_t src_sz;
size_t ptr_sz;
int next_vm;
__le32 *src;
int ret, i, b;
u64 srcvm_bits = *srcvm;
src_sz = hweight64(srcvm_bits) * sizeof(*src);
mem_to_map_sz = sizeof(*mem_to_map);
dest_sz = dest_cnt * sizeof(*destvm);
ptr_sz = ALIGN(src_sz, SZ_64) + ALIGN(mem_to_map_sz, SZ_64) +
ALIGN(dest_sz, SZ_64);
void *ptr __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
ptr_sz, GFP_KERNEL);
if (!ptr)
return -ENOMEM;
ptr_phys = qcom_tzmem_to_phys(ptr);
/* Fill source vmid detail */
src = ptr;
i = 0;
for (b = 0; b < BITS_PER_TYPE(u64); b++) {
if (srcvm_bits & BIT(b))
src[i++] = cpu_to_le32(b);
}
/* Fill details of mem buff to map */
mem_to_map = ptr + ALIGN(src_sz, SZ_64);
mem_to_map_phys = ptr_phys + ALIGN(src_sz, SZ_64);
mem_to_map->mem_addr = cpu_to_le64(mem_addr);
mem_to_map->mem_size = cpu_to_le64(mem_sz);
next_vm = 0;
/* Fill details of next vmid detail */
destvm = ptr + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(src_sz, SZ_64);
dest_phys = ptr_phys + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(src_sz, SZ_64);
for (i = 0; i < dest_cnt; i++, destvm++, newvm++) {
destvm->vmid = cpu_to_le32(newvm->vmid);
destvm->perm = cpu_to_le32(newvm->perm);
destvm->ctx = 0;
destvm->ctx_size = 0;
next_vm |= BIT(newvm->vmid);
}
ret = __qcom_scm_assign_mem(__scm->dev, mem_to_map_phys, mem_to_map_sz,
ptr_phys, src_sz, dest_phys, dest_sz);
if (ret) {
dev_err(__scm->dev,
"Assign memory protection call failed %d\n", ret);
return -EINVAL;
}
*srcvm = next_vm;
return 0;
}
EXPORT_SYMBOL_GPL(qcom_scm_assign_mem);
/**
* qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
*/
bool qcom_scm_ocmem_lock_available(void)
{
return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_OCMEM,
QCOM_SCM_OCMEM_LOCK_CMD);
}
EXPORT_SYMBOL_GPL(qcom_scm_ocmem_lock_available);
/**
* qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
* region to the specified initiator
*
* @id: tz initiator id
* @offset: OCMEM offset
* @size: OCMEM size
* @mode: access mode (WIDE/NARROW)
*/
int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32 offset, u32 size,
u32 mode)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_OCMEM,
.cmd = QCOM_SCM_OCMEM_LOCK_CMD,
.args[0] = id,
.args[1] = offset,
.args[2] = size,
.args[3] = mode,
.arginfo = QCOM_SCM_ARGS(4),
};
return qcom_scm_call(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_ocmem_lock);
/**
* qcom_scm_ocmem_unlock() - call OCMEM unlock interface to release an OCMEM
* region from the specified initiator
*
* @id: tz initiator id
* @offset: OCMEM offset
* @size: OCMEM size
*/
int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32 offset, u32 size)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_OCMEM,
.cmd = QCOM_SCM_OCMEM_UNLOCK_CMD,
.args[0] = id,
.args[1] = offset,
.args[2] = size,
.arginfo = QCOM_SCM_ARGS(3),
};
return qcom_scm_call(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_ocmem_unlock);
/**
* qcom_scm_ice_available() - Is the ICE key programming interface available?
*
* Return: true iff the SCM calls wrapped by qcom_scm_ice_invalidate_key() and
* qcom_scm_ice_set_key() are available.
*/
bool qcom_scm_ice_available(void)
{
return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_ES,
QCOM_SCM_ES_INVALIDATE_ICE_KEY) &&
__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_ES,
QCOM_SCM_ES_CONFIG_SET_ICE_KEY);
}
EXPORT_SYMBOL_GPL(qcom_scm_ice_available);
/**
* qcom_scm_ice_invalidate_key() - Invalidate an inline encryption key
* @index: the keyslot to invalidate
*
* The UFSHCI and eMMC standards define a standard way to do this, but it
* doesn't work on these SoCs; only this SCM call does.
*
* It is assumed that the SoC has only one ICE instance being used, as this SCM
* call doesn't specify which ICE instance the keyslot belongs to.
*
* Return: 0 on success; -errno on failure.
*/
int qcom_scm_ice_invalidate_key(u32 index)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_ES,
.cmd = QCOM_SCM_ES_INVALIDATE_ICE_KEY,
.arginfo = QCOM_SCM_ARGS(1),
.args[0] = index,
.owner = ARM_SMCCC_OWNER_SIP,
};
return qcom_scm_call(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_ice_invalidate_key);
/**
* qcom_scm_ice_set_key() - Set an inline encryption key
* @index: the keyslot into which to set the key
* @key: the key to program
* @key_size: the size of the key in bytes
* @cipher: the encryption algorithm the key is for
* @data_unit_size: the encryption data unit size, i.e. the size of each
* individual plaintext and ciphertext. Given in 512-byte
* units, e.g. 1 = 512 bytes, 8 = 4096 bytes, etc.
*
* Program a key into a keyslot of Qualcomm ICE (Inline Crypto Engine), where it
* can then be used to encrypt/decrypt UFS or eMMC I/O requests inline.
*
* The UFSHCI and eMMC standards define a standard way to do this, but it
* doesn't work on these SoCs; only this SCM call does.
*
* It is assumed that the SoC has only one ICE instance being used, as this SCM
* call doesn't specify which ICE instance the keyslot belongs to.
*
* Return: 0 on success; -errno on failure.
*/
int qcom_scm_ice_set_key(u32 index, const u8 *key, u32 key_size,
enum qcom_scm_ice_cipher cipher, u32 data_unit_size)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_ES,
.cmd = QCOM_SCM_ES_CONFIG_SET_ICE_KEY,
.arginfo = QCOM_SCM_ARGS(5, QCOM_SCM_VAL, QCOM_SCM_RW,
QCOM_SCM_VAL, QCOM_SCM_VAL,
QCOM_SCM_VAL),
.args[0] = index,
.args[2] = key_size,
.args[3] = cipher,
.args[4] = data_unit_size,
.owner = ARM_SMCCC_OWNER_SIP,
};
int ret;
void *keybuf __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
key_size,
GFP_KERNEL);
if (!keybuf)
return -ENOMEM;
memcpy(keybuf, key, key_size);
desc.args[1] = qcom_tzmem_to_phys(keybuf);
ret = qcom_scm_call(__scm->dev, &desc, NULL);
memzero_explicit(keybuf, key_size);
return ret;
}
EXPORT_SYMBOL_GPL(qcom_scm_ice_set_key);
/**
* qcom_scm_hdcp_available() - Check if secure environment supports HDCP.
*
* Return true if HDCP is supported, false if not.
*/
bool qcom_scm_hdcp_available(void)
{
bool avail;
int ret = qcom_scm_clk_enable();
if (ret)
return ret;
avail = __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_HDCP,
QCOM_SCM_HDCP_INVOKE);
qcom_scm_clk_disable();
return avail;
}
EXPORT_SYMBOL_GPL(qcom_scm_hdcp_available);
/**
* qcom_scm_hdcp_req() - Send HDCP request.
* @req: HDCP request array
* @req_cnt: HDCP request array count
* @resp: response buffer passed to SCM
*
* Write HDCP register(s) through SCM.
*/
int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, u32 *resp)
{
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_HDCP,
.cmd = QCOM_SCM_HDCP_INVOKE,
.arginfo = QCOM_SCM_ARGS(10),
.args = {
req[0].addr,
req[0].val,
req[1].addr,
req[1].val,
req[2].addr,
req[2].val,
req[3].addr,
req[3].val,
req[4].addr,
req[4].val
},
.owner = ARM_SMCCC_OWNER_SIP,
};
struct qcom_scm_res res;
if (req_cnt > QCOM_SCM_HDCP_MAX_REQ_CNT)
return -ERANGE;
ret = qcom_scm_clk_enable();
if (ret)
return ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
*resp = res.result[0];
qcom_scm_clk_disable();
return ret;
}
EXPORT_SYMBOL_GPL(qcom_scm_hdcp_req);
int qcom_scm_iommu_set_pt_format(u32 sec_id, u32 ctx_num, u32 pt_fmt)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_SMMU_PROGRAM,
.cmd = QCOM_SCM_SMMU_PT_FORMAT,
.arginfo = QCOM_SCM_ARGS(3),
.args[0] = sec_id,
.args[1] = ctx_num,
.args[2] = pt_fmt, /* 0: LPAE AArch32 - 1: AArch64 */
.owner = ARM_SMCCC_OWNER_SIP,
};
return qcom_scm_call(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_iommu_set_pt_format);
int qcom_scm_qsmmu500_wait_safe_toggle(bool en)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_SMMU_PROGRAM,
.cmd = QCOM_SCM_SMMU_CONFIG_ERRATA1,
.arginfo = QCOM_SCM_ARGS(2),
.args[0] = QCOM_SCM_SMMU_CONFIG_ERRATA1_CLIENT_ALL,
.args[1] = en,
.owner = ARM_SMCCC_OWNER_SIP,
};
return qcom_scm_call_atomic(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_qsmmu500_wait_safe_toggle);
bool qcom_scm_lmh_dcvsh_available(void)
{
return __qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_LMH, QCOM_SCM_LMH_LIMIT_DCVSH);
}
EXPORT_SYMBOL_GPL(qcom_scm_lmh_dcvsh_available);
int qcom_scm_shm_bridge_enable(void)
{
firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling JIRA: https://issues.redhat.com/browse/RHEL-73299 commit f489f6c6eb26482010470d77bad3901a3de1b166 Author: Qingqing Zhou <quic_qqzhou@quicinc.com> Date: Wed Oct 23 00:51:48 2024 +0530 firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling When enabling SHM bridge, QTEE returns 0 and sets error 4 in result to qcom_scm for unsupported platforms. Currently, tzmem interprets this as an unknown error rather than recognizing it as an unsupported platform. Error log: [ 0.177224] qcom_scm firmware:scm: error (____ptrval____): Failed to enable the TrustZone memory allocator [ 0.177244] qcom_scm firmware:scm: probe with driver qcom_scm failed with error 4 To address this, modify the function call qcom_scm_shm_bridge_enable() to remap result to indicate an unsupported error. This way, tzmem will correctly identify it as an unsupported platform case instead of reporting it as an error. Fixes: 178e19c0df1b ("firmware: qcom: scm: add support for SHM bridge operations") Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com> Co-developed-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Signed-off-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20241022192148.1626633-1-quic_kuldsing@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:59:29 +00:00
int ret;
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_MP,
.cmd = QCOM_SCM_MP_SHM_BRIDGE_ENABLE,
.owner = ARM_SMCCC_OWNER_SIP
};
struct qcom_scm_res res;
if (!__qcom_scm_is_call_available(__scm->dev, QCOM_SCM_SVC_MP,
QCOM_SCM_MP_SHM_BRIDGE_ENABLE))
return -EOPNOTSUPP;
firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling JIRA: https://issues.redhat.com/browse/RHEL-73299 commit f489f6c6eb26482010470d77bad3901a3de1b166 Author: Qingqing Zhou <quic_qqzhou@quicinc.com> Date: Wed Oct 23 00:51:48 2024 +0530 firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling When enabling SHM bridge, QTEE returns 0 and sets error 4 in result to qcom_scm for unsupported platforms. Currently, tzmem interprets this as an unknown error rather than recognizing it as an unsupported platform. Error log: [ 0.177224] qcom_scm firmware:scm: error (____ptrval____): Failed to enable the TrustZone memory allocator [ 0.177244] qcom_scm firmware:scm: probe with driver qcom_scm failed with error 4 To address this, modify the function call qcom_scm_shm_bridge_enable() to remap result to indicate an unsupported error. This way, tzmem will correctly identify it as an unsupported platform case instead of reporting it as an error. Fixes: 178e19c0df1b ("firmware: qcom: scm: add support for SHM bridge operations") Signed-off-by: Qingqing Zhou <quic_qqzhou@quicinc.com> Co-developed-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Signed-off-by: Kuldeep Singh <quic_kuldsing@quicinc.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20241022192148.1626633-1-quic_kuldsing@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:59:29 +00:00
ret = qcom_scm_call(__scm->dev, &desc, &res);
if (ret)
return ret;
if (res.result[0] == SHMBRIDGE_RESULT_NOTSUPP)
return -EOPNOTSUPP;
return res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_shm_bridge_enable);
int qcom_scm_shm_bridge_create(struct device *dev, u64 pfn_and_ns_perm_flags,
u64 ipfn_and_s_perm_flags, u64 size_and_flags,
u64 ns_vmids, u64 *handle)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_MP,
.cmd = QCOM_SCM_MP_SHM_BRIDGE_CREATE,
.owner = ARM_SMCCC_OWNER_SIP,
.args[0] = pfn_and_ns_perm_flags,
.args[1] = ipfn_and_s_perm_flags,
.args[2] = size_and_flags,
.args[3] = ns_vmids,
.arginfo = QCOM_SCM_ARGS(4, QCOM_SCM_VAL, QCOM_SCM_VAL,
QCOM_SCM_VAL, QCOM_SCM_VAL),
};
struct qcom_scm_res res;
int ret;
ret = qcom_scm_call(__scm->dev, &desc, &res);
if (handle && !ret)
*handle = res.result[1];
return ret ?: res.result[0];
}
EXPORT_SYMBOL_GPL(qcom_scm_shm_bridge_create);
int qcom_scm_shm_bridge_delete(struct device *dev, u64 handle)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_MP,
.cmd = QCOM_SCM_MP_SHM_BRIDGE_DELETE,
.owner = ARM_SMCCC_OWNER_SIP,
.args[0] = handle,
.arginfo = QCOM_SCM_ARGS(1, QCOM_SCM_VAL),
};
return qcom_scm_call(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_shm_bridge_delete);
int qcom_scm_lmh_profile_change(u32 profile_id)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_LMH,
.cmd = QCOM_SCM_LMH_LIMIT_PROFILE_CHANGE,
.arginfo = QCOM_SCM_ARGS(1, QCOM_SCM_VAL),
.args[0] = profile_id,
.owner = ARM_SMCCC_OWNER_SIP,
};
return qcom_scm_call(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_lmh_profile_change);
int qcom_scm_lmh_dcvsh(u32 payload_fn, u32 payload_reg, u32 payload_val,
u64 limit_node, u32 node_id, u64 version)
{
int ret, payload_size = 5 * sizeof(u32);
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_LMH,
.cmd = QCOM_SCM_LMH_LIMIT_DCVSH,
.arginfo = QCOM_SCM_ARGS(5, QCOM_SCM_RO, QCOM_SCM_VAL, QCOM_SCM_VAL,
QCOM_SCM_VAL, QCOM_SCM_VAL),
.args[1] = payload_size,
.args[2] = limit_node,
.args[3] = node_id,
.args[4] = version,
.owner = ARM_SMCCC_OWNER_SIP,
};
u32 *payload_buf __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
payload_size,
GFP_KERNEL);
if (!payload_buf)
return -ENOMEM;
payload_buf[0] = payload_fn;
payload_buf[1] = 0;
payload_buf[2] = payload_reg;
payload_buf[3] = 1;
payload_buf[4] = payload_val;
desc.args[0] = qcom_tzmem_to_phys(payload_buf);
ret = qcom_scm_call(__scm->dev, &desc, NULL);
return ret;
}
EXPORT_SYMBOL_GPL(qcom_scm_lmh_dcvsh);
int qcom_scm_gpu_init_regs(u32 gpu_req)
{
struct qcom_scm_desc desc = {
.svc = QCOM_SCM_SVC_GPU,
.cmd = QCOM_SCM_SVC_GPU_INIT_REGS,
.arginfo = QCOM_SCM_ARGS(1),
.args[0] = gpu_req,
.owner = ARM_SMCCC_OWNER_SIP,
};
return qcom_scm_call(__scm->dev, &desc, NULL);
}
EXPORT_SYMBOL_GPL(qcom_scm_gpu_init_regs);
static int qcom_scm_find_dload_address(struct device *dev, u64 *addr)
{
struct device_node *tcsr;
struct device_node *np = dev->of_node;
struct resource res;
u32 offset;
int ret;
tcsr = of_parse_phandle(np, "qcom,dload-mode", 0);
if (!tcsr)
return 0;
ret = of_address_to_resource(tcsr, 0, &res);
of_node_put(tcsr);
if (ret)
return ret;
ret = of_property_read_u32_index(np, "qcom,dload-mode", 1, &offset);
if (ret < 0)
return ret;
*addr = res.start + offset;
return 0;
}
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
#ifdef CONFIG_QCOM_QSEECOM
/* Lock for QSEECOM SCM call executions */
static DEFINE_MUTEX(qcom_scm_qseecom_call_lock);
static int __qcom_scm_qseecom_call(const struct qcom_scm_desc *desc,
struct qcom_scm_qseecom_resp *res)
{
struct qcom_scm_res scm_res = {};
int status;
/*
* QSEECOM SCM calls should not be executed concurrently. Therefore, we
* require the respective call lock to be held.
*/
lockdep_assert_held(&qcom_scm_qseecom_call_lock);
status = qcom_scm_call(__scm->dev, desc, &scm_res);
res->result = scm_res.result[0];
res->resp_type = scm_res.result[1];
res->data = scm_res.result[2];
if (status)
return status;
return 0;
}
/**
* qcom_scm_qseecom_call() - Perform a QSEECOM SCM call.
* @desc: SCM call descriptor.
* @res: SCM call response (output).
*
* Performs the QSEECOM SCM call described by @desc, returning the response in
* @rsp.
*
* Return: Zero on success, nonzero on failure.
*/
static int qcom_scm_qseecom_call(const struct qcom_scm_desc *desc,
struct qcom_scm_qseecom_resp *res)
{
int status;
/*
* Note: Multiple QSEECOM SCM calls should not be executed same time,
* so lock things here. This needs to be extended to callback/listener
* handling when support for that is implemented.
*/
mutex_lock(&qcom_scm_qseecom_call_lock);
status = __qcom_scm_qseecom_call(desc, res);
mutex_unlock(&qcom_scm_qseecom_call_lock);
dev_dbg(__scm->dev, "%s: owner=%x, svc=%x, cmd=%x, result=%lld, type=%llx, data=%llx\n",
__func__, desc->owner, desc->svc, desc->cmd, res->result,
res->resp_type, res->data);
if (status) {
dev_err(__scm->dev, "qseecom: scm call failed with error %d\n", status);
return status;
}
/*
* TODO: Handle incomplete and blocked calls:
*
* Incomplete and blocked calls are not supported yet. Some devices
* and/or commands require those, some don't. Let's warn about them
* prominently in case someone attempts to try these commands with a
* device/command combination that isn't supported yet.
*/
WARN_ON(res->result == QSEECOM_RESULT_INCOMPLETE);
WARN_ON(res->result == QSEECOM_RESULT_BLOCKED_ON_LISTENER);
return 0;
}
/**
* qcom_scm_qseecom_get_version() - Query the QSEECOM version.
* @version: Pointer where the QSEECOM version will be stored.
*
* Performs the QSEECOM SCM querying the QSEECOM version currently running in
* the TrustZone.
*
* Return: Zero on success, nonzero on failure.
*/
static int qcom_scm_qseecom_get_version(u32 *version)
{
struct qcom_scm_desc desc = {};
struct qcom_scm_qseecom_resp res = {};
u32 feature = 10;
int ret;
desc.owner = QSEECOM_TZ_OWNER_SIP;
desc.svc = QSEECOM_TZ_SVC_INFO;
desc.cmd = QSEECOM_TZ_CMD_INFO_VERSION;
desc.arginfo = QCOM_SCM_ARGS(1, QCOM_SCM_VAL);
desc.args[0] = feature;
ret = qcom_scm_qseecom_call(&desc, &res);
if (ret)
return ret;
*version = res.result;
return 0;
}
/**
* qcom_scm_qseecom_app_get_id() - Query the app ID for a given QSEE app name.
* @app_name: The name of the app.
* @app_id: The returned app ID.
*
* Query and return the application ID of the SEE app identified by the given
* name. This returned ID is the unique identifier of the app required for
* subsequent communication.
*
* Return: Zero on success, nonzero on failure, -ENOENT if the app has not been
* loaded or could not be found.
*/
int qcom_scm_qseecom_app_get_id(const char *app_name, u32 *app_id)
{
unsigned long name_buf_size = QSEECOM_MAX_APP_NAME_SIZE;
unsigned long app_name_len = strlen(app_name);
struct qcom_scm_desc desc = {};
struct qcom_scm_qseecom_resp res = {};
int status;
if (app_name_len >= name_buf_size)
return -EINVAL;
char *name_buf __free(qcom_tzmem) = qcom_tzmem_alloc(__scm->mempool,
name_buf_size,
GFP_KERNEL);
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
if (!name_buf)
return -ENOMEM;
memcpy(name_buf, app_name, app_name_len);
desc.owner = QSEECOM_TZ_OWNER_QSEE_OS;
desc.svc = QSEECOM_TZ_SVC_APP_MGR;
desc.cmd = QSEECOM_TZ_CMD_APP_LOOKUP;
desc.arginfo = QCOM_SCM_ARGS(2, QCOM_SCM_RW, QCOM_SCM_VAL);
desc.args[0] = qcom_tzmem_to_phys(name_buf);
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
desc.args[1] = app_name_len;
status = qcom_scm_qseecom_call(&desc, &res);
if (status)
return status;
if (res.result == QSEECOM_RESULT_FAILURE)
return -ENOENT;
if (res.result != QSEECOM_RESULT_SUCCESS)
return -EINVAL;
if (res.resp_type != QSEECOM_SCM_RES_APP_ID)
return -EINVAL;
*app_id = res.data;
return 0;
}
EXPORT_SYMBOL_GPL(qcom_scm_qseecom_app_get_id);
/**
* qcom_scm_qseecom_app_send() - Send to and receive data from a given QSEE app.
* @app_id: The ID of the target app.
* @req: Request buffer sent to the app (must be TZ memory)
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
* @req_size: Size of the request buffer.
* @rsp: Response buffer, written to by the app (must be TZ memory)
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
* @rsp_size: Size of the response buffer.
*
* Sends a request to the QSEE app associated with the given ID and read back
* its response. The caller must provide two DMA memory regions, one for the
* request and one for the response, and fill out the @req region with the
* respective (app-specific) request data. The QSEE app reads this and returns
* its response in the @rsp region.
*
* Return: Zero on success, nonzero on failure.
*/
int qcom_scm_qseecom_app_send(u32 app_id, void *req, size_t req_size,
void *rsp, size_t rsp_size)
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
{
struct qcom_scm_qseecom_resp res = {};
struct qcom_scm_desc desc = {};
phys_addr_t req_phys;
phys_addr_t rsp_phys;
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
int status;
req_phys = qcom_tzmem_to_phys(req);
rsp_phys = qcom_tzmem_to_phys(rsp);
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
desc.owner = QSEECOM_TZ_OWNER_TZ_APPS;
desc.svc = QSEECOM_TZ_SVC_APP_ID_PLACEHOLDER;
desc.cmd = QSEECOM_TZ_CMD_APP_SEND;
desc.arginfo = QCOM_SCM_ARGS(5, QCOM_SCM_VAL,
QCOM_SCM_RW, QCOM_SCM_VAL,
QCOM_SCM_RW, QCOM_SCM_VAL);
desc.args[0] = app_id;
desc.args[1] = req_phys;
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
desc.args[2] = req_size;
desc.args[3] = rsp_phys;
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
desc.args[4] = rsp_size;
status = qcom_scm_qseecom_call(&desc, &res);
if (status)
return status;
if (res.result != QSEECOM_RESULT_SUCCESS)
return -EIO;
return 0;
}
EXPORT_SYMBOL_GPL(qcom_scm_qseecom_app_send);
/*
* We do not yet support re-entrant calls via the qseecom interface. To prevent
+ any potential issues with this, only allow validated machines for now.
*/
static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
{ .compatible = "lenovo,thinkpad-x13s", },
{ }
};
static bool qcom_scm_qseecom_machine_is_allowed(void)
{
struct device_node *np;
bool match;
np = of_find_node_by_path("/");
if (!np)
return false;
match = of_match_node(qcom_scm_qseecom_allowlist, np);
of_node_put(np);
return match;
}
static void qcom_scm_qseecom_free(void *data)
{
struct platform_device *qseecom_dev = data;
platform_device_del(qseecom_dev);
platform_device_put(qseecom_dev);
}
static int qcom_scm_qseecom_init(struct qcom_scm *scm)
{
struct platform_device *qseecom_dev;
u32 version;
int ret;
/*
* Note: We do two steps of validation here: First, we try to query the
* QSEECOM version as a check to see if the interface exists on this
* device. Second, we check against known good devices due to current
* driver limitations (see comment in qcom_scm_qseecom_allowlist).
*
* Note that we deliberately do the machine check after the version
* check so that we can log potentially supported devices. This should
* be safe as downstream sources indicate that the version query is
* neither blocking nor reentrant.
*/
ret = qcom_scm_qseecom_get_version(&version);
if (ret)
return 0;
dev_info(scm->dev, "qseecom: found qseecom with version 0x%x\n", version);
if (!qcom_scm_qseecom_machine_is_allowed()) {
dev_info(scm->dev, "qseecom: untested machine, skipping\n");
return 0;
}
/*
* Set up QSEECOM interface device. All application clients will be
* set up and managed by the corresponding driver for it.
*/
qseecom_dev = platform_device_alloc("qcom_qseecom", -1);
if (!qseecom_dev)
return -ENOMEM;
qseecom_dev->dev.parent = scm->dev;
ret = platform_device_add(qseecom_dev);
if (ret) {
platform_device_put(qseecom_dev);
return ret;
}
return devm_add_action_or_reset(scm->dev, qcom_scm_qseecom_free, qseecom_dev);
}
#else /* CONFIG_QCOM_QSEECOM */
static int qcom_scm_qseecom_init(struct qcom_scm *scm)
{
return 0;
}
#endif /* CONFIG_QCOM_QSEECOM */
/**
* qcom_scm_is_available() - Checks if SCM is available
*/
bool qcom_scm_is_available(void)
{
firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available() JIRA: https://issues.redhat.com/browse/RHEL-73299 commit 0a744cceebd0480cb39587b3b1339d66a9d14063 Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Date: Mon Dec 9 15:27:54 2024 +0100 firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available() Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq completion variable initialization") introduced a write barrier in probe function to store global '__scm' variable. It also claimed that it added a read barrier, because as we all known barriers are paired (see memory-barriers.txt: "Note that write barriers should normally be paired with read or address-dependency barriers"), however it did not really add it. The offending commit used READ_ONCE() to access '__scm' global which is not a barrier. The barrier is needed so the store to '__scm' will be properly visible. This is most likely not fatal in current driver design, because missing read barrier would mean qcom_scm_is_available() callers will access old value, NULL. Driver does not support unbinding and does not correctly handle probe failures, thus there is no risk of stale or old pointer in '__scm' variable. However for code correctness, readability and to be sure that we did not mess up something in this tricky topic of SMP barriers, add a read barrier for accessing '__scm'. Change also comment from useless/obvious what does barrier do, to what is expected: which other parts of the code are involved here. Fixes: 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq completion variable initialization") Cc: stable@vger.kernel.org Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-1-9061013c8d92@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:59:31 +00:00
/* Paired with smp_store_release() in qcom_scm_probe */
return !!smp_load_acquire(&__scm);
}
EXPORT_SYMBOL_GPL(qcom_scm_is_available);
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
static int qcom_scm_assert_valid_wq_ctx(u32 wq_ctx)
{
/* FW currently only supports a single wq_ctx (zero).
* TODO: Update this logic to include dynamic allocation and lookup of
* completion structs when FW supports more wq_ctx values.
*/
if (wq_ctx != 0) {
dev_err(__scm->dev, "Firmware unexpectedly passed non-zero wq_ctx\n");
return -EINVAL;
}
return 0;
}
int qcom_scm_wait_for_wq_completion(u32 wq_ctx)
{
int ret;
ret = qcom_scm_assert_valid_wq_ctx(wq_ctx);
if (ret)
return ret;
wait_for_completion(&__scm->waitq_comp);
return 0;
}
static int qcom_scm_waitq_wakeup(unsigned int wq_ctx)
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
{
int ret;
ret = qcom_scm_assert_valid_wq_ctx(wq_ctx);
if (ret)
return ret;
complete(&__scm->waitq_comp);
return 0;
}
static irqreturn_t qcom_scm_irq_handler(int irq, void *data)
{
int ret;
struct qcom_scm *scm = data;
u32 wq_ctx, flags, more_pending = 0;
do {
ret = scm_get_wq_ctx(&wq_ctx, &flags, &more_pending);
if (ret) {
dev_err(scm->dev, "GET_WQ_CTX SMC call failed: %d\n", ret);
goto out;
}
if (flags != QCOM_SMC_WAITQ_FLAG_WAKE_ONE &&
flags != QCOM_SMC_WAITQ_FLAG_WAKE_ALL) {
dev_err(scm->dev, "Invalid flags found for wq_ctx: %u\n", flags);
goto out;
}
ret = qcom_scm_waitq_wakeup(wq_ctx);
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
if (ret)
goto out;
} while (more_pending);
out:
return IRQ_HANDLED;
}
static int get_download_mode(char *buffer, const struct kernel_param *kp)
{
if (download_mode >= ARRAY_SIZE(download_mode_name))
return sysfs_emit(buffer, "unknown mode\n");
return sysfs_emit(buffer, "%s\n", download_mode_name[download_mode]);
}
static int set_download_mode(const char *val, const struct kernel_param *kp)
{
bool tmp;
int ret;
ret = sysfs_match_string(download_mode_name, val);
if (ret < 0) {
ret = kstrtobool(val, &tmp);
if (ret < 0) {
pr_err("qcom_scm: err: %d\n", ret);
return ret;
}
ret = tmp ? 1 : 0;
}
download_mode = ret;
if (__scm)
qcom_scm_set_download_mode(download_mode);
return 0;
}
static const struct kernel_param_ops download_mode_param_ops = {
.get = get_download_mode,
.set = set_download_mode,
};
module_param_cb(download_mode, &download_mode_param_ops, NULL, 0644);
MODULE_PARM_DESC(download_mode, "download mode: off/0/N for no dump mode, full/on/1/Y for full dump mode, mini for minidump mode and full,mini for both full and minidump mode together are acceptable values");
static int qcom_scm_probe(struct platform_device *pdev)
{
struct qcom_tzmem_pool_config pool_config;
struct qcom_scm *scm;
unsigned long clks;
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
int irq, ret;
scm = devm_kzalloc(&pdev->dev, sizeof(*scm), GFP_KERNEL);
if (!scm)
return -ENOMEM;
scm->dev = &pdev->dev;
ret = qcom_scm_find_dload_address(&pdev->dev, &scm->dload_mode_addr);
if (ret < 0)
return ret;
init_completion(&scm->waitq_comp);
mutex_init(&scm->scm_bw_lock);
clks = (unsigned long)of_device_get_match_data(&pdev->dev);
scm->path = devm_of_icc_get(&pdev->dev, NULL);
if (IS_ERR(scm->path))
return dev_err_probe(&pdev->dev, PTR_ERR(scm->path),
"failed to acquire interconnect path\n");
scm->core_clk = devm_clk_get(&pdev->dev, "core");
if (IS_ERR(scm->core_clk)) {
if (PTR_ERR(scm->core_clk) == -EPROBE_DEFER)
return PTR_ERR(scm->core_clk);
if (clks & SCM_HAS_CORE_CLK) {
dev_err(&pdev->dev, "failed to acquire core clk\n");
return PTR_ERR(scm->core_clk);
}
scm->core_clk = NULL;
}
scm->iface_clk = devm_clk_get(&pdev->dev, "iface");
if (IS_ERR(scm->iface_clk)) {
if (PTR_ERR(scm->iface_clk) == -EPROBE_DEFER)
return PTR_ERR(scm->iface_clk);
if (clks & SCM_HAS_IFACE_CLK) {
dev_err(&pdev->dev, "failed to acquire iface clk\n");
return PTR_ERR(scm->iface_clk);
}
scm->iface_clk = NULL;
}
scm->bus_clk = devm_clk_get(&pdev->dev, "bus");
if (IS_ERR(scm->bus_clk)) {
if (PTR_ERR(scm->bus_clk) == -EPROBE_DEFER)
return PTR_ERR(scm->bus_clk);
if (clks & SCM_HAS_BUS_CLK) {
dev_err(&pdev->dev, "failed to acquire bus clk\n");
return PTR_ERR(scm->bus_clk);
}
scm->bus_clk = NULL;
}
scm->reset.ops = &qcom_scm_pas_reset_ops;
scm->reset.nr_resets = 1;
scm->reset.of_node = pdev->dev.of_node;
ret = devm_reset_controller_register(&pdev->dev, &scm->reset);
if (ret)
return ret;
/* vote for max clk rate for highest performance */
ret = clk_set_rate(scm->core_clk, INT_MAX);
if (ret)
return ret;
firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available() JIRA: https://issues.redhat.com/browse/RHEL-73299 commit 0a744cceebd0480cb39587b3b1339d66a9d14063 Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Date: Mon Dec 9 15:27:54 2024 +0100 firmware: qcom: scm: Fix missing read barrier in qcom_scm_is_available() Commit 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq completion variable initialization") introduced a write barrier in probe function to store global '__scm' variable. It also claimed that it added a read barrier, because as we all known barriers are paired (see memory-barriers.txt: "Note that write barriers should normally be paired with read or address-dependency barriers"), however it did not really add it. The offending commit used READ_ONCE() to access '__scm' global which is not a barrier. The barrier is needed so the store to '__scm' will be properly visible. This is most likely not fatal in current driver design, because missing read barrier would mean qcom_scm_is_available() callers will access old value, NULL. Driver does not support unbinding and does not correctly handle probe failures, thus there is no risk of stale or old pointer in '__scm' variable. However for code correctness, readability and to be sure that we did not mess up something in this tricky topic of SMP barriers, add a read barrier for accessing '__scm'. Change also comment from useless/obvious what does barrier do, to what is expected: which other parts of the code are involved here. Fixes: 2e4955167ec5 ("firmware: qcom: scm: Fix __scm and waitq completion variable initialization") Cc: stable@vger.kernel.org Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20241209-qcom-scm-missing-barriers-and-all-sort-of-srap-v2-1-9061013c8d92@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:59:31 +00:00
/* Paired with smp_load_acquire() in qcom_scm_is_available(). */
smp_store_release(&__scm, scm);
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
irq = platform_get_irq_optional(pdev, 0);
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
if (irq < 0) {
if (irq != -ENXIO) {
ret = irq;
goto err;
}
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
} else {
ret = devm_request_threaded_irq(__scm->dev, irq, NULL, qcom_scm_irq_handler,
IRQF_ONESHOT, "qcom-scm", __scm);
if (ret < 0) {
dev_err_probe(scm->dev, ret, "Failed to request qcom-scm irq\n");
goto err;
}
firmware: qcom: scm: Add wait-queue handling logic Bugzilla: https://bugzilla.redhat.com/2213601 commit 6bf32599223634294cdc6efb359ffaab1d68073c Author: Guru Das Srinagesh <quic_gurus@quicinc.com> Date: Fri Jan 13 21:41:14 2023 +0530 firmware: qcom: scm: Add wait-queue handling logic When the firmware (FW) supports multiple requests per VM, multiple requests from the same/different VM can reach the firmware at the same time. Since the firmware currently being used has limited resources, it guards them with a resource lock and puts requests on a wait-queue internally and signals to HLOS that it is doing so. It does this by returning a new return value in addition to success or error: SCM_WAITQ_SLEEP. A sleeping SCM call can be woken up by an interrupt that the FW raises. 1) SCM_WAITQ_SLEEP: When an SCM call receives this return value instead of success or error, FW has placed this call on a wait-queue and has signalled HLOS to put it to non-interruptible sleep. Along with this return value, FW also passes to HLOS `wq_ctx` - a unique number (UID) identifying the wait-queue that it has put the call on, internally. This is to help HLOS with its own bookkeeping to wake this sleeping call later. Additionally, FW also passes to HLOS `smc_call_ctx` - a UID identifying the SCM call thus being put to sleep. This is also for HLOS' bookkeeping to wake this call up later. These two additional values are passed via the a1 and a2 registers. N.B.: The "ctx" in the above UID names = "context". The handshake mechanism that HLOS uses to talk to FW about wait-queue operations involves two new SMC calls. 1) get_wq_ctx(): Arguments: None Returns: wq_ctx, flags, more_pending Get the wait-queue context, and wake up either one or all of the sleeping SCM calls associated with that wait-queue. Additionally, repeat this if there are more wait-queues that are ready to have their requests woken up (`more_pending`). 2) wq_resume(smc_call_ctx): Arguments: smc_call_ctx HLOS needs to issue this in response to receiving an IRQ, passing to FW the same smc_call_ctx that FW receives from HLOS via the get_wq_ctx() call. (The mechanism to wake a SMC call back up is described in detail below) VM_1 VM_2 Firmware │ │ │ │ │ │ │ │ │ │ │ │ │ REQUEST_1 │ │ ├────────────────────────┼─────────────────────────────────┤ │ │ │ │ │ ┌──┼──┐ │ │ │ │ │ │ │ REQUEST_2 │ │ │ │ ├──────────────────────────────┼──┤ │ │ │ │ │ │Resource │ │ │ │ │is busy │ │ {WQ_SLEEP} │ │ │ │ │◄─────────────────────────────┼──┤ │ │ │ wq_ctx, smc_call_ctx │ │ │ │ │ └──┼──┘ │ REQUEST_1 COMPLETE │ │ │◄───────────────────────┼─────────────────────────────────┤ │ │ │ │ │ IRQ │ │ │◄─-------------------------------│ │ │ │ │ │ get_wq_ctx() │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │◄────────────────────────────────┤ │ │ wq_ctx, flags, and │ │ │ more_pending │ │ │ │ │ │ │ │ │ wq_resume(smc_call_ctx) │ │ ├────────────────────────────────►│ │ │ │ │ │ │ │ │ REQUEST_2 COMPLETE │ │ │◄────────────────────────────────┤ │ │ │ │ │ │ With the exception of get_wq_ctx(), the other SMC call wq_resume() can return WQ_SLEEP (these nested rounds of WQ_SLEEP are not shown in the above diagram for the sake of simplicity). Therefore, introduce a new do-while loop to handle multiple WQ_SLEEP return values for the same parent SCM call. Request Completion in the above diagram refers to either a success return value (zero) or error (and not SMC_WAITQ_SLEEP) Also add the interrupt handler that wakes up a sleeping SCM call. Signed-off-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Co-developed-by: Sibi Sankar <quic_sibis@quicinc.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230113161114.22607-3-quic_sibis@quicinc.com Signed-off-by: Lucas Karpinski <lkarpins@redhat.com>
2023-06-08 18:56:17 +00:00
}
firmware: qcom_scm: Reduce locking section for __get_convention() 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 <eberman@codeaurora.org> Cc: Brian Masney <masneyb@onstation.org> Cc: Stephan Gerhold <stephan@gerhold.net> Cc: Jeffrey Hugo <jhugo@codeaurora.org> Cc: Douglas Anderson <dianders@chromium.org> Fixes: 9a434cee773a ("firmware: qcom_scm: Dynamically support SMCCC and legacy conventions") Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20210223214539.1336155-3-swboyd@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2021-02-23 21:45:35 +00:00
__get_convention();
/*
* If "download mode" is requested, from this point on warmboot
* will cause the boot stages to enter download mode, unless
* disabled below by a clean shutdown/reboot.
*/
firmware: qcom: scm: Disable SDI and write no dump to dump mode JIRA: https://issues.redhat.com/browse/RHEL-73299 commit 79cb2cb8d89b7eca87e8dac031dadea4aeafeaa7 Author: Mukesh Ojha <quic_mojha@quicinc.com> Date: Mon Jul 8 21:23:32 2024 +0530 firmware: qcom: scm: Disable SDI and write no dump to dump mode SDI is enabled for most of the Qualcomm SoCs and as per commit ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required") it was recommended to disable SDI by mentioning it in device tree to avoid hang during watchdog or during reboot. However, for some cases if download mode tcsr register already configured from boot firmware to collect dumps and if SDI is disabled via means of mentioning it in device tree we could still end up with dump collection. Disabling SDI alone is not completely enough to disable dump mode and we also need to zero out the bits download bits from tcsr register. Current commit now, unconditionally call qcom_scm_set_download_mode() based on download_mode flag, at max if TCSR register is not mentioned or available for a SoC it will fallback to legacy way of setting download mode through command which may be no-ops or return error in case current firmware does not implements QCOM_SCM_INFO_IS_CALL_AVAIL so, at worst it does nothing if it fails. It also does to call SDI disable call if dload mode is disabled, which looks fine to do as intention is to disable dump collection even if system crashes. Fixes: ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required") Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20240708155332.4056479-1-quic_mojha@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:59:13 +00:00
qcom_scm_set_download_mode(download_mode);
/*
* Disable SDI if indicated by DT that it is enabled by default.
*/
firmware: qcom: scm: Disable SDI and write no dump to dump mode JIRA: https://issues.redhat.com/browse/RHEL-73299 commit 79cb2cb8d89b7eca87e8dac031dadea4aeafeaa7 Author: Mukesh Ojha <quic_mojha@quicinc.com> Date: Mon Jul 8 21:23:32 2024 +0530 firmware: qcom: scm: Disable SDI and write no dump to dump mode SDI is enabled for most of the Qualcomm SoCs and as per commit ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required") it was recommended to disable SDI by mentioning it in device tree to avoid hang during watchdog or during reboot. However, for some cases if download mode tcsr register already configured from boot firmware to collect dumps and if SDI is disabled via means of mentioning it in device tree we could still end up with dump collection. Disabling SDI alone is not completely enough to disable dump mode and we also need to zero out the bits download bits from tcsr register. Current commit now, unconditionally call qcom_scm_set_download_mode() based on download_mode flag, at max if TCSR register is not mentioned or available for a SoC it will fallback to legacy way of setting download mode through command which may be no-ops or return error in case current firmware does not implements QCOM_SCM_INFO_IS_CALL_AVAIL so, at worst it does nothing if it fails. It also does to call SDI disable call if dload mode is disabled, which looks fine to do as intention is to disable dump collection even if system crashes. Fixes: ff4aa3bc9825 ("firmware: qcom_scm: disable SDI if required") Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> Link: https://lore.kernel.org/r/20240708155332.4056479-1-quic_mojha@quicinc.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:59:13 +00:00
if (of_property_read_bool(pdev->dev.of_node, "qcom,sdi-enabled") || !download_mode)
qcom_scm_disable_sdi();
ret = of_reserved_mem_device_init(__scm->dev);
if (ret && ret != -ENODEV) {
dev_err_probe(__scm->dev, ret,
"Failed to setup the reserved memory region for TZ mem\n");
goto err;
}
ret = qcom_tzmem_enable(__scm->dev);
if (ret) {
dev_err_probe(__scm->dev, ret,
"Failed to enable the TrustZone memory allocator\n");
goto err;
}
memset(&pool_config, 0, sizeof(pool_config));
pool_config.initial_size = 0;
pool_config.policy = QCOM_TZMEM_POLICY_ON_DEMAND;
pool_config.max_size = SZ_256K;
__scm->mempool = devm_qcom_tzmem_pool_new(__scm->dev, &pool_config);
if (IS_ERR(__scm->mempool)) {
dev_err_probe(__scm->dev, PTR_ERR(__scm->mempool),
"Failed to create the SCM memory pool\n");
goto err;
}
firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface JIRA: https://issues.redhat.com/browse/RHEL-73299 Conflicts: MAINTAINERS: Context difference. include/linux/firmware/qcom/qcom_scm.h: conflict in whitespace only. This file was erroneously missing the newline at the end of the file in cs9 only since 3a0ebb4a4159, which makes git see the final line as changed even though it doesn't have any meaningful change. commit 00b1248606ba3979ccae30ed11df8cdc1a84245a Author: Maximilian Luz <luzmaximilian@gmail.com> Date: Sun Aug 27 23:14:05 2023 +0200 firmware: qcom_scm: Add support for Qualcomm Secure Execution Environment SCM interface Add support for SCM calls to Secure OS and the Secure Execution Environment (SEE) residing in the TrustZone (TZ) via the QSEECOM interface. This allows communication with Secure/TZ applications, for example 'uefisecapp' managing access to UEFI variables. For better separation, make qcom_scm spin up a dedicated child (platform) device in case QSEECOM support has been detected. The corresponding driver for this device is then responsible for managing any QSEECOM clients. Specifically, this driver attempts to automatically detect known and supported applications, creating a client (auxiliary) device for each one. The respective client/auxiliary driver is then responsible for managing and communicating with the application. While this patch introduces only a very basic interface without the more advanced features (such as re-entrant and blocking SCM calls and listeners/callbacks), this is enough to talk to the aforementioned 'uefisecapp'. Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20230827211408.689076-3-luzmaximilian@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Jennifer Berringer <jberring@redhat.com>
2025-01-31 15:57:44 +00:00
/*
* Initialize the QSEECOM interface.
*
* Note: QSEECOM is fairly self-contained and this only adds the
* interface device (the driver of which does most of the heavy
* lifting). So any errors returned here should be either -ENOMEM or
* -EINVAL (with the latter only in case there's a bug in our code).
* This means that there is no need to bring down the whole SCM driver.
* Just log the error instead and let SCM live.
*/
ret = qcom_scm_qseecom_init(scm);
WARN(ret < 0, "failed to initialize qseecom: %d\n", ret);
return 0;
err:
/* Paired with smp_load_acquire() in qcom_scm_is_available(). */
smp_store_release(&__scm, NULL);
return ret;
}
static void qcom_scm_shutdown(struct platform_device *pdev)
{
/* Clean shutdown, disable download mode to allow normal restart */
qcom_scm_set_download_mode(QCOM_DLOAD_NODUMP);
}
static const struct of_device_id qcom_scm_dt_match[] = {
{ .compatible = "qcom,scm-apq8064",
/* FIXME: This should have .data = (void *) SCM_HAS_CORE_CLK */
},
{ .compatible = "qcom,scm-apq8084", .data = (void *)(SCM_HAS_CORE_CLK |
SCM_HAS_IFACE_CLK |
SCM_HAS_BUS_CLK)
},
{ .compatible = "qcom,scm-ipq4019" },
{ .compatible = "qcom,scm-mdm9607", .data = (void *)(SCM_HAS_CORE_CLK |
SCM_HAS_IFACE_CLK |
SCM_HAS_BUS_CLK) },
{ .compatible = "qcom,scm-msm8660", .data = (void *) SCM_HAS_CORE_CLK },
{ .compatible = "qcom,scm-msm8960", .data = (void *) SCM_HAS_CORE_CLK },
{ .compatible = "qcom,scm-msm8916", .data = (void *)(SCM_HAS_CORE_CLK |
SCM_HAS_IFACE_CLK |
SCM_HAS_BUS_CLK)
},
{ .compatible = "qcom,scm-msm8953", .data = (void *)(SCM_HAS_CORE_CLK |
SCM_HAS_IFACE_CLK |
SCM_HAS_BUS_CLK)
},
{ .compatible = "qcom,scm-msm8974", .data = (void *)(SCM_HAS_CORE_CLK |
SCM_HAS_IFACE_CLK |
SCM_HAS_BUS_CLK)
},
{ .compatible = "qcom,scm-msm8976", .data = (void *)(SCM_HAS_CORE_CLK |
SCM_HAS_IFACE_CLK |
SCM_HAS_BUS_CLK)
},
{ .compatible = "qcom,scm-msm8994" },
{ .compatible = "qcom,scm-msm8996" },
{ .compatible = "qcom,scm-sm6375", .data = (void *)SCM_HAS_CORE_CLK },
{ .compatible = "qcom,scm" },
{}
};
MODULE_DEVICE_TABLE(of, qcom_scm_dt_match);
static struct platform_driver qcom_scm_driver = {
.driver = {
.name = "qcom_scm",
.of_match_table = qcom_scm_dt_match,
.suppress_bind_attrs = true,
},
.probe = qcom_scm_probe,
.shutdown = qcom_scm_shutdown,
};
static int __init qcom_scm_init(void)
{
return platform_driver_register(&qcom_scm_driver);
}
subsys_initcall(qcom_scm_init);
MODULE_DESCRIPTION("Qualcomm Technologies, Inc. SCM driver");
MODULE_LICENSE("GPL v2");