From patchwork Thu Nov 10 13:45:05 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sudeep Holla X-Patchwork-Id: 13038809 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EE142C4332F for ; Thu, 10 Nov 2022 13:46:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0ycwVr2xadVs5Fpc7lqMLdobGvN9hQR1URZfYT92r0E=; b=vGs4PPd0nK+yAE +WynCFgONtI664n+YzNZ9I8QMo27qjhjKSwo4+MaUYu2USAlL2fVDt92erUoY+OnTvKEJZ8awDqzH S9Hyau0lNwPsNAi6mRpGD2zcZua34RBlAZd3EAJLMAY+fqNv1mjFCVML6Itk7CtD9uFU5ydGWOr8Z +WNRYuKcbolT1nfsUeJTA73FIeHYc1miv7quKq/xeYBjD/OLFmqx5CgcT+sw2eNRHgaV/OldY0gyS zugNZE3A1uNF5MKQx8pKHRcLB3PLCoMKFrlhReKiR8GdU3gwRUN48WxyiUAOhRuq4+I0w9luKHWRL KUABjq3171nT+6AFJB7g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ot7rz-00676j-Vo; Thu, 10 Nov 2022 13:45:28 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ot7rn-0066xU-QI for linux-arm-kernel@lists.infradead.org; Thu, 10 Nov 2022 13:45:17 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 16A92D6E; Thu, 10 Nov 2022 05:45:17 -0800 (PST) Received: from usa.arm.com (e103737-lin.cambridge.arm.com [10.1.197.49]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 061D53F703; Thu, 10 Nov 2022 05:45:09 -0800 (PST) From: Sudeep Holla To: linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org Cc: Sudeep Holla , "Rafael J . Wysocki" , Will Deacon , Catalin Marinas Subject: [PATCH v2 2/2] arm64: Add architecture specific ACPI FFH Opregion callbacks Date: Thu, 10 Nov 2022 13:45:05 +0000 Message-Id: <20221110134505.1375955-3-sudeep.holla@arm.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221110134505.1375955-1-sudeep.holla@arm.com> References: <20221110134505.1375955-1-sudeep.holla@arm.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221110_054515_984789_ACCECDF7 X-CRM114-Status: GOOD ( 17.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org FFH Operation Region space can be used to trigger SMC or HVC calls, using the Arm SMC Calling Convention (SMCCC). The choice of conduit (SMC or HVC) is based on what the kernel choose based on PSCI as with any other users of SMCCC within the kernel. Function identifiers only in the SMCCC SiP Service, OEM Service and FF-A specific call range are allowed in FFH Opregions. Offset can be either 0(32 bit calling convention) or 1(64 bit calling convention). The length must be set with the range applicable based on the value of the offset. Acked-by: Catalin Marinas Cc: Will Deacon Signed-off-by: Sudeep Holla --- Hi Will, Catalin had acked the changes to be routed via PM tree for last or the one previous merge window. Since we were waiting for ACPICA changes, it was not merged. Now that ACPICA changes are queued(via PM tree), I will ask Rafael to take these patches now. Just thought I will let you know since you are handling upcoming merge window and I do see few ACPI related changes there. I don't see any conflict with this, so it should be fine. Please let me know if you are fine with that and ack is an add-on :). Regards, Sudeep arch/arm64/kernel/acpi.c | 104 +++++++++++++++++++++++++++++++++++++++ arch/arm64/kernel/acpi.c | 106 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index a5a256e3f9fe..378453faa87e 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -13,6 +13,7 @@ #define pr_fmt(fmt) "ACPI: " fmt #include +#include #include #include #include @@ -411,3 +412,108 @@ void arch_reserve_mem_area(acpi_physical_address addr, size_t size) { memblock_mark_nomap(addr, size); } + +#ifdef CONFIG_ACPI_FFH +/* + * Implements ARM64 specific callbacks to support ACPI FFH Operation Region as + * specified in https://developer.arm.com/docs/den0048/latest + */ +struct acpi_ffh_data { + struct acpi_ffh_info info; + void (*invoke_ffh_fn)(unsigned long a0, unsigned long a1, + unsigned long a2, unsigned long a3, + unsigned long a4, unsigned long a5, + unsigned long a6, unsigned long a7, + struct arm_smccc_res *args, + struct arm_smccc_quirk *res); + void (*invoke_ffh64_fn)(const struct arm_smccc_1_2_regs *args, + struct arm_smccc_1_2_regs *res); +}; + +int acpi_ffh_address_space_arch_setup(void *handler_ctxt, void **region_ctxt) +{ + enum arm_smccc_conduit conduit; + struct acpi_ffh_data *ffh_ctxt; + + ffh_ctxt = kzalloc(sizeof(*ffh_ctxt), GFP_KERNEL); + if (!ffh_ctxt) + return -ENOMEM; + + if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_2) + return -EOPNOTSUPP; + + conduit = arm_smccc_1_1_get_conduit(); + if (conduit == SMCCC_CONDUIT_NONE) { + pr_err("%s: invalid SMCCC conduit\n", __func__); + return -EOPNOTSUPP; + } + + if (conduit == SMCCC_CONDUIT_SMC) { + ffh_ctxt->invoke_ffh_fn = __arm_smccc_smc; + ffh_ctxt->invoke_ffh64_fn = arm_smccc_1_2_smc; + } else { + ffh_ctxt->invoke_ffh_fn = __arm_smccc_hvc; + ffh_ctxt->invoke_ffh64_fn = arm_smccc_1_2_hvc; + } + + memcpy(ffh_ctxt, handler_ctxt, sizeof(ffh_ctxt->info)); + + *region_ctxt = ffh_ctxt; + return AE_OK; +} + +static bool acpi_ffh_smccc_owner_allowed(u32 fid) +{ + int owner = ARM_SMCCC_OWNER_NUM(fid); + + if (owner == ARM_SMCCC_OWNER_STANDARD || + owner == ARM_SMCCC_OWNER_SIP || owner == ARM_SMCCC_OWNER_OEM) + return true; + + return false; +} + +int acpi_ffh_address_space_arch_handler(acpi_integer *value, void *region_context) +{ + int ret = 0; + struct acpi_ffh_data *ffh_ctxt = region_context; + + if (ffh_ctxt->info.offset == 0) { + /* SMC/HVC 32bit call */ + struct arm_smccc_res res; + u32 a[8] = { 0 }, *ptr = (u32 *)value; + + if (!ARM_SMCCC_IS_FAST_CALL(*ptr) || ARM_SMCCC_IS_64(*ptr) || + !acpi_ffh_smccc_owner_allowed(*ptr) || + ffh_ctxt->info.length > 32) { + ret = AE_ERROR; + } else { + int idx, len = ffh_ctxt->info.length >> 2; + + for (idx = 0; idx < len; idx++) + a[idx] = *(ptr + idx); + + ffh_ctxt->invoke_ffh_fn(a[0], a[1], a[2], a[3], a[4], + a[5], a[6], a[7], &res, NULL); + memcpy(value, &res, sizeof(res)); + } + + } else if (ffh_ctxt->info.offset == 1) { + /* SMC/HVC 64bit call */ + struct arm_smccc_1_2_regs *r = (struct arm_smccc_1_2_regs *)value; + + if (!ARM_SMCCC_IS_FAST_CALL(r->a0) || !ARM_SMCCC_IS_64(r->a0) || + !acpi_ffh_smccc_owner_allowed(r->a0) || + ffh_ctxt->info.length > sizeof(*r)) { + ret = AE_ERROR; + } else { + ffh_ctxt->invoke_ffh64_fn(r, r); + memcpy(value, r, ffh_ctxt->info.length); + } + } else { + ret = AE_ERROR; + } + + return ret; +} +#endif /* CONFIG_ACPI_FFH */