driver to support ACPI AML calls to native firmware

driver to support ACPI AML calls to native firmware

[Bjorn Helgaas]

Here's the driver with no exported symbols.

[patch 1/2] ia64: abstract SAL_CALL wrapper to allow other firmware entry points

[Bjorn Helgaas]

SAL_CALL() always calls through the ia64_sal function pointer.  I am adding
new functionality that needs the same conventions as SAL_CALL (FP regs
saved/restored, sal_lock acquired, etc), but doesn't use the ia64_sal
function pointer.

This patch pulls the body of SAL_CALL out into a new "IA64_FW_CALL" that
takes care of these calling conventions, but allows the caller to specify
either ia64_sal or some other firmware entry point.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: work2/include/asm-ia64/sal.h
===================================================================
--- work2.orig/include/asm-ia64/sal.h	2007-09-19 10:25:12.000000000 -0600
+++ work2/include/asm-ia64/sal.h	2007-09-19 10:27:15.000000000 -0600
@@ -46,25 +46,28 @@
 extern spinlock_t sal_lock;
 
 /* SAL spec _requires_ eight args for each call. */
-#define __SAL_CALL(result,a0,a1,a2,a3,a4,a5,a6,a7)	\
-	result = (*ia64_sal)(a0,a1,a2,a3,a4,a5,a6,a7)
+#define __IA64_FW_CALL(entry,result,a0,a1,a2,a3,a4,a5,a6,a7)	\
+	result = (*entry)(a0,a1,a2,a3,a4,a5,a6,a7)
 
-# define SAL_CALL(result,args...) do {				\
+# define IA64_FW_CALL(entry,result,args...) do {		\
 	unsigned long __ia64_sc_flags;				\
 	struct ia64_fpreg __ia64_sc_fr[6];			\
 	ia64_save_scratch_fpregs(__ia64_sc_fr);			\
 	spin_lock_irqsave(&sal_lock, __ia64_sc_flags);		\
-	__SAL_CALL(result, args);				\
+	__IA64_FW_CALL(entry, result, args);			\
 	spin_unlock_irqrestore(&sal_lock, __ia64_sc_flags);	\
 	ia64_load_scratch_fpregs(__ia64_sc_fr);			\
 } while (0)
 
+# define SAL_CALL(result,args...)			\
+	IA64_FW_CALL(ia64_sal, result, args);
+
 # define SAL_CALL_NOLOCK(result,args...) do {		\
 	unsigned long __ia64_scn_flags;			\
 	struct ia64_fpreg __ia64_scn_fr[6];		\
 	ia64_save_scratch_fpregs(__ia64_scn_fr);	\
 	local_irq_save(__ia64_scn_flags);		\
-	__SAL_CALL(result, args);			\
+	__IA64_FW_CALL(ia64_sal, result, args);		\
 	local_irq_restore(__ia64_scn_flags);		\
 	ia64_load_scratch_fpregs(__ia64_scn_fr);	\
 } while (0)
@@ -73,7 +76,7 @@
 	struct ia64_fpreg __ia64_scs_fr[6];		\
 	ia64_save_scratch_fpregs(__ia64_scs_fr);	\
 	preempt_disable();				\
-	__SAL_CALL(result, args);			\
+	__IA64_FW_CALL(ia64_sal, result, args);		\
 	preempt_enable();				\
 	ia64_load_scratch_fpregs(__ia64_scs_fr);	\
 } while (0)

[patch 2/2] ia64: add driver for ACPI methods to call native firmware

[Bjorn Helgaas]

This driver for HPQ5001 devices installs a global ACPI OpRegion handler.
AML methods can use this OpRegion to call native firmware entry points.

ACPI does not define a mechanism for AML methods to call native firmware
interfaces such as PAL or SAL.  This OpRegion handler adds such a mechanism.
After the handler is installed, an AML method can call native firmware by
storing the arguments and firmware entry point to specific offsets in the
OpRegion.  When AML reads the "return value" offset from the OpRegion, this
handler loads up the arguments, makes the firmware call, and returns the
result.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: work2/arch/ia64/Kconfig
===================================================================
--- work2.orig/arch/ia64/Kconfig	2007-09-19 10:09:43.000000000 -0600
+++ work2/arch/ia64/Kconfig	2007-09-19 10:51:15.000000000 -0600
@@ -461,6 +461,16 @@
 	  firmware extensions, such as the ability to inject memory-errors
 	  for test-purposes.  If you're unsure, say N.
 
+config IA64_HP_AML_NFW
+	bool "Support ACPI AML calls to native firmware"
+	help
+	  This driver installs a global ACPI Operation Region handler for
+	  region 0xA1.  AML methods can use this OpRegion to call arbitrary
+	  native firmware functions.  The driver installs the OpRegion
+	  handler if there is an HPQ5001 device or if the user supplies
+	  the "force" module parameter, e.g., with the "aml_nfw.force"
+	  kernel command line option.
+
 source "drivers/sn/Kconfig"
 
 config KEXEC
Index: work2/arch/ia64/hp/common/Makefile
===================================================================
--- work2.orig/arch/ia64/hp/common/Makefile	2007-09-19 10:09:43.000000000 -0600
+++ work2/arch/ia64/hp/common/Makefile	2007-09-19 10:51:15.000000000 -0600
@@ -8,3 +8,4 @@
 obj-y := sba_iommu.o
 obj-$(CONFIG_IA64_HP_ZX1_SWIOTLB) += hwsw_iommu.o
 obj-$(CONFIG_IA64_GENERIC) += hwsw_iommu.o
+obj-$(CONFIG_IA64_HP_AML_NFW) += aml_nfw.o
Index: work2/arch/ia64/hp/common/aml_nfw.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ work2/arch/ia64/hp/common/aml_nfw.c	2007-09-20 14:05:21.000000000 -0600
@@ -0,0 +1,236 @@
+/*
+ * OpRegion handler to allow AML to call native firmware
+ *
+ * (c) Copyright 2007 Hewlett-Packard Development Company, L.P.
+ *	Bjorn Helgaas <bjorn.helgaas@hp.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This driver implements HP Open Source Review Board proposal 1842,
+ * which was approved on 9/20/2006.
+ *
+ * For technical documentation, see the HP SPPA Firmware EAS, Appendix F.
+ *
+ * ACPI does not define a mechanism for AML methods to call native firmware
+ * interfaces such as PAL or SAL.  This OpRegion handler adds such a mechanism.
+ * After the handler is installed, an AML method can call native firmware by
+ * storing the arguments and firmware entry point to specific offsets in the
+ * OpRegion.  When AML reads the "return value" offset from the OpRegion, this
+ * handler loads up the arguments, makes the firmware call, and returns the
+ * result.
+ */
+
+#include <linux/module.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <asm/sal.h>
+
+MODULE_AUTHOR("Bjorn Helgaas <bjorn.helgaas@hp.com>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ACPI opregion handler for native firmware calls");
+
+static int force_register;
+module_param_named(force, force_register, bool, 0);
+MODULE_PARM_DESC(force, "Install opregion handler even without HPQ5001 device");
+
+#define AML_NFW_SPACE		0xA1
+
+struct ia64_pdesc {
+	void *ip;
+	void *gp;
+};
+
+/*
+ * N.B.  The layout of this structure is defined in the HP SPPA FW EAS, and
+ *	 the member offsets are embedded in AML methods.
+ */
+struct ia64_nfw_context {
+	u64 arg[8];
+	struct ia64_sal_retval ret;
+	u64 ip;
+	u64 gp;
+	u64 pad[2];
+};
+
+static void *virt_map(u64 address)
+{
+	if (address & (1UL << 63))
+		return (void *) (__IA64_UNCACHED_OFFSET | address);
+
+	return __va(address);
+}
+
+static void aml_nfw_execute(struct ia64_nfw_context *c)
+{
+	struct ia64_pdesc virt_entry;
+	ia64_sal_handler entry;
+
+	virt_entry.ip = virt_map(c->ip);
+	virt_entry.gp = virt_map(c->gp);
+
+	entry = (ia64_sal_handler) &virt_entry;
+
+	IA64_FW_CALL(entry, c->ret,
+		     c->arg[0], c->arg[1], c->arg[2], c->arg[3],
+		     c->arg[4], c->arg[5], c->arg[6], c->arg[7]);
+}
+
+static void aml_nfw_read_arg(u8 *offset, u32 bit_width, acpi_integer *value)
+{
+	switch (bit_width) {
+	case 8:
+		*value = *(u8 *)offset;
+		break;
+	case 16:
+		*value = *(u16 *)offset;
+		break;
+	case 32:
+		*value = *(u32 *)offset;
+		break;
+	case 64:
+		*value = *(u64 *)offset;
+		break;
+	}
+}
+
+static void aml_nfw_write_arg(u8 *offset, u32 bit_width, acpi_integer *value)
+{
+	switch (bit_width) {
+	case 8:
+		*(u8 *) offset = *value;
+		break;
+	case 16:
+		*(u16 *) offset = *value;
+		break;
+	case 32:
+		*(u32 *) offset = *value;
+		break;
+	case 64:
+		*(u64 *) offset = *value;
+		break;
+	}
+}
+
+static acpi_status aml_nfw_handler(u32 function, acpi_physical_address address,
+	u32 bit_width, acpi_integer *value, void *handler_context,
+	void *region_context)
+{
+	struct ia64_nfw_context *context = handler_context;
+	u8 *offset = (u8 *) context + address;
+
+	if (bit_width !=  8 && bit_width != 16 &&
+	    bit_width != 32 && bit_width != 64)
+		return AE_BAD_PARAMETER;
+
+	if (address + (bit_width >> 3) > sizeof(struct ia64_nfw_context))
+		return AE_BAD_PARAMETER;
+
+	switch (function) {
+	case ACPI_READ:
+		if (address == offsetof(struct ia64_nfw_context, ret))
+			aml_nfw_execute(context);
+		aml_nfw_read_arg(offset, bit_width, value);
+		break;
+	case ACPI_WRITE:
+		aml_nfw_write_arg(offset, bit_width, value);
+		break;
+	}
+
+	return AE_OK;
+}
+
+static struct ia64_nfw_context global_context;
+static int global_handler_registered;
+
+static int aml_nfw_add_global_handler(void)
+{
+	acpi_status status;
+
+	if (global_handler_registered)
+		return 0;
+
+	status = acpi_install_address_space_handler(ACPI_ROOT_OBJECT,
+		AML_NFW_SPACE, aml_nfw_handler, NULL, &global_context);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	global_handler_registered = 1;
+	printk(KERN_INFO "Global 0x%02X opregion handler registered\n",
+		AML_NFW_SPACE);
+	return 0;
+}
+
+static int aml_nfw_remove_global_handler(void)
+{
+	acpi_status status;
+
+	if (!global_handler_registered)
+		return 0;
+
+	status = acpi_remove_address_space_handler(ACPI_ROOT_OBJECT,
+		AML_NFW_SPACE, aml_nfw_handler);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	global_handler_registered = 0;
+	printk(KERN_INFO "Global 0x%02X opregion handler removed\n",
+		AML_NFW_SPACE);
+	return 0;
+}
+
+static int aml_nfw_add(struct acpi_device *device)
+{
+	/*
+	 * We would normally allocate a new context structure and install
+	 * the address space handler for the specific device we found.
+	 * But the HP-UX implementation shares a single global context
+	 * and always puts the handler at the root, so we'll do the same.
+	 */
+	return aml_nfw_add_global_handler();
+}
+
+static int aml_nfw_remove(struct acpi_device *device, int type)
+{
+	return aml_nfw_remove_global_handler();
+}
+
+static const struct acpi_device_id aml_nfw_ids[] = {
+	{"HPQ5001", 0},
+	{"", 0}
+};
+
+static struct acpi_driver acpi_aml_nfw_driver = {
+	.name = "native firmware",
+	.ids = aml_nfw_ids,
+	.ops = {
+		.add = aml_nfw_add,
+		.remove = aml_nfw_remove,
+		},
+};
+
+static int __init aml_nfw_init(void)
+{
+	int result;
+
+	if (force_register)
+		aml_nfw_add_global_handler();
+
+	result = acpi_bus_register_driver(&acpi_aml_nfw_driver);
+	if (result < 0) {
+		aml_nfw_remove_global_handler();
+		return result;
+	}
+
+	return 0;
+}
+
+static void __exit aml_nfw_exit(void)
+{
+	acpi_bus_unregister_driver(&acpi_aml_nfw_driver);
+	aml_nfw_remove_global_handler();
+}
+
+module_init(aml_nfw_init);
+module_exit(aml_nfw_exit);

Re: [patch 2/2] ia64: add driver for ACPI methods to call native firmware

[Len Brown]

I guess x86 does this via SMI,
I don't see any other way, so it looks reasonable to me.

Tony,
Acked-by: Len Brown <len.brown@intel.com>

On Thursday 20 September 2007 16:22, Bjorn Helgaas wrote:
> This driver for HPQ5001 devices installs a global ACPI OpRegion handler.
> AML methods can use this OpRegion to call native firmware entry points.
> 
> ACPI does not define a mechanism for AML methods to call native firmware
> interfaces such as PAL or SAL.  This OpRegion handler adds such a mechanism.
> After the handler is installed, an AML method can call native firmware by
> storing the arguments and firmware entry point to specific offsets in the
> OpRegion.  When AML reads the "return value" offset from the OpRegion, this
> handler loads up the arguments, makes the firmware call, and returns the
> result.
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> 
> Index: work2/arch/ia64/Kconfig
> ===================================================================
> --- work2.orig/arch/ia64/Kconfig	2007-09-19 10:09:43.000000000 -0600
> +++ work2/arch/ia64/Kconfig	2007-09-19 10:51:15.000000000 -0600
> @@ -461,6 +461,16 @@
>  	  firmware extensions, such as the ability to inject memory-errors
>  	  for test-purposes.  If you're unsure, say N.
>  
> +config IA64_HP_AML_NFW
> +	bool "Support ACPI AML calls to native firmware"
> +	help
> +	  This driver installs a global ACPI Operation Region handler for
> +	  region 0xA1.  AML methods can use this OpRegion to call arbitrary
> +	  native firmware functions.  The driver installs the OpRegion
> +	  handler if there is an HPQ5001 device or if the user supplies
> +	  the "force" module parameter, e.g., with the "aml_nfw.force"
> +	  kernel command line option.
> +
>  source "drivers/sn/Kconfig"
>  
>  config KEXEC
> Index: work2/arch/ia64/hp/common/Makefile
> ===================================================================
> --- work2.orig/arch/ia64/hp/common/Makefile	2007-09-19 10:09:43.000000000 -0600
> +++ work2/arch/ia64/hp/common/Makefile	2007-09-19 10:51:15.000000000 -0600
> @@ -8,3 +8,4 @@
>  obj-y := sba_iommu.o
>  obj-$(CONFIG_IA64_HP_ZX1_SWIOTLB) += hwsw_iommu.o
>  obj-$(CONFIG_IA64_GENERIC) += hwsw_iommu.o
> +obj-$(CONFIG_IA64_HP_AML_NFW) += aml_nfw.o
> Index: work2/arch/ia64/hp/common/aml_nfw.c
> ===================================================================
> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
> +++ work2/arch/ia64/hp/common/aml_nfw.c	2007-09-20 14:05:21.000000000 -0600
> @@ -0,0 +1,236 @@
> +/*
> + * OpRegion handler to allow AML to call native firmware
> + *
> + * (c) Copyright 2007 Hewlett-Packard Development Company, L.P.
> + *	Bjorn Helgaas <bjorn.helgaas@hp.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This driver implements HP Open Source Review Board proposal 1842,
> + * which was approved on 9/20/2006.
> + *
> + * For technical documentation, see the HP SPPA Firmware EAS, Appendix F.
> + *
> + * ACPI does not define a mechanism for AML methods to call native firmware
> + * interfaces such as PAL or SAL.  This OpRegion handler adds such a mechanism.
> + * After the handler is installed, an AML method can call native firmware by
> + * storing the arguments and firmware entry point to specific offsets in the
> + * OpRegion.  When AML reads the "return value" offset from the OpRegion, this
> + * handler loads up the arguments, makes the firmware call, and returns the
> + * result.
> + */
> +
> +#include <linux/module.h>
> +#include <acpi/acpi_bus.h>
> +#include <acpi/acpi_drivers.h>
> +#include <asm/sal.h>
> +
> +MODULE_AUTHOR("Bjorn Helgaas <bjorn.helgaas@hp.com>");
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("ACPI opregion handler for native firmware calls");
> +
> +static int force_register;
> +module_param_named(force, force_register, bool, 0);
> +MODULE_PARM_DESC(force, "Install opregion handler even without HPQ5001 device");
> +
> +#define AML_NFW_SPACE		0xA1
> +
> +struct ia64_pdesc {
> +	void *ip;
> +	void *gp;
> +};
> +
> +/*
> + * N.B.  The layout of this structure is defined in the HP SPPA FW EAS, and
> + *	 the member offsets are embedded in AML methods.
> + */
> +struct ia64_nfw_context {
> +	u64 arg[8];
> +	struct ia64_sal_retval ret;
> +	u64 ip;
> +	u64 gp;
> +	u64 pad[2];
> +};
> +
> +static void *virt_map(u64 address)
> +{
> +	if (address & (1UL << 63))
> +		return (void *) (__IA64_UNCACHED_OFFSET | address);
> +
> +	return __va(address);
> +}
> +
> +static void aml_nfw_execute(struct ia64_nfw_context *c)
> +{
> +	struct ia64_pdesc virt_entry;
> +	ia64_sal_handler entry;
> +
> +	virt_entry.ip = virt_map(c->ip);
> +	virt_entry.gp = virt_map(c->gp);
> +
> +	entry = (ia64_sal_handler) &virt_entry;
> +
> +	IA64_FW_CALL(entry, c->ret,
> +		     c->arg[0], c->arg[1], c->arg[2], c->arg[3],
> +		     c->arg[4], c->arg[5], c->arg[6], c->arg[7]);
> +}
> +
> +static void aml_nfw_read_arg(u8 *offset, u32 bit_width, acpi_integer *value)
> +{
> +	switch (bit_width) {
> +	case 8:
> +		*value = *(u8 *)offset;
> +		break;
> +	case 16:
> +		*value = *(u16 *)offset;
> +		break;
> +	case 32:
> +		*value = *(u32 *)offset;
> +		break;
> +	case 64:
> +		*value = *(u64 *)offset;
> +		break;
> +	}
> +}
> +
> +static void aml_nfw_write_arg(u8 *offset, u32 bit_width, acpi_integer *value)
> +{
> +	switch (bit_width) {
> +	case 8:
> +		*(u8 *) offset = *value;
> +		break;
> +	case 16:
> +		*(u16 *) offset = *value;
> +		break;
> +	case 32:
> +		*(u32 *) offset = *value;
> +		break;
> +	case 64:
> +		*(u64 *) offset = *value;
> +		break;
> +	}
> +}
> +
> +static acpi_status aml_nfw_handler(u32 function, acpi_physical_address address,
> +	u32 bit_width, acpi_integer *value, void *handler_context,
> +	void *region_context)
> +{
> +	struct ia64_nfw_context *context = handler_context;
> +	u8 *offset = (u8 *) context + address;
> +
> +	if (bit_width !=  8 && bit_width != 16 &&
> +	    bit_width != 32 && bit_width != 64)
> +		return AE_BAD_PARAMETER;
> +
> +	if (address + (bit_width >> 3) > sizeof(struct ia64_nfw_context))
> +		return AE_BAD_PARAMETER;
> +
> +	switch (function) {
> +	case ACPI_READ:
> +		if (address == offsetof(struct ia64_nfw_context, ret))
> +			aml_nfw_execute(context);
> +		aml_nfw_read_arg(offset, bit_width, value);
> +		break;
> +	case ACPI_WRITE:
> +		aml_nfw_write_arg(offset, bit_width, value);
> +		break;
> +	}
> +
> +	return AE_OK;
> +}
> +
> +static struct ia64_nfw_context global_context;
> +static int global_handler_registered;
> +
> +static int aml_nfw_add_global_handler(void)
> +{
> +	acpi_status status;
> +
> +	if (global_handler_registered)
> +		return 0;
> +
> +	status = acpi_install_address_space_handler(ACPI_ROOT_OBJECT,
> +		AML_NFW_SPACE, aml_nfw_handler, NULL, &global_context);
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	global_handler_registered = 1;
> +	printk(KERN_INFO "Global 0x%02X opregion handler registered\n",
> +		AML_NFW_SPACE);
> +	return 0;
> +}
> +
> +static int aml_nfw_remove_global_handler(void)
> +{
> +	acpi_status status;
> +
> +	if (!global_handler_registered)
> +		return 0;
> +
> +	status = acpi_remove_address_space_handler(ACPI_ROOT_OBJECT,
> +		AML_NFW_SPACE, aml_nfw_handler);
> +	if (ACPI_FAILURE(status))
> +		return -ENODEV;
> +
> +	global_handler_registered = 0;
> +	printk(KERN_INFO "Global 0x%02X opregion handler removed\n",
> +		AML_NFW_SPACE);
> +	return 0;
> +}
> +
> +static int aml_nfw_add(struct acpi_device *device)
> +{
> +	/*
> +	 * We would normally allocate a new context structure and install
> +	 * the address space handler for the specific device we found.
> +	 * But the HP-UX implementation shares a single global context
> +	 * and always puts the handler at the root, so we'll do the same.
> +	 */
> +	return aml_nfw_add_global_handler();
> +}
> +
> +static int aml_nfw_remove(struct acpi_device *device, int type)
> +{
> +	return aml_nfw_remove_global_handler();
> +}
> +
> +static const struct acpi_device_id aml_nfw_ids[] = {
> +	{"HPQ5001", 0},
> +	{"", 0}
> +};
> +
> +static struct acpi_driver acpi_aml_nfw_driver = {
> +	.name = "native firmware",
> +	.ids = aml_nfw_ids,
> +	.ops = {
> +		.add = aml_nfw_add,
> +		.remove = aml_nfw_remove,
> +		},
> +};
> +
> +static int __init aml_nfw_init(void)
> +{
> +	int result;
> +
> +	if (force_register)
> +		aml_nfw_add_global_handler();
> +
> +	result = acpi_bus_register_driver(&acpi_aml_nfw_driver);
> +	if (result < 0) {
> +		aml_nfw_remove_global_handler();
> +		return result;
> +	}
> +
> +	return 0;
> +}
> +
> +static void __exit aml_nfw_exit(void)
> +{
> +	acpi_bus_unregister_driver(&acpi_aml_nfw_driver);
> +	aml_nfw_remove_global_handler();
> +}
> +
> +module_init(aml_nfw_init);
> +module_exit(aml_nfw_exit);
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: driver to support ACPI AML calls to native firmware

[Bjorn Helgaas]

On Thursday 20 September 2007 02:20:23 pm Bjorn Helgaas wrote:
> Here's the driver with no exported symbols.

Ping!  Tony, can you let me know your plans for this patch?  I'd
like to get it into a distro release, and of course, it's best if
you accept it first.

Thanks,
  Bjorn

RE: driver to support ACPI AML calls to native firmware

[Luck, Tony]

> Ping!  Tony, can you let me know your plans for this patch?  I'd
> like to get it into a distro release, and of course, it's best if
> you accept it first.

I'll put it in soon.  My only vague concern is whether it should be more
accessible for other OEMs who want to do the SAL/ACPI sharing thing. But
I can wait and see whether we get a proliferation of OEM specific
drivers doing the same kind of thing.  If we do, then we'll look at how
to merge the common stuff.

-Tony

Re: driver to support ACPI AML calls to native firmware

[Bjorn Helgaas]

On Friday 05 October 2007 02:19:17 pm Luck, Tony wrote:
> > Ping!  Tony, can you let me know your plans for this patch?  I'd
> > like to get it into a distro release, and of course, it's best if
> > you accept it first.
> 
> I'll put it in soon.  My only vague concern is whether it should be more
> accessible for other OEMs who want to do the SAL/ACPI sharing thing. But
> I can wait and see whether we get a proliferation of OEM specific
> drivers doing the same kind of thing.  If we do, then we'll look at how
> to merge the common stuff.

OK, thanks.

Bjorn

[RFC] module to support ACPI AML calls to native firmware

[Bjorn Helgaas]

Here are a couple patches on which I'd like some feedback.

The basic idea is that ACPI AML methods sometimes need to do something
that is already implemented as a SAL interface.  ACPI doesn't provide a
way for an AML method to directly call the SAL interface.  That means
firmware writers sometimes have to implement things twice: once in SAL,
then again in AML, which leads to duplication and errors.

So HP dreamed up a way to reduce this duplication by connecting AML with
native firmware by using an ACPI Operation Region.  HP firmware uses this
for some hotplug functionality.  So far, we have not had a Linux driver
for this OpRegion, so we haven't been able to take advantage of this
hotplug functionality.

These patches implement this OpRegion driver.  The OpRegion is connected
to an HPQ5001 ACPI device, so it's only useful on HP systems.  Therefore,
I'd like to make it a module so non-HP systems are not penalized by the
4K or so of space the driver uses.

The driver needs to serialize firmware calls using the sal_lock.  That
lock is currently not exported, which prevents making the driver a
module.  We could easily rectify that by exporting sal_lock (this would
also enable making arch/ia64/kernel/esi.c a module), but there was some
resistance to that in the past.

So I'm interested in feedback on the following patches, which do not
export sal_lock, but rather export functions that can be used to call
SAL or other native firmware interfaces.

Bjorn

[patch 2/2] ia64: add driver for ACPI methods to call native firmware

[Bjorn Helgaas]

This driver for HPQ5001 devices installs a global ACPI OpRegion handler.
AML methods can use this OpRegion to call native firmware entry points.

This is required to support some hotplug functionality on HP Integrity
systems.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>

Index: w/arch/ia64/Kconfig
===================================================================
--- w.orig/arch/ia64/Kconfig	2007-09-11 16:07:23.000000000 -0600
+++ w/arch/ia64/Kconfig	2007-09-11 16:09:53.000000000 -0600
@@ -461,6 +461,19 @@
 	  firmware extensions, such as the ability to inject memory-errors
 	  for test-purposes.  If you're unsure, say N.
 
+config IA64_HP_AML_NFW
+	tristate "Support ACPI AML calls to native firmware"
+	help
+	  This driver installs a global ACPI Operation Region handler for
+	  region 0xA1.  AML methods can use this OpRegion to call arbitrary
+	  native firmware functions.  The driver installs the OpRegion
+	  handler if there is an HPQ5001 device or if the user supplies
+	  the "force" module parameter, e.g., with the "aml_nfw.force"
+	  kernel command line option.
+
+	  This driver is required for some hotplug functionality on
+	  HP Integrity systems.
+
 source "drivers/sn/Kconfig"
 
 config KEXEC
Index: w/arch/ia64/hp/common/Makefile
===================================================================
--- w.orig/arch/ia64/hp/common/Makefile	2007-09-11 16:07:23.000000000 -0600
+++ w/arch/ia64/hp/common/Makefile	2007-09-11 16:09:41.000000000 -0600
@@ -8,3 +8,4 @@
 obj-y := sba_iommu.o
 obj-$(CONFIG_IA64_HP_ZX1_SWIOTLB) += hwsw_iommu.o
 obj-$(CONFIG_IA64_GENERIC) += hwsw_iommu.o
+obj-$(CONFIG_IA64_HP_AML_NFW) += aml_nfw.o
Index: w/arch/ia64/hp/common/aml_nfw.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ w/arch/ia64/hp/common/aml_nfw.c	2007-09-11 16:09:41.000000000 -0600
@@ -0,0 +1,228 @@
+/*
+ * OpRegion handler to allow AML to call native firmware
+ *
+ * (c) Copyright 2007 Hewlett-Packard Development Company, L.P.
+ *	Bjorn Helgaas <bjorn.helgaas@hp.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This driver implements HP Open Source Review Board proposal 1842,
+ * which was approved on 9/20/2006.
+ *
+ * For technical documentation, see the HP SPPA Firmware EAS, Appendix F.
+ */
+
+#include <linux/module.h>
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <asm/sal.h>
+
+MODULE_AUTHOR("Bjorn Helgaas <bjorn.helgaas@hp.com>");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ACPI opregion handler for native firmware calls");
+
+static int force_register;
+module_param_named(force, force_register, bool, 0);
+MODULE_PARM_DESC(force, "Install opregion handler even without HPQ5001 device");
+
+#define AML_NFW_SPACE		0xA1
+
+struct ia64_pdesc {
+	void *ip;
+	void *gp;
+};
+
+/*
+ * N.B.  The layout of this structure is defined in the HP SPPA FW EAS, and
+ *	 the member offsets are embedded in AML methods.
+ */
+struct ia64_nfw_context {
+	u64 arg[8];
+	struct ia64_sal_retval ret;
+	u64 ip;
+	u64 gp;
+	u64 pad[2];
+};
+
+static void *virt_map(u64 address)
+{
+	if (address & (1UL << 63))
+		return (void *) (__IA64_UNCACHED_OFFSET | address);
+
+	return __va(address);
+}
+
+static void aml_nfw_execute(struct ia64_nfw_context *c)
+{
+	struct ia64_pdesc virt_entry;
+	ia64_sal_handler entry;
+
+	virt_entry.ip = virt_map(c->ip);
+	virt_entry.gp = virt_map(c->gp);
+
+	entry = (ia64_sal_handler) &virt_entry;
+
+	fw_call_lock(entry, &c->ret,
+			c->arg[0], c->arg[1], c->arg[2], c->arg[3],
+			c->arg[4], c->arg[5], c->arg[6], c->arg[7]);
+}
+
+static void aml_nfw_read_arg(u8 *offset, u32 bit_width, acpi_integer *value)
+{
+	switch (bit_width) {
+	case 8:
+		*value = *(u8 *)offset;
+		break;
+	case 16:
+		*value = *(u16 *)offset;
+		break;
+	case 32:
+		*value = *(u32 *)offset;
+		break;
+	case 64:
+		*value = *(u64 *)offset;
+		break;
+	}
+}
+
+static void aml_nfw_write_arg(u8 *offset, u32 bit_width, acpi_integer *value)
+{
+	switch (bit_width) {
+	case 8:
+		*(u8 *) offset = *value;
+		break;
+	case 16:
+		*(u16 *) offset = *value;
+		break;
+	case 32:
+		*(u32 *) offset = *value;
+		break;
+	case 64:
+		*(u64 *) offset = *value;
+		break;
+	}
+}
+
+static acpi_status aml_nfw_handler(u32 function, acpi_physical_address address,
+	u32 bit_width, acpi_integer *value, void *handler_context,
+	void *region_context)
+{
+	struct ia64_nfw_context *context = handler_context;
+	u8 *offset = (u8 *) context + address;
+
+	if (bit_width !=  8 && bit_width != 16 &&
+	    bit_width != 32 && bit_width != 64)
+		return AE_BAD_PARAMETER;
+
+	if (address + (bit_width >> 3) > sizeof(struct ia64_nfw_context))
+		return AE_BAD_PARAMETER;
+
+	switch (function) {
+	case ACPI_READ:
+		if (address == offsetof(struct ia64_nfw_context, ret))
+			aml_nfw_execute(context);
+		aml_nfw_read_arg(offset, bit_width, value);
+		break;
+	case ACPI_WRITE:
+		aml_nfw_write_arg(offset, bit_width, value);
+		break;
+	}
+
+	return AE_OK;
+}
+
+static struct ia64_nfw_context global_context;
+static int global_handler_registered;
+
+static int aml_nfw_add_global_handler(void)
+{
+	acpi_status status;
+
+	if (global_handler_registered)
+		return 0;
+
+	status = acpi_install_address_space_handler(ACPI_ROOT_OBJECT,
+		AML_NFW_SPACE, aml_nfw_handler, NULL, &global_context);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	global_handler_registered = 1;
+	printk(KERN_INFO "Global 0x%02X opregion handler registered\n",
+		AML_NFW_SPACE);
+	return 0;
+}
+
+static int aml_nfw_remove_global_handler(void)
+{
+	acpi_status status;
+
+	if (!global_handler_registered)
+		return 0;
+
+	status = acpi_remove_address_space_handler(ACPI_ROOT_OBJECT,
+		AML_NFW_SPACE, aml_nfw_handler);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	global_handler_registered = 0;
+	printk(KERN_INFO "Global 0x%02X opregion handler removed\n",
+		AML_NFW_SPACE);
+	return 0;
+}
+
+static int aml_nfw_add(struct acpi_device *device)
+{
+	/*
+	 * We would normally allocate a new context structure and install
+	 * the address space handler for the specific device we found.
+	 * But the HP-UX implementation shares a single global context
+	 * and always puts the handler at the root, so we'll do the same.
+	 */
+	return aml_nfw_add_global_handler();
+}
+
+static int aml_nfw_remove(struct acpi_device *device, int type)
+{
+	return aml_nfw_remove_global_handler();
+}
+
+static const struct acpi_device_id aml_nfw_ids[] = {
+	{"HPQ5001", 0},
+	{"", 0}
+};
+
+static struct acpi_driver acpi_aml_nfw_driver = {
+	.name = "native firmware",
+	.ids = aml_nfw_ids,
+	.ops = {
+		.add = aml_nfw_add,
+		.remove = aml_nfw_remove,
+		},
+};
+
+static int __init aml_nfw_init(void)
+{
+	int result;
+
+	if (force_register)
+		aml_nfw_add_global_handler();
+
+	result = acpi_bus_register_driver(&acpi_aml_nfw_driver);
+	if (result < 0) {
+		aml_nfw_remove_global_handler();
+		return result;
+	}
+
+	return 0;
+}
+
+static void __exit aml_nfw_exit(void)
+{
+	acpi_bus_unregister_driver(&acpi_aml_nfw_driver);
+	aml_nfw_remove_global_handler();
+}
+
+module_init(aml_nfw_init);
+module_exit(aml_nfw_exit);

Re: [patch 2/2] ia64: add driver for ACPI methods to call native firmware

[Matthew Garrett]

On Tue, Sep 11, 2007 at 05:16:46PM -0600, Bjorn Helgaas wrote:
> +config IA64_HP_AML_NFW
> +	tristate "Support ACPI AML calls to native firmware"

The description seems a bit generic for something that's HP specific?
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [patch 2/2] ia64: add driver for ACPI methods to call native firmware

[Kyle McMartin]

On Wed, Sep 12, 2007 at 09:56:51AM +0100, Matthew Garrett wrote:
> On Tue, Sep 11, 2007 at 05:16:46PM -0600, Bjorn Helgaas wrote:
> > +config IA64_HP_AML_NFW
> > +	tristate "Support ACPI AML calls to native firmware"
> 
> The description seems a bit generic for something that's HP specific?
>

It's within arch/ia64/Kconfig, so it will only show up on IA64 boxes...
It's possible that Altix or Intel IA64 boxes will want to make SAL calls
from ACPI, so it looks ok...

--Kyle

Re: [patch 2/2] ia64: add driver for ACPI methods to call native firmware

[Bjorn Helgaas]

On Wednesday 12 September 2007 02:56:51 am Matthew Garrett wrote:
> On Tue, Sep 11, 2007 at 05:16:46PM -0600, Bjorn Helgaas wrote:
> > +config IA64_HP_AML_NFW
> > +	tristate "Support ACPI AML calls to native firmware"
> 
> The description seems a bit generic for something that's HP specific?

Thanks, I'll wordsmith the description a bit.  There's actually nothing
in the implementation that prevents this from working on non-HP firmware.  

I really want feedback on the best approach of:

  1.  Always build the driver static, accept the additional 4600 bytes
      in everybody's image, not export anything.

  2.  Allow building driver as a module, export sal_lock.  This would
      also enable building arch/ia64/kernel/esi.c as a module.

  3.  Allow building driver as a module, restructure SAL_CALL so we
      don't have to export sal_lock, but we do export fw_call_lock()
      (as done in these patches).  This isn't quite sufficient to
      enable building esi.c as a module.

#1 would be easiest, of course, but I'm not happy about adding stuff
that is only used on HP hardware.  #2 would be simple, but exporting
sal_lock has been resisted in the past.

Bjorn