WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [PATCH] linux/acpi: adjust extcntl code so that CONFIG_ACPI_

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] linux/acpi: adjust extcntl code so that CONFIG_ACPI_PROCESSOR=m is possible again
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 23 Jul 2008 13:32:21 +0100
Delivery-date: Wed, 23 Jul 2008 05:32:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
This is done by inverting the calling direction for registering the
extcntl_ops structure, similar to arch_acpi_processor_init_pdc().

As usual, written and tested on 2.6.26 and made apply to the 2.6.18
tree without further testing.

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>

Index: head-2008-07-21/arch/i386/kernel/acpi/processor_extcntl_xen.c
===================================================================
--- head-2008-07-21.orig/arch/i386/kernel/acpi/processor_extcntl_xen.c  
2008-07-22 17:19:29.000000000 +0200
+++ head-2008-07-21/arch/i386/kernel/acpi/processor_extcntl_xen.c       
2008-07-22 15:58:45.000000000 +0200
@@ -221,7 +221,7 @@ static struct processor_extcntl_ops xen_
        .hotplug                = xen_hotplug_notifier,
 };
 
-static int __cpuinit xen_init_processor_extcntl(void)
+void arch_acpi_processor_init_extcntl(const struct processor_extcntl_ops **ops)
 {
        if (xen_processor_pmbits & XEN_PROCESSOR_PM_CX)
                xen_extcntl_ops.pm_ops[PM_TYPE_IDLE] = xen_cx_notifier;
@@ -230,6 +230,6 @@ static int __cpuinit xen_init_processor_
        if (xen_processor_pmbits & XEN_PROCESSOR_PM_TX)
                xen_extcntl_ops.pm_ops[PM_TYPE_THR] = xen_tx_notifier;
 
-       return processor_register_extcntl(&xen_extcntl_ops);
+       *ops = &xen_extcntl_ops;
 }
-core_initcall(xen_init_processor_extcntl);
+EXPORT_SYMBOL(arch_acpi_processor_init_extcntl);
Index: head-2008-07-21/drivers/acpi/Kconfig
===================================================================
--- head-2008-07-21.orig/drivers/acpi/Kconfig   2008-07-22 09:14:58.000000000 
+0200
+++ head-2008-07-21/drivers/acpi/Kconfig        2008-07-21 14:14:13.000000000 
+0200
@@ -371,7 +371,6 @@ config ACPI_PV_SLEEP
 config PROCESSOR_EXTERNAL_CONTROL
        bool
        depends on X86 && XEN
-       select ACPI_PROCESSOR
        default y
 endif  # ACPI
 
Index: head-2008-07-21/drivers/acpi/processor_extcntl.c
===================================================================
--- head-2008-07-21.orig/drivers/acpi/processor_extcntl.c       2008-07-22 
17:19:29.000000000 +0200
+++ head-2008-07-21/drivers/acpi/processor_extcntl.c    2008-07-22 
17:20:52.000000000 +0200
@@ -36,7 +36,7 @@ static int processor_extcntl_get_perform
  * External processor control logic may register with its own set of
  * ops to get ACPI related notification. One example is like VMM.
  */
-struct processor_extcntl_ops *processor_extcntl_ops;
+const struct processor_extcntl_ops *processor_extcntl_ops;
 EXPORT_SYMBOL(processor_extcntl_ops);
 
 static int processor_notify_smm(void)
@@ -105,47 +105,13 @@ int processor_notify_external(struct acp
 }
 
 /*
- * External control logic can decide to grab full or part of physical
- * processor control bits. Take a VMM for example, physical processors
- * are owned by VMM and thus existence information like hotplug is
- * always required to be notified to VMM. Similar is processor idle
- * state which is also necessarily controlled by VMM. But for other
- * control bits like performance/throttle states, VMM may choose to
- * control or not upon its own policy.
- *
- * Such ownership is unlikely to be switched in the fly, and thus
- * not sure unregister interface is required or not. Being same reason,
- * lock is not forced now.
- */
-int processor_register_extcntl(struct processor_extcntl_ops *ops)
-{
-       if (!ops)
-               return -EINVAL;
-
-       if (processor_extcntl_ops &&
-               (processor_extcntl_ops != ops))
-               return -EBUSY;
-
-       processor_extcntl_ops = ops;
-       return 0;
-}
-
-int processor_unregister_extcntl(struct processor_extcntl_ops *ops)
-{
-       if (processor_extcntl_ops == ops)
-               processor_extcntl_ops = NULL;
-
-       return 0;
-}
-
-/*
  * This is called from ACPI processor init, and targeted to hold
  * some tricky housekeeping jobs to satisfy external control model.
  * For example, we may put dependency parse stub here for idle
  * and performance state. Those information may be not available
  * if splitting from dom0 control logic like cpufreq driver.
  */
-int processor_extcntl_init(struct acpi_processor *pr)
+int __cpuinit processor_extcntl_init(struct acpi_processor *pr)
 {
        /* parse cstate dependency information */
        if (processor_pm_external())
@@ -155,6 +121,18 @@ int processor_extcntl_init(struct acpi_p
        if (processor_pmperf_external())
                processor_extcntl_get_performance(pr);
 
+       /*
+        * External control logic can decide to grab full or part of physical
+        * processor control bits. Take a VMM for example, physical processors
+        * are owned by VMM and thus existence information like hotplug is
+        * always required to be notified to VMM. Similar is processor idle
+        * state which is also necessarily controlled by VMM. But for other
+        * control bits like performance/throttle states, VMM may choose to
+        * control or not upon its own policy.
+        */
+       if (!processor_extcntl_ops)
+               arch_acpi_processor_init_extcntl(&processor_extcntl_ops);
+
        return 0;
 }
 
Index: head-2008-07-21/include/acpi/processor.h
===================================================================
--- head-2008-07-21.orig/include/acpi/processor.h       2008-07-22 
17:19:29.000000000 +0200
+++ head-2008-07-21/include/acpi/processor.h    2008-07-22 16:01:43.000000000 
+0200
@@ -323,7 +323,7 @@ struct processor_extcntl_ops {
        /* Notify physical processor status to external control logic */
        int (*hotplug)(struct acpi_processor *pr, int event);
 };
-extern struct processor_extcntl_ops *processor_extcntl_ops;
+extern const struct processor_extcntl_ops *processor_extcntl_ops;
 
 static inline int processor_cntl_external(void)
 {
@@ -350,11 +350,10 @@ static inline int processor_pmthr_extern
 
 extern int processor_notify_external(struct acpi_processor *pr,
                        int event, int type);
-extern int processor_register_extcntl(struct processor_extcntl_ops *ops);
-extern int processor_unregister_extcntl(struct processor_extcntl_ops *ops);
 extern int processor_extcntl_init(struct acpi_processor *pr);
 extern int acpi_processor_get_performance_info(struct acpi_processor *pr);
 extern int acpi_processor_get_psd(struct acpi_processor *pr);
+void arch_acpi_processor_init_extcntl(const struct processor_extcntl_ops **);
 #else
 static inline int processor_cntl_external(void) {return 0;}
 static inline int processor_pm_external(void) {return 0;}



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH] linux/acpi: adjust extcntl code so that CONFIG_ACPI_PROCESSOR=m is possible again, Jan Beulich <=