[PATCH 0/3] ACPI: Implement FFH OpRegion support

[PATCH 0/3] ACPI: Implement FFH OpRegion support

[Sudeep Holla]

Hi,

This short series adds supports for ACPI Fixed Function Hardware(FFH) based
Opregion that is being added(via Code First approach[1]) to ACPI v6.5

The first patch added ACPICA support for the same and must be routed via
ACPICA project into the kernel and is part of the series just for the
reference. The pull request is already sent there[2].

The second patch added a generic FFH OpRegion handler. Since handling of
FFH OpRegion is very platform and the generic handlers just call the platform/
architecture specific callbacks for all the work.

The last patch added the ARM64 specific callback which handles FFH
OpRegion using arch specific SMC/HVC instructions using SMCCC. The
specification can be found at [3].

[1] https://bugzilla.tianocore.org/show_bug.cgi?id=3598
[2] https://github.com/acpica/acpica/pull/782
[3] https://developer.arm.com/docs/den0048/latest

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>

Sudeep Holla (3):
  ACPICA: Add support for FFH Opregion special context data
  ACPI: Implement a generic FFH Opregion handler
  arm64: Add architecture specific ACPI FFH Opregion callbacks

 arch/arm64/kernel/acpi.c       | 104 +++++++++++++++++++++++++++++++++
 drivers/acpi/Kconfig           |  10 ++++
 drivers/acpi/Makefile          |   1 +
 drivers/acpi/acpi_ffh.c        |  55 +++++++++++++++++
 drivers/acpi/acpica/evregion.c |   8 +++
 drivers/acpi/acpica/exfield.c  |   8 ++-
 drivers/acpi/acpica/exserial.c |   6 ++
 drivers/acpi/bus.c             |   6 ++
 include/acpi/acconfig.h        |   2 +
 include/acpi/actypes.h         |   7 +++
 include/linux/acpi.h           |   7 +++
 11 files changed, 212 insertions(+), 2 deletions(-)
 create mode 100644 drivers/acpi/acpi_ffh.c

--
2.36.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/3] ACPICA: Add support for FFH Opregion special context data

[Sudeep Holla]

FFH(Fixed Function Hardware) Opregion is approved to be added in ACPIC 6.5 via
code first approach[1]. It requires special context data similar to GPIO and
Generic Serial Bus as it needs to know platform specific offset and length.

Add support for the special context data needed by FFH Opregion.

FFH OpRegion enables advanced use of FFH on some architectures. For example,
it could be used to easily proxy AML code to architecture-specific behavior
(to ensure it is OS initiated)

Actual behavior of FFH is ofcourse architecture specific and depends on
the FFH bindings. The offset and length could have arch specific meaning
or usage.

[1] https://bugzilla.tianocore.org/show_bug.cgi?id=3598

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/acpi/acpica/evregion.c | 8 ++++++++
 drivers/acpi/acpica/exfield.c  | 8 ++++++--
 drivers/acpi/acpica/exserial.c | 6 ++++++
 include/acpi/acconfig.h        | 2 ++
 include/acpi/actypes.h         | 7 +++++++
 5 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpica/evregion.c b/drivers/acpi/acpica/evregion.c
index b96b3a7e78e5..d5aed3249630 100644
--- a/drivers/acpi/acpica/evregion.c
+++ b/drivers/acpi/acpica/evregion.c
@@ -172,6 +172,14 @@ acpi_ev_address_space_dispatch(union acpi_operand_object *region_obj,
 			ctx->subspace_id = (u8)region_obj->region.address;
 		}
 
+		if (region_obj->region.space_id ==
+			ACPI_ADR_SPACE_FIXED_HARDWARE) {
+			struct acpi_ffh_info *ctx =
+			    handler_desc->address_space.context;
+
+			ctx->offset = region_obj->region.address;
+			ctx->length = region_obj->region.length;
+		}
 		/*
 		 * We must exit the interpreter because the region setup will
 		 * potentially execute control methods (for example, the _REG method
diff --git a/drivers/acpi/acpica/exfield.c b/drivers/acpi/acpica/exfield.c
index 2b89a496de65..657f4002f9dc 100644
--- a/drivers/acpi/acpica/exfield.c
+++ b/drivers/acpi/acpica/exfield.c
@@ -141,7 +141,9 @@ acpi_ex_read_data_from_field(struct acpi_walk_state *walk_state,
 		    || obj_desc->field.region_obj->region.space_id ==
 		    ACPI_ADR_SPACE_IPMI
 		    || obj_desc->field.region_obj->region.space_id ==
-		    ACPI_ADR_SPACE_PLATFORM_RT)) {
+		    ACPI_ADR_SPACE_PLATFORM_RT
+		    || obj_desc->field.region_obj->region.space_id ==
+		    ACPI_ADR_SPACE_FIXED_HARDWARE)) {
 
 		/* SMBus, GSBus, IPMI serial */
 
@@ -305,7 +307,9 @@ acpi_ex_write_data_to_field(union acpi_operand_object *source_desc,
 		    || obj_desc->field.region_obj->region.space_id ==
 		    ACPI_ADR_SPACE_IPMI
 		    || obj_desc->field.region_obj->region.space_id ==
-		    ACPI_ADR_SPACE_PLATFORM_RT)) {
+		    ACPI_ADR_SPACE_PLATFORM_RT
+		    || obj_desc->field.region_obj->region.space_id ==
+		    ACPI_ADR_SPACE_FIXED_HARDWARE)) {
 
 		/* SMBus, GSBus, IPMI serial */
 
diff --git a/drivers/acpi/acpica/exserial.c b/drivers/acpi/acpica/exserial.c
index 4da20d7845df..fd63f2042514 100644
--- a/drivers/acpi/acpica/exserial.c
+++ b/drivers/acpi/acpica/exserial.c
@@ -323,6 +323,12 @@ acpi_ex_write_serial_bus(union acpi_operand_object *source_desc,
 		function = ACPI_WRITE;
 		break;
 
+	case ACPI_ADR_SPACE_FIXED_HARDWARE:
+
+		buffer_length = ACPI_FFH_INPUT_BUFFER_SIZE;
+		function = ACPI_WRITE;
+		break;
+
 	default:
 		return_ACPI_STATUS(AE_AML_INVALID_SPACE_ID);
 	}
diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h
index c3ae3ea88e17..02e57191c1fd 100644
--- a/include/acpi/acconfig.h
+++ b/include/acpi/acconfig.h
@@ -190,6 +190,8 @@
 
 #define ACPI_PRM_INPUT_BUFFER_SIZE      26
 
+#define ACPI_FFH_INPUT_BUFFER_SIZE      144
+
 /* _sx_d and _sx_w control methods */
 
 #define ACPI_NUM_sx_d_METHODS           4
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 3491e454b2ab..1b4f81f1ac5d 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -1115,6 +1115,13 @@ struct acpi_pcc_info {
 	u8 *internal_buffer;
 };
 
+/* Special Context data for FFH Opregion (ACPI 6.5) */
+
+struct acpi_ffh_info {
+	u64 offset;
+	u64 length;
+};
+
 typedef
 acpi_status (*acpi_adr_space_setup) (acpi_handle region_handle,
 				     u32 function,
-- 
2.36.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/3] ACPI: Implement a generic FFH Opregion handler

[Sudeep Holla]

This registers the FFH OpRegion handler before ACPI tables are
loaded. The platform support for the same is checked via Platform-Wide
OSPM Capabilities(OSC) before registering the OpRegion handler.

It relies on the special context data passed to offset and the length.
However the interpretation of the values is platform/architecture
specific. This generic handler just passed all the information to
the platform/architecture specific callback. It also implements the
default callbacks which return as not supported.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/acpi/Kconfig    | 10 ++++++++
 drivers/acpi/Makefile   |  1 +
 drivers/acpi/acpi_ffh.c | 55 +++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/bus.c      |  6 +++++
 include/linux/acpi.h    |  7 ++++++
 5 files changed, 79 insertions(+)
 create mode 100644 drivers/acpi/acpi_ffh.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1e34f846508f..c1cf40b7d22b 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -567,6 +567,16 @@ config ACPI_PCC
 	  Enable this feature if you want to set up and install the PCC Address
 	  Space handler to handle PCC OpRegion in the firmware.
 
+config ACPI_FFH
+	bool "ACPI FFH Address Space"
+	default n
+	help
+	  The FFH(Fixed Function Hardware) Address Space also referred as FFH
+	  Operation Region allows to define platform specific opregion.
+
+	  Enable this feature if you want to set up and install the FFH Address
+	  Space handler to handle FFH OpRegion in the firmware.
+
 source "drivers/acpi/pmic/Kconfig"
 
 config ACPI_VIOT
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b5a8d3e00a52..d2fc0587e218 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -68,6 +68,7 @@ acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
 acpi-$(CONFIG_ACPI_WATCHDOG)	+= acpi_watchdog.o
 acpi-$(CONFIG_ACPI_PRMT)	+= prmt.o
 acpi-$(CONFIG_ACPI_PCC)		+= acpi_pcc.o
+acpi-$(CONFIG_ACPI_FFH)		+= acpi_ffh.o
 
 # Address translation
 acpi-$(CONFIG_ACPI_ADXL)	+= acpi_adxl.o
diff --git a/drivers/acpi/acpi_ffh.c b/drivers/acpi/acpi_ffh.c
new file mode 100644
index 000000000000..19aff808bbb8
--- /dev/null
+++ b/drivers/acpi/acpi_ffh.c
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Author: Sudeep Holla <sudeep.holla@arm.com>
+ * Copyright 2022 Arm Limited
+ */
+#include <linux/kernel.h>
+#include <linux/acpi.h>
+#include <linux/completion.h>
+#include <linux/idr.h>
+#include <linux/io.h>
+
+#include <linux/arm-smccc.h>
+
+static struct acpi_ffh_info ffh_ctx;
+
+int __weak acpi_ffh_address_space_arch_setup(void *handler_ctxt,
+					     void **region_ctxt)
+{
+	return -EOPNOTSUPP;
+}
+
+int __weak acpi_ffh_address_space_arch_handler(acpi_integer *value,
+					       void *region_context)
+{
+	return -EOPNOTSUPP;
+}
+
+static acpi_status
+acpi_ffh_address_space_setup(acpi_handle region_handle, u32 function,
+			     void *handler_context,  void **region_context)
+{
+	return acpi_ffh_address_space_arch_setup(handler_context,
+						 region_context);
+}
+
+static acpi_status
+acpi_ffh_address_space_handler(u32 function, acpi_physical_address addr,
+			       u32 bits, acpi_integer *value,
+			       void *handler_context, void *region_context)
+{
+	return acpi_ffh_address_space_arch_handler(value, region_context);
+}
+
+void __init acpi_init_ffh(void)
+{
+	acpi_status status;
+
+	status = acpi_install_address_space_handler(ACPI_ROOT_OBJECT,
+						    ACPI_ADR_SPACE_FIXED_HARDWARE,
+						    &acpi_ffh_address_space_handler,
+						    &acpi_ffh_address_space_setup,
+						    &ffh_ctx);
+	if (ACPI_FAILURE(status))
+		pr_alert("OperationRegion handler could not be installed\n");
+}
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 86fa61a21826..84734c8cc714 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -298,6 +298,8 @@ EXPORT_SYMBOL_GPL(osc_cpc_flexible_adr_space_confirmed);
 bool osc_sb_native_usb4_support_confirmed;
 EXPORT_SYMBOL_GPL(osc_sb_native_usb4_support_confirmed);
 
+bool osc_sb_ffh_opregion_support_confirmed;
+
 bool osc_sb_cppc_not_supported;
 
 static u8 sb_uuid_str[] = "0811B06E-4A27-44F9-8D60-3CBBC22E7B48";
@@ -384,6 +386,8 @@ static void acpi_bus_osc_negotiate_platform_control(void)
 			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT;
 		osc_cpc_flexible_adr_space_confirmed =
 			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_CPC_FLEXIBLE_ADR_SPACE;
+		osc_sb_ffh_opregion_support_confirmed =
+			capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_FFH_OPR_SUPPORT;
 	}
 
 	kfree(context.ret.pointer);
@@ -1397,6 +1401,8 @@ static int __init acpi_init(void)
 		disable_acpi();
 		return result;
 	}
+	if (osc_sb_ffh_opregion_support_confirmed)
+		acpi_init_ffh();
 
 	pci_mmcfg_late_init();
 	acpi_iort_init();
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4f82a5bc6d98..471c42a6044c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -580,6 +580,7 @@ acpi_status acpi_run_osc(acpi_handle handle, struct acpi_osc_context *context);
 #define OSC_SB_CPC_FLEXIBLE_ADR_SPACE		0x00004000
 #define OSC_SB_NATIVE_USB4_SUPPORT		0x00040000
 #define OSC_SB_PRM_SUPPORT			0x00200000
+#define OSC_SB_FFH_OPR_SUPPORT			0x00400000
 
 extern bool osc_sb_apei_support_acked;
 extern bool osc_pc_lpi_support_confirmed;
@@ -1463,6 +1464,12 @@ void acpi_init_pcc(void);
 static inline void acpi_init_pcc(void) { }
 #endif
 
+#ifdef CONFIG_ACPI_FFH
+void acpi_init_ffh(void);
+#else
+static inline void acpi_init_ffh(void) { }
+#endif
+
 #ifdef CONFIG_ACPI
 extern void acpi_device_notify(struct device *dev);
 extern void acpi_device_notify_remove(struct device *dev);
-- 
2.36.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/3] arm64: Add architecture specific ACPI FFH Opregion callbacks

[Sudeep Holla]

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 the SMCCC SiP Service, OEM Service and FF-A
specific call range.

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.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 arch/arm64/kernel/acpi.c | 104 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index e4dea8db6924..3eb64d443ab0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -13,6 +13,7 @@
 #define pr_fmt(fmt) "ACPI: " fmt
 
 #include <linux/acpi.h>
+#include <linux/arm-smccc.h>
 #include <linux/cpumask.h>
 #include <linux/efi.h>
 #include <linux/efi-bgrt.h>
@@ -411,3 +412,106 @@ 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, unsigned long, unsigned long,
+			      unsigned long, unsigned long, unsigned long,
+			      unsigned long, unsigned long,
+			      struct arm_smccc_res *, struct arm_smccc_quirk *);
+	void (*invoke_ffh64_fn)(const struct arm_smccc_1_2_regs *,
+				struct arm_smccc_1_2_regs *);
+};
+
+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 */
-- 
2.36.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/3] ACPICA: Add support for FFH Opregion special context data

[Rafael J. Wysocki]

On Thu, Jun 16, 2022 at 11:01 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> FFH(Fixed Function Hardware) Opregion is approved to be added in ACPIC 6.5 via

s/ACPIC/ACPI/

> code first approach[1]. It requires special context data similar to GPIO and
> Generic Serial Bus as it needs to know platform specific offset and length.
>
> Add support for the special context data needed by FFH Opregion.
>
> FFH OpRegion enables advanced use of FFH on some architectures. For example,
> it could be used to easily proxy AML code to architecture-specific behavior
> (to ensure it is OS initiated)
>
> Actual behavior of FFH is ofcourse architecture specific and depends on
> the FFH bindings. The offset and length could have arch specific meaning
> or usage.
>
> [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3598
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

This looks reasonable to me and I see that you've already submitted a
pull request to the upstream ACPICA.

> ---
>  drivers/acpi/acpica/evregion.c | 8 ++++++++
>  drivers/acpi/acpica/exfield.c  | 8 ++++++--
>  drivers/acpi/acpica/exserial.c | 6 ++++++
>  include/acpi/acconfig.h        | 2 ++
>  include/acpi/actypes.h         | 7 +++++++
>  5 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/acpica/evregion.c b/drivers/acpi/acpica/evregion.c
> index b96b3a7e78e5..d5aed3249630 100644
> --- a/drivers/acpi/acpica/evregion.c
> +++ b/drivers/acpi/acpica/evregion.c
> @@ -172,6 +172,14 @@ acpi_ev_address_space_dispatch(union acpi_operand_object *region_obj,
>                         ctx->subspace_id = (u8)region_obj->region.address;
>                 }
>
> +               if (region_obj->region.space_id ==
> +                       ACPI_ADR_SPACE_FIXED_HARDWARE) {
> +                       struct acpi_ffh_info *ctx =
> +                           handler_desc->address_space.context;
> +
> +                       ctx->offset = region_obj->region.address;
> +                       ctx->length = region_obj->region.length;
> +               }
>                 /*
>                  * We must exit the interpreter because the region setup will
>                  * potentially execute control methods (for example, the _REG method
> diff --git a/drivers/acpi/acpica/exfield.c b/drivers/acpi/acpica/exfield.c
> index 2b89a496de65..657f4002f9dc 100644
> --- a/drivers/acpi/acpica/exfield.c
> +++ b/drivers/acpi/acpica/exfield.c
> @@ -141,7 +141,9 @@ acpi_ex_read_data_from_field(struct acpi_walk_state *walk_state,
>                     || obj_desc->field.region_obj->region.space_id ==
>                     ACPI_ADR_SPACE_IPMI
>                     || obj_desc->field.region_obj->region.space_id ==
> -                   ACPI_ADR_SPACE_PLATFORM_RT)) {
> +                   ACPI_ADR_SPACE_PLATFORM_RT
> +                   || obj_desc->field.region_obj->region.space_id ==
> +                   ACPI_ADR_SPACE_FIXED_HARDWARE)) {
>
>                 /* SMBus, GSBus, IPMI serial */
>
> @@ -305,7 +307,9 @@ acpi_ex_write_data_to_field(union acpi_operand_object *source_desc,
>                     || obj_desc->field.region_obj->region.space_id ==
>                     ACPI_ADR_SPACE_IPMI
>                     || obj_desc->field.region_obj->region.space_id ==
> -                   ACPI_ADR_SPACE_PLATFORM_RT)) {
> +                   ACPI_ADR_SPACE_PLATFORM_RT
> +                   || obj_desc->field.region_obj->region.space_id ==
> +                   ACPI_ADR_SPACE_FIXED_HARDWARE)) {
>
>                 /* SMBus, GSBus, IPMI serial */
>
> diff --git a/drivers/acpi/acpica/exserial.c b/drivers/acpi/acpica/exserial.c
> index 4da20d7845df..fd63f2042514 100644
> --- a/drivers/acpi/acpica/exserial.c
> +++ b/drivers/acpi/acpica/exserial.c
> @@ -323,6 +323,12 @@ acpi_ex_write_serial_bus(union acpi_operand_object *source_desc,
>                 function = ACPI_WRITE;
>                 break;
>
> +       case ACPI_ADR_SPACE_FIXED_HARDWARE:
> +
> +               buffer_length = ACPI_FFH_INPUT_BUFFER_SIZE;
> +               function = ACPI_WRITE;
> +               break;
> +
>         default:
>                 return_ACPI_STATUS(AE_AML_INVALID_SPACE_ID);
>         }
> diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h
> index c3ae3ea88e17..02e57191c1fd 100644
> --- a/include/acpi/acconfig.h
> +++ b/include/acpi/acconfig.h
> @@ -190,6 +190,8 @@
>
>  #define ACPI_PRM_INPUT_BUFFER_SIZE      26
>
> +#define ACPI_FFH_INPUT_BUFFER_SIZE      144
> +
>  /* _sx_d and _sx_w control methods */
>
>  #define ACPI_NUM_sx_d_METHODS           4
> diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
> index 3491e454b2ab..1b4f81f1ac5d 100644
> --- a/include/acpi/actypes.h
> +++ b/include/acpi/actypes.h
> @@ -1115,6 +1115,13 @@ struct acpi_pcc_info {
>         u8 *internal_buffer;
>  };
>
> +/* Special Context data for FFH Opregion (ACPI 6.5) */
> +
> +struct acpi_ffh_info {
> +       u64 offset;
> +       u64 length;
> +};
> +
>  typedef
>  acpi_status (*acpi_adr_space_setup) (acpi_handle region_handle,
>                                      u32 function,
> --
> 2.36.1
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/3] ACPICA: Add support for FFH Opregion special context data

[Sudeep Holla]

On Wed, Jun 22, 2022 at 02:50:08PM +0200, Rafael J. Wysocki wrote:
> On Thu, Jun 16, 2022 at 11:01 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > FFH(Fixed Function Hardware) Opregion is approved to be added in ACPIC 6.5 via
> 
> s/ACPIC/ACPI/
>

Fixed and pushed in ACPICA PR.

> > code first approach[1]. It requires special context data similar to GPIO and
> > Generic Serial Bus as it needs to know platform specific offset and length.
> >
> > Add support for the special context data needed by FFH Opregion.
> >
> > FFH OpRegion enables advanced use of FFH on some architectures. For example,
> > it could be used to easily proxy AML code to architecture-specific behavior
> > (to ensure it is OS initiated)
> >
> > Actual behavior of FFH is ofcourse architecture specific and depends on
> > the FFH bindings. The offset and length could have arch specific meaning
> > or usage.
> >
> > [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3598
> >
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> 
> This looks reasonable to me and I see that you've already submitted a
> pull request to the upstream ACPICA.

I assume you would prefer me to post the other 2 patches once this lands
in your -next. Worst case I would like to get the generic patch in along
with ACPICA changes, I can then route the arm64 specific next cycle if it
gets too late for v5.20

-- 
Regards,
Sudeep

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/3] ACPICA: Add support for FFH Opregion special context data

[Rafael J. Wysocki]

On Wed, Jun 22, 2022 at 4:01 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Wed, Jun 22, 2022 at 02:50:08PM +0200, Rafael J. Wysocki wrote:
> > On Thu, Jun 16, 2022 at 11:01 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > FFH(Fixed Function Hardware) Opregion is approved to be added in ACPIC 6.5 via
> >
> > s/ACPIC/ACPI/
> >
>
> Fixed and pushed in ACPICA PR.
>
> > > code first approach[1]. It requires special context data similar to GPIO and
> > > Generic Serial Bus as it needs to know platform specific offset and length.
> > >
> > > Add support for the special context data needed by FFH Opregion.
> > >
> > > FFH OpRegion enables advanced use of FFH on some architectures. For example,
> > > it could be used to easily proxy AML code to architecture-specific behavior
> > > (to ensure it is OS initiated)
> > >
> > > Actual behavior of FFH is ofcourse architecture specific and depends on
> > > the FFH bindings. The offset and length could have arch specific meaning
> > > or usage.
> > >
> > > [1] https://bugzilla.tianocore.org/show_bug.cgi?id=3598
> > >
> > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> >
> > This looks reasonable to me and I see that you've already submitted a
> > pull request to the upstream ACPICA.
>
> I assume you would prefer me to post the other 2 patches once this lands
> in your -next.

That would be ideal, but technically I can apply an ACPICA patch in
advance once the corresponding pull request has been integrated
upstream.

> Worst case I would like to get the generic patch in along
> with ACPICA changes, I can then route the arm64 specific next cycle if it
> gets too late for v5.20

Let's try the normal flow and worry about workarounds if it gets late.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/3] arm64: Add architecture specific ACPI FFH Opregion callbacks

[Catalin Marinas]

On Thu, Jun 16, 2022 at 10:01:06AM +0100, Sudeep Holla wrote:
> 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 the SMCCC SiP Service, OEM Service and FF-A
> specific call range.
> 
> 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.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel