[PATCH 00/10] ACPI: remove several initcalls

[PATCH 00/10] ACPI: remove several initcalls

[Bjorn Helgaas]

These patches change several ACPI initcalls to explicit calls.
This removes dependencies on link order and makes the code
clearer.

Comments welcome.

---

Bjorn Helgaas (10):
      ACPI: tidy up makefile
      ACPI: call acpi_wakeup_device_init() explicitly rather than as initcall
      ACPI: call acpi_sleep_proc_init() explicitly rather than as initcall
      ACPI: call init_acpi_device_notify() explicitly rather than as initcall
      ACPI: call acpi_debug_init() explicitly rather than as initcall
      ACPI: call acpi_system_init() explicitly rather than as initcall
      ACPI: call acpi_power_init() explicitly rather than as initcall
      ACPI: call acpi_ec_init() explicitly rather than as initcall
      ACPI: call acpi_scan_init() explicitly rather than as initcall
      ACPI: skip DMI power state check when ACPI disabled


 drivers/acpi/Makefile   |    8 ++------
 drivers/acpi/bus.c      |   13 +++++++++++++
 drivers/acpi/debug.c    |   14 ++++++--------
 drivers/acpi/ec.c       |    7 +------
 drivers/acpi/glue.c     |    6 +-----
 drivers/acpi/internal.h |   21 ++++++++++++++++++++-
 drivers/acpi/power.c    |    8 +-------
 drivers/acpi/proc.c     |    7 +------
 drivers/acpi/scan.c     |    9 +--------
 drivers/acpi/system.c   |    9 ++-------
 drivers/acpi/wakeup.c   |    7 +------
 11 files changed, 49 insertions(+), 60 deletions(-)

[PATCH 01/10] ACPI: skip DMI power state check when ACPI disabled

[Bjorn Helgaas]

This patch makes acpi_init() exit early when ACPI is disabled.
This skips a DMI check that affects ACPI power management.   The
DMI check prints a notice that is misleading when ACPI is disabled.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
---
 drivers/acpi/bus.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 2e90410..bdeed39 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -869,6 +869,10 @@ static int __init acpi_init(void)
 		}
 	} else
 		disable_acpi();
+
+	if (acpi_disabled)
+		return result;
+
 	/*
 	 * If the laptop falls into the DMI check table, the power state check
 	 * will be disabled in the course of device power transistion.

[PATCH 02/10] ACPI: call acpi_scan_init() explicitly rather than as initcall

[Bjorn Helgaas]

This patch makes acpi_init() call acpi_scan_init() directly.

Previously, both acpi_init() and acpi_scan_init() were subsys_initcalls,
and acpi_init() was called first based on the link order from the
makefile (bus.o before scan.o).

acpi_scan_init() registers the ACPI bus type, creates the root device,
and enumerates fixed-feature and namespace devices.  All of this must
be done after acpi_init(), and it's better to call acpi_scan_init()
explicitly rather than rely on the link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
---
 drivers/acpi/bus.c      |    2 ++
 drivers/acpi/internal.h |    2 ++
 drivers/acpi/scan.c     |    9 +--------
 3 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index bdeed39..cdd11fd 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -878,6 +878,8 @@ static int __init acpi_init(void)
 	 * will be disabled in the course of device power transistion.
 	 */
 	dmi_check_system(power_nocheck_dmi_table);
+
+	acpi_scan_init();
 	return result;
 }
 
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 4aee4a2..28042c0 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -1,5 +1,7 @@
 /* For use by Linux/ACPI infrastructure, not drivers */
 
+int acpi_scan_init(void);
+
 /* --------------------------------------------------------------------------
                                   Power Resource
    -------------------------------------------------------------------------- */
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 467e9d0..b7308ef 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1514,16 +1514,11 @@ static int acpi_bus_scan_fixed(struct acpi_device *root)
 	return result;
 }
 
-
-static int __init acpi_scan_init(void)
+int __init acpi_scan_init(void)
 {
 	int result;
 	struct acpi_bus_ops ops;
 
-
-	if (acpi_disabled)
-		return 0;
-
 	memset(&ops, 0, sizeof(ops));
 	ops.acpi_op_add = 1;
 	ops.acpi_op_start = 1;
@@ -1556,5 +1551,3 @@ static int __init acpi_scan_init(void)
       Done:
 	return result;
 }
-
-subsys_initcall(acpi_scan_init);

[PATCH 03/10] ACPI: call acpi_ec_init() explicitly rather than as initcall

[Bjorn Helgaas]

This patch makes acpi_init() call acpi_ec_init() directly.
Previously, both were subsys_initcalls.  acpi_ec_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Alexey Starikovskiy <astarikovskiy@suse.de>
---
 drivers/acpi/bus.c      |    1 +
 drivers/acpi/ec.c       |    7 +------
 drivers/acpi/internal.h |    1 +
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index cdd11fd..9ca6837 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -880,6 +880,7 @@ static int __init acpi_init(void)
 	dmi_check_system(power_nocheck_dmi_table);
 
 	acpi_scan_init();
+	acpi_ec_init();
 	return result;
 }
 
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 2fe1506..bf88f18 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -1069,13 +1069,10 @@ static struct acpi_driver acpi_ec_driver = {
 		},
 };
 
-static int __init acpi_ec_init(void)
+int __init acpi_ec_init(void)
 {
 	int result = 0;
 
-	if (acpi_disabled)
-		return 0;
-
 	acpi_ec_dir = proc_mkdir(ACPI_EC_CLASS, acpi_root_dir);
 	if (!acpi_ec_dir)
 		return -ENODEV;
@@ -1090,8 +1087,6 @@ static int __init acpi_ec_init(void)
 	return result;
 }
 
-subsys_initcall(acpi_ec_init);
-
 /* EC driver currently not unloadable */
 #if 0
 static void __exit acpi_ec_exit(void)
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 28042c0..fad8e38 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -17,6 +17,7 @@ extern int acpi_power_nocheck;
 /* --------------------------------------------------------------------------
                                   Embedded Controller
    -------------------------------------------------------------------------- */
+int acpi_ec_init(void);
 int acpi_ec_ecdt_probe(void);
 int acpi_boot_ec_enable(void);
 

[PATCH 04/10] ACPI: call acpi_power_init() explicitly rather than as initcall

[Bjorn Helgaas]

This patch makes acpi_init() call acpi_power_init() directly.
Previously, both were subsys_initcalls.  acpi_power_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Zhao Yakui <yakui.zhao@intel.com>
---
 drivers/acpi/bus.c      |    1 +
 drivers/acpi/internal.h |    2 +-
 drivers/acpi/power.c    |    8 +-------
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 9ca6837..946610f 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -881,6 +881,7 @@ static int __init acpi_init(void)
 
 	acpi_scan_init();
 	acpi_ec_init();
+	acpi_power_init();
 	return result;
 }
 
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index fad8e38..a8178ad 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -5,7 +5,7 @@ int acpi_scan_init(void);
 /* --------------------------------------------------------------------------
                                   Power Resource
    -------------------------------------------------------------------------- */
-
+int acpi_power_init(void);
 int acpi_device_sleep_wake(struct acpi_device *dev,
                            int enable, int sleep_state, int dev_state);
 int acpi_enable_wakeup_device_power(struct acpi_device *dev, int sleep_state);
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index c926e7d..11968ba 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -773,14 +773,10 @@ static int acpi_power_resume(struct acpi_device *device)
 	return 0;
 }
 
-static int __init acpi_power_init(void)
+int __init acpi_power_init(void)
 {
 	int result = 0;
 
-
-	if (acpi_disabled)
-		return 0;
-
 	INIT_LIST_HEAD(&acpi_power_resource_list);
 
 	acpi_power_dir = proc_mkdir(ACPI_POWER_CLASS, acpi_root_dir);
@@ -795,5 +791,3 @@ static int __init acpi_power_init(void)
 
 	return 0;
 }
-
-subsys_initcall(acpi_power_init);

[PATCH 05/10] ACPI: call acpi_system_init() explicitly rather than as initcall

[Bjorn Helgaas]

This patch makes acpi_init() call acpi_system_init() directly.
Previously, both were subsys_initcalls.  acpi_system_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
---
 drivers/acpi/bus.c      |    1 +
 drivers/acpi/internal.h |    1 +
 drivers/acpi/system.c   |    9 ++-------
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 946610f..c133072 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -882,6 +882,7 @@ static int __init acpi_init(void)
 	acpi_scan_init();
 	acpi_ec_init();
 	acpi_power_init();
+	acpi_system_init();
 	return result;
 }
 
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index a8178ad..4a35f6e 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -1,6 +1,7 @@
 /* For use by Linux/ACPI infrastructure, not drivers */
 
 int acpi_scan_init(void);
+int acpi_system_init(void);
 
 /* --------------------------------------------------------------------------
                                   Power Resource
diff --git a/drivers/acpi/system.c b/drivers/acpi/system.c
index 391d035..3b88981 100644
--- a/drivers/acpi/system.c
+++ b/drivers/acpi/system.c
@@ -571,12 +571,9 @@ static int acpi_system_procfs_init(void)
 }
 #endif
 
-static int __init acpi_system_init(void)
+int __init acpi_system_init(void)
 {
-	int result = 0;
-
-	if (acpi_disabled)
-		return 0;
+	int result;
 
 	result = acpi_system_procfs_init();
 	if (result)
@@ -586,5 +583,3 @@ static int __init acpi_system_init(void)
 
 	return result;
 }
-
-subsys_initcall(acpi_system_init);

[PATCH 06/10] ACPI: call acpi_debug_init() explicitly rather than as initcall

[Bjorn Helgaas]

This patch makes acpi_init() call acpi_debug_init() directly.
Previously, both were subsys_initcalls.  acpi_debug_init()
must happen after acpi_init(), and it's better to call it
explicitly rather than rely on link ordering.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
---
 drivers/acpi/bus.c      |    1 +
 drivers/acpi/debug.c    |   14 ++++++--------
 drivers/acpi/internal.h |    6 ++++++
 3 files changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index c133072..f32cfd6 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -883,6 +883,7 @@ static int __init acpi_init(void)
 	acpi_ec_init();
 	acpi_power_init();
 	acpi_system_init();
+	acpi_debug_init();
 	return result;
 }
 
diff --git a/drivers/acpi/debug.c b/drivers/acpi/debug.c
index 20223cb..9cb189f 100644
--- a/drivers/acpi/debug.c
+++ b/drivers/acpi/debug.c
@@ -297,17 +297,15 @@ acpi_system_write_debug(struct file *file,
 
 	return count;
 }
+#endif
 
-static int __init acpi_debug_init(void)
+int __init acpi_debug_init(void)
 {
+#ifdef CONFIG_ACPI_PROCFS
 	struct proc_dir_entry *entry;
 	int error = 0;
 	char *name;
 
-
-	if (acpi_disabled)
-		return 0;
-
 	/* 'debug_layer' [R/W] */
 	name = ACPI_SYSTEM_FILE_DEBUG_LAYER;
 	entry =
@@ -338,7 +336,7 @@ static int __init acpi_debug_init(void)
 	remove_proc_entry(ACPI_SYSTEM_FILE_DEBUG_LAYER, acpi_root_dir);
 	error = -ENODEV;
 	goto Done;
-}
-
-subsys_initcall(acpi_debug_init);
+#else
+	return 0;
 #endif
+}
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 4a35f6e..44b8402 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -3,6 +3,12 @@
 int acpi_scan_init(void);
 int acpi_system_init(void);
 
+#ifdef CONFIG_ACPI_DEBUG
+int acpi_debug_init(void);
+#else
+static inline int acpi_debug_init(void) { return 0; }
+#endif
+
 /* --------------------------------------------------------------------------
                                   Power Resource
    -------------------------------------------------------------------------- */

[PATCH 07/10] ACPI: call init_acpi_device_notify() explicitly rather than as initcall

[Bjorn Helgaas]

This patch makes acpi_init() call init_acpi_device_notify() directly.
Previously, init_acpi_device_notify() was an arch_initcall (sequence 3),
so it was called before acpi_init() (a subsys_initcall at sequence 4).

init_acpi_device_notify() sets the platform_notify and
platform_notify_remove function pointers.  These pointers
are not used until acpi_init() enumerates ACPI devices in
this path:

    acpi_init()
	    acpi_scan_init()
		acpi_bus_scan()
		    acpi_add_single_object()
			acpi_device_register()
			    device_add()
				<use platform_notify>

So it is sufficient to have acpi_init() call init_acpi_device_notify()
directly before it enumerates devices.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
---
 drivers/acpi/bus.c      |    1 +
 drivers/acpi/glue.c     |    6 +-----
 drivers/acpi/internal.h |    1 +
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index f32cfd6..db9eca8 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -855,6 +855,7 @@ static int __init acpi_init(void)
 		acpi_kobj = NULL;
 	}
 
+	init_acpi_device_notify();
 	result = acpi_bus_init();
 
 	if (!result) {
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 5479b9f..8bd2c2a 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -286,10 +286,8 @@ static int acpi_platform_notify_remove(struct device *dev)
 	return 0;
 }
 
-static int __init init_acpi_device_notify(void)
+int __init init_acpi_device_notify(void)
 {
-	if (acpi_disabled)
-		return 0;
 	if (platform_notify || platform_notify_remove) {
 		printk(KERN_ERR PREFIX "Can't use platform_notify\n");
 		return 0;
@@ -298,5 +296,3 @@ static int __init init_acpi_device_notify(void)
 	platform_notify_remove = acpi_platform_notify_remove;
 	return 0;
 }
-
-arch_initcall(init_acpi_device_notify);
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 44b8402..8a45dd8 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -1,5 +1,6 @@
 /* For use by Linux/ACPI infrastructure, not drivers */
 
+int init_acpi_device_notify(void);
 int acpi_scan_init(void);
 int acpi_system_init(void);
 

[PATCH 08/10] ACPI: call acpi_sleep_proc_init() explicitly rather than as initcall

[Bjorn Helgaas]

This patch makes acpi_init() call acpi_sleep_proc_init() directly.
Previously, acpi_sleep_proc_init() was a late_initcall (sequence 7),
apparently to make sure that the /proc hierarchy already exists:

    2003/02/13 12:38:03-06:00 mochel
    acpi sleep: demote sleep proc file creation.

    - Make acpi_sleep_proc_init() a late_initcall(), and not called from
      acpi_sleep_init(). This guarantees that the acpi proc hierarchy is at
      least there when we create the dang file.

This should no longer be an issue because acpi_bus_init() (called early
in acpi_init()) creates acpi_root_dir (/proc/acpi).

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
---
 drivers/acpi/bus.c      |    1 +
 drivers/acpi/internal.h |    6 ++++++
 drivers/acpi/proc.c     |    7 +------
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index db9eca8..a812e84 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -885,6 +885,7 @@ static int __init acpi_init(void)
 	acpi_power_init();
 	acpi_system_init();
 	acpi_debug_init();
+	acpi_sleep_proc_init();
 	return result;
 }
 
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 8a45dd8..8870e5f 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -33,3 +33,9 @@ int acpi_boot_ec_enable(void);
                                   Suspend/Resume
   -------------------------------------------------------------------------- */
 extern int acpi_sleep_init(void);
+
+#ifdef CONFIG_ACPI_SLEEP
+int acpi_sleep_proc_init(void);
+#else
+static inline int acpi_sleep_proc_init(void) { return 0; }
+#endif
diff --git a/drivers/acpi/proc.c b/drivers/acpi/proc.c
index 428c911..05dfdc9 100644
--- a/drivers/acpi/proc.c
+++ b/drivers/acpi/proc.c
@@ -496,11 +496,8 @@ static u32 rtc_handler(void *context)
 }
 #endif				/* HAVE_ACPI_LEGACY_ALARM */
 
-static int __init acpi_sleep_proc_init(void)
+int __init acpi_sleep_proc_init(void)
 {
-	if (acpi_disabled)
-		return 0;
-
 #ifdef	CONFIG_ACPI_PROCFS
 	/* 'sleep' [R/W] */
 	proc_create("sleep", S_IFREG | S_IRUGO | S_IWUSR,
@@ -527,5 +524,3 @@ static int __init acpi_sleep_proc_init(void)
 
 	return 0;
 }
-
-late_initcall(acpi_sleep_proc_init);

[PATCH 09/10] ACPI: call acpi_wakeup_device_init() explicitly rather than as initcall

[Bjorn Helgaas]

This patch makes acpi_init() call acpi_wakeup_device_init() directly.
Previously, acpi_wakeup_device_init() was a late_initcall (sequence 7).

acpi_wakeup_device_init() depends on acpi_wakeup_device_list, which
is populated when ACPI devices are enumerated by acpi_init() ->
acpi_scan_init().  Using late_initcall is certainly enough to make
sure acpi_wakeup_device_list is populated, but it is more than
necessary.  We can just as easily call acpi_wakeup_device_init()
directly from acpi_init(), which avoids the initcall magic.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
CC: Li Shaohua <shaohua.li@intel.com>
---
 drivers/acpi/bus.c      |    1 +
 drivers/acpi/internal.h |    2 ++
 drivers/acpi/wakeup.c   |    7 +------
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index a812e84..7fe0945 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -886,6 +886,7 @@ static int __init acpi_init(void)
 	acpi_system_init();
 	acpi_debug_init();
 	acpi_sleep_proc_init();
+	acpi_wakeup_device_init();
 	return result;
 }
 
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 8870e5f..11a69b5 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -22,6 +22,8 @@ int acpi_power_get_inferred_state(struct acpi_device *device);
 int acpi_power_transition(struct acpi_device *device, int state);
 extern int acpi_power_nocheck;
 
+int acpi_wakeup_device_init(void);
+
 /* --------------------------------------------------------------------------
                                   Embedded Controller
    -------------------------------------------------------------------------- */
diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c
index 3f29fd5..5aee8c2 100644
--- a/drivers/acpi/wakeup.c
+++ b/drivers/acpi/wakeup.c
@@ -138,13 +138,10 @@ void acpi_disable_wakeup_device(u8 sleep_state)
 	spin_unlock(&acpi_device_lock);
 }
 
-static int __init acpi_wakeup_device_init(void)
+int __init acpi_wakeup_device_init(void)
 {
 	struct list_head *node, *next;
 
-	if (acpi_disabled)
-		return 0;
-
 	spin_lock(&acpi_device_lock);
 	list_for_each_safe(node, next, &acpi_wakeup_device_list) {
 		struct acpi_device *dev = container_of(node,
@@ -165,5 +162,3 @@ static int __init acpi_wakeup_device_init(void)
 	spin_unlock(&acpi_device_lock);
 	return 0;
 }
-
-late_initcall(acpi_wakeup_device_init);

[PATCH 10/10] ACPI: tidy up makefile

[Bjorn Helgaas]

This patch removes the suggestion that ec.o link order is important,
because it doesn't matter since acpi_ec_init() is no longer an initcall.
And it puts together most of the core modules that are not configurable.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
---
 drivers/acpi/Makefile |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b130ea0..61675e2 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -32,10 +32,8 @@ ifdef CONFIG_CPU_FREQ
 processor-objs	+= processor_perflib.o
 endif
 
-obj-y				+= bus.o glue.o
-obj-y				+= scan.o
-# Keep EC driver first. Initialization of others depend on it.
-obj-y				+= ec.o
+obj-y				+= bus.o glue.o scan.o ec.o \
+					power.o system.o event.o
 obj-$(CONFIG_ACPI_AC) 		+= ac.o
 obj-$(CONFIG_ACPI_BATTERY)	+= battery.o
 obj-$(CONFIG_ACPI_BUTTON)	+= button.o
@@ -51,8 +49,6 @@ obj-$(CONFIG_ACPI_PCI_SLOT)	+= pci_slot.o
 obj-$(CONFIG_ACPI_PROCESSOR)	+= processor.o
 obj-$(CONFIG_ACPI_CONTAINER)	+= container.o
 obj-$(CONFIG_ACPI_THERMAL)	+= thermal.o
-obj-y				+= power.o
-obj-y				+= system.o event.o
 obj-$(CONFIG_ACPI_DEBUG)	+= debug.o
 obj-$(CONFIG_ACPI_NUMA)		+= numa.o
 obj-$(CONFIG_ACPI_HOTPLUG_MEMORY)	+= acpi_memhotplug.o

Re: [PATCH 06/10] ACPI: call acpi_debug_init() explicitly rather than as initcall

[Yinghai Lu]

On Tue, Mar 24, 2009 at 3:50 PM, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> This patch makes acpi_init() call acpi_debug_init() directly.
> Previously, both were subsys_initcalls.  acpi_debug_init()
> must happen after acpi_init(), and it's better to call it
> explicitly rather than rely on link ordering.
>
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> ---
>  drivers/acpi/bus.c      |    1 +
>  drivers/acpi/debug.c    |   14 ++++++--------
>  drivers/acpi/internal.h |    6 ++++++
>  3 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index c133072..f32cfd6 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -883,6 +883,7 @@ static int __init acpi_init(void)
>        acpi_ec_init();
>        acpi_power_init();
>        acpi_system_init();
> +       acpi_debug_init();
>        return result;
>  }
>
> diff --git a/drivers/acpi/debug.c b/drivers/acpi/debug.c
> index 20223cb..9cb189f 100644
> --- a/drivers/acpi/debug.c
> +++ b/drivers/acpi/debug.c
> @@ -297,17 +297,15 @@ acpi_system_write_debug(struct file *file,
>
>        return count;
>  }
> +#endif
>
> -static int __init acpi_debug_init(void)
> +int __init acpi_debug_init(void)
>  {
> +#ifdef CONFIG_ACPI_PROCFS
>        struct proc_dir_entry *entry;
>        int error = 0;
>        char *name;
>
> -
> -       if (acpi_disabled)
> -               return 0;
> -
>        /* 'debug_layer' [R/W] */
>        name = ACPI_SYSTEM_FILE_DEBUG_LAYER;
>        entry =
> @@ -338,7 +336,7 @@ static int __init acpi_debug_init(void)
>        remove_proc_entry(ACPI_SYSTEM_FILE_DEBUG_LAYER, acpi_root_dir);
>        error = -ENODEV;
>        goto Done;
> -}
> -
> -subsys_initcall(acpi_debug_init);
> +#else
> +       return 0;
>  #endif
> +}
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 4a35f6e..44b8402 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -3,6 +3,12 @@
>  int acpi_scan_init(void);
>  int acpi_system_init(void);
>
> +#ifdef CONFIG_ACPI_DEBUG

==> #if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS)

YH
> +int acpi_debug_init(void);
> +#else
> +static inline int acpi_debug_init(void) { return 0; }
> +#endif
> +
>  /* --------------------------------------------------------------------------
>                                   Power Resource
>    -------------------------------------------------------------------------- */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/10] ACPI: call acpi_debug_init() explicitly rather than as initcall

[Bjorn Helgaas]

On Tuesday 24 March 2009 05:08:12 pm Yinghai Lu wrote:
> On Tue, Mar 24, 2009 at 3:50 PM, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> > This patch makes acpi_init() call acpi_debug_init() directly.
> > Previously, both were subsys_initcalls.  acpi_debug_init()
> > must happen after acpi_init(), and it's better to call it
> > explicitly rather than rely on link ordering.
> >
> > Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > ---
> >  drivers/acpi/bus.c      |    1 +
> >  drivers/acpi/debug.c    |   14 ++++++--------
> >  drivers/acpi/internal.h |    6 ++++++
> >  3 files changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> > index c133072..f32cfd6 100644
> > --- a/drivers/acpi/bus.c
> > +++ b/drivers/acpi/bus.c
> > @@ -883,6 +883,7 @@ static int __init acpi_init(void)
> >        acpi_ec_init();
> >        acpi_power_init();
> >        acpi_system_init();
> > +       acpi_debug_init();
> >        return result;
> >  }
> >
> > diff --git a/drivers/acpi/debug.c b/drivers/acpi/debug.c
> > index 20223cb..9cb189f 100644
> > --- a/drivers/acpi/debug.c
> > +++ b/drivers/acpi/debug.c
> > @@ -297,17 +297,15 @@ acpi_system_write_debug(struct file *file,
> >
> >        return count;
> >  }
> > +#endif
> >
> > -static int __init acpi_debug_init(void)
> > +int __init acpi_debug_init(void)
> >  {
> > +#ifdef CONFIG_ACPI_PROCFS
> >        struct proc_dir_entry *entry;
> >        int error = 0;
> >        char *name;
> >
> > -
> > -       if (acpi_disabled)
> > -               return 0;
> > -
> >        /* 'debug_layer' [R/W] */
> >        name = ACPI_SYSTEM_FILE_DEBUG_LAYER;
> >        entry =
> > @@ -338,7 +336,7 @@ static int __init acpi_debug_init(void)
> >        remove_proc_entry(ACPI_SYSTEM_FILE_DEBUG_LAYER, acpi_root_dir);
> >        error = -ENODEV;
> >        goto Done;
> > -}
> > -
> > -subsys_initcall(acpi_debug_init);
> > +#else
> > +       return 0;
> >  #endif
> > +}
> > diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> > index 4a35f6e..44b8402 100644
> > --- a/drivers/acpi/internal.h
> > +++ b/drivers/acpi/internal.h
> > @@ -3,6 +3,12 @@
> >  int acpi_scan_init(void);
> >  int acpi_system_init(void);
> >
> > +#ifdef CONFIG_ACPI_DEBUG
> 
> ==> #if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS)

I could do that, and leave the #ifdefs in debug.c as they were,
but I thought it was cleaner to make it so that if we compile debug.c
(i.e., CONFIG_ACPI_DEBUG=y), it always provides acpi_debug_init().

I moved the #ifdefs in debug.c so that acpi_debug_init() is a no-op
if CONFIG_ACPI_PROCFS=n.

So I think my patch already addressed your concern, but let me
know if not.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 06/10] ACPI: call acpi_debug_init() explicitly rather than as initcall

[Yinghai Lu]

Bjorn Helgaas wrote:
> On Tuesday 24 March 2009 05:08:12 pm Yinghai Lu wrote:
>> On Tue, Mar 24, 2009 at 3:50 PM, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>>> This patch makes acpi_init() call acpi_debug_init() directly.
>>> Previously, both were subsys_initcalls.  acpi_debug_init()
>>> must happen after acpi_init(), and it's better to call it
>>> explicitly rather than rely on link ordering.
>>>
>>> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>>> ---
>>>  drivers/acpi/bus.c      |    1 +
>>>  drivers/acpi/debug.c    |   14 ++++++--------
>>>  drivers/acpi/internal.h |    6 ++++++
>>>  3 files changed, 13 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>>> index c133072..f32cfd6 100644
>>> --- a/drivers/acpi/bus.c
>>> +++ b/drivers/acpi/bus.c
>>> @@ -883,6 +883,7 @@ static int __init acpi_init(void)
>>>        acpi_ec_init();
>>>        acpi_power_init();
>>>        acpi_system_init();
>>> +       acpi_debug_init();
>>>        return result;
>>>  }
>>>
>>> diff --git a/drivers/acpi/debug.c b/drivers/acpi/debug.c
>>> index 20223cb..9cb189f 100644
>>> --- a/drivers/acpi/debug.c
>>> +++ b/drivers/acpi/debug.c
>>> @@ -297,17 +297,15 @@ acpi_system_write_debug(struct file *file,
>>>
>>>        return count;
>>>  }
>>> +#endif
>>>
>>> -static int __init acpi_debug_init(void)
>>> +int __init acpi_debug_init(void)
>>>  {
>>> +#ifdef CONFIG_ACPI_PROCFS
>>>        struct proc_dir_entry *entry;
>>>        int error = 0;
>>>        char *name;
>>>
>>> -
>>> -       if (acpi_disabled)
>>> -               return 0;
>>> -
>>>        /* 'debug_layer' [R/W] */
>>>        name = ACPI_SYSTEM_FILE_DEBUG_LAYER;
>>>        entry =
>>> @@ -338,7 +336,7 @@ static int __init acpi_debug_init(void)
>>>        remove_proc_entry(ACPI_SYSTEM_FILE_DEBUG_LAYER, acpi_root_dir);
>>>        error = -ENODEV;
>>>        goto Done;
>>> -}
>>> -
>>> -subsys_initcall(acpi_debug_init);
>>> +#else
>>> +       return 0;
>>>  #endif
>>> +}
>>> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
>>> index 4a35f6e..44b8402 100644
>>> --- a/drivers/acpi/internal.h
>>> +++ b/drivers/acpi/internal.h
>>> @@ -3,6 +3,12 @@
>>>  int acpi_scan_init(void);
>>>  int acpi_system_init(void);
>>>
>>> +#ifdef CONFIG_ACPI_DEBUG
>> ==> #if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS)
> 
> I could do that, and leave the #ifdefs in debug.c as they were,
> but I thought it was cleaner to make it so that if we compile debug.c
> (i.e., CONFIG_ACPI_DEBUG=y), it always provides acpi_debug_init().
> 
> I moved the #ifdefs in debug.c so that acpi_debug_init() is a no-op
> if CONFIG_ACPI_PROCFS=n.
> 
> So I think my patch already addressed your concern, but let me
> know if not.

you had two copy
+#else
> > +       return 0;
> >  #endif
...

with
#if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS) 
in .h

you only need to do
>>> -
>>> -       if (acpi_disabled)
>>> -               return 0;
>>> -
>>>        /* 'debug_layer' [R/W] */
>>>        name = ACPI_SYSTEM_FILE_DEBUG_LAYER;
>>>        entry =
>>> @@ -338,7 +336,7 @@ static int __init acpi_debug_init(void)
>>>        remove_proc_entry(ACPI_SYSTEM_FILE_DEBUG_LAYER, acpi_root_dir);
>>>        error = -ENODEV;
>>>        goto Done;
>>> -}
>>> -
>>> -subsys_initcall(acpi_debug_init);

in debug.c

totally you will have less one #ifdef

YH

Re: [PATCH 06/10] ACPI: call acpi_debug_init() explicitly rather than as initcall

[Bjorn Helgaas]

On Tuesday 24 March 2009 05:20:44 pm Yinghai Lu wrote:
> Bjorn Helgaas wrote:
> > On Tuesday 24 March 2009 05:08:12 pm Yinghai Lu wrote:
> >> On Tue, Mar 24, 2009 at 3:50 PM, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> >>> This patch makes acpi_init() call acpi_debug_init() directly.
> >>> Previously, both were subsys_initcalls.  acpi_debug_init()
> >>> must happen after acpi_init(), and it's better to call it
> >>> explicitly rather than rely on link ordering.
> >>>
> >>> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> >>> ---
> >>>  drivers/acpi/bus.c      |    1 +
> >>>  drivers/acpi/debug.c    |   14 ++++++--------
> >>>  drivers/acpi/internal.h |    6 ++++++
> >>>  3 files changed, 13 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> >>> index c133072..f32cfd6 100644
> >>> --- a/drivers/acpi/bus.c
> >>> +++ b/drivers/acpi/bus.c
> >>> @@ -883,6 +883,7 @@ static int __init acpi_init(void)
> >>>        acpi_ec_init();
> >>>        acpi_power_init();
> >>>        acpi_system_init();
> >>> +       acpi_debug_init();
> >>>        return result;
> >>>  }
> >>>
> >>> diff --git a/drivers/acpi/debug.c b/drivers/acpi/debug.c
> >>> index 20223cb..9cb189f 100644
> >>> --- a/drivers/acpi/debug.c
> >>> +++ b/drivers/acpi/debug.c
> >>> @@ -297,17 +297,15 @@ acpi_system_write_debug(struct file *file,
> >>>
> >>>        return count;
> >>>  }
> >>> +#endif
> >>>
> >>> -static int __init acpi_debug_init(void)
> >>> +int __init acpi_debug_init(void)
> >>>  {
> >>> +#ifdef CONFIG_ACPI_PROCFS
> >>>        struct proc_dir_entry *entry;
> >>>        int error = 0;
> >>>        char *name;
> >>>
> >>> -
> >>> -       if (acpi_disabled)
> >>> -               return 0;
> >>> -
> >>>        /* 'debug_layer' [R/W] */
> >>>        name = ACPI_SYSTEM_FILE_DEBUG_LAYER;
> >>>        entry =
> >>> @@ -338,7 +336,7 @@ static int __init acpi_debug_init(void)
> >>>        remove_proc_entry(ACPI_SYSTEM_FILE_DEBUG_LAYER, acpi_root_dir);
> >>>        error = -ENODEV;
> >>>        goto Done;
> >>> -}
> >>> -
> >>> -subsys_initcall(acpi_debug_init);
> >>> +#else
> >>> +       return 0;
> >>>  #endif
> >>> +}
> >>> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> >>> index 4a35f6e..44b8402 100644
> >>> --- a/drivers/acpi/internal.h
> >>> +++ b/drivers/acpi/internal.h
> >>> @@ -3,6 +3,12 @@
> >>>  int acpi_scan_init(void);
> >>>  int acpi_system_init(void);
> >>>
> >>> +#ifdef CONFIG_ACPI_DEBUG
> >> ==> #if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS)
> > 
> > I could do that, and leave the #ifdefs in debug.c as they were,
> > but I thought it was cleaner to make it so that if we compile debug.c
> > (i.e., CONFIG_ACPI_DEBUG=y), it always provides acpi_debug_init().
> > 
> > I moved the #ifdefs in debug.c so that acpi_debug_init() is a no-op
> > if CONFIG_ACPI_PROCFS=n.
> > 
> > So I think my patch already addressed your concern, but let me
> > know if not.
> 
> you had two copy
> +#else
> > > +       return 0;
> > >  #endif
> ...
> 
> with
> #if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS) 
> in .h
> 
> you only need to do
> >>> -
> >>> -       if (acpi_disabled)
> >>> -               return 0;
> >>> -
> >>>        /* 'debug_layer' [R/W] */
> >>>        name = ACPI_SYSTEM_FILE_DEBUG_LAYER;
> >>>        entry =
> >>> @@ -338,7 +336,7 @@ static int __init acpi_debug_init(void)
> >>>        remove_proc_entry(ACPI_SYSTEM_FILE_DEBUG_LAYER, acpi_root_dir);
> >>>        error = -ENODEV;
> >>>        goto Done;
> >>> -}
> >>> -
> >>> -subsys_initcall(acpi_debug_init);
> 
> in debug.c
> 
> totally you will have less one #ifdef

You're right that I have two "#ifdef CONFIG_ACPI_PROCFS" in debug.c,
and I could get away with only one if I used
    #if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS)
in internal.h.  I actually did that in my first version of the patch.

However, I thought it was a bit ugly to put the CONFIG_ACPI_PROCFS
stuff in internal.h.  That would mean a reader of internal.h has
to know about the details of how debug.c is implemented.  It is
completely non-obvious why a definition of acpi_debug_init() should
depend on CONFIG_ACPI_PROCFS, so the reader would have to go dig
through debug.c to figure it out.  With my patch, the reader only
has to know "CONFIG_ACPI_DEBUG enables the build of debug.c."

If I understand you correctly, you're raising a style issue, and
there's no functional problem either way.  Right?

Bjorn

Re: [PATCH 06/10] ACPI: call acpi_debug_init() explicitly rather than as initcall

[Yinghai Lu]

Bjorn Helgaas wrote:
> On Tuesday 24 March 2009 05:20:44 pm Yinghai Lu wrote:
>> Bjorn Helgaas wrote:
>>> On Tuesday 24 March 2009 05:08:12 pm Yinghai Lu wrote:
>>>> On Tue, Mar 24, 2009 at 3:50 PM, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>>>>> This patch makes acpi_init() call acpi_debug_init() directly.
>>>>> Previously, both were subsys_initcalls.  acpi_debug_init()
>>>>> must happen after acpi_init(), and it's better to call it
>>>>> explicitly rather than rely on link ordering.
>>>>>
>>>>> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>>>>> ---
>>>>>  drivers/acpi/bus.c      |    1 +
>>>>>  drivers/acpi/debug.c    |   14 ++++++--------
>>>>>  drivers/acpi/internal.h |    6 ++++++
>>>>>  3 files changed, 13 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
>>>>> index c133072..f32cfd6 100644
>>>>> --- a/drivers/acpi/bus.c
>>>>> +++ b/drivers/acpi/bus.c
>>>>> @@ -883,6 +883,7 @@ static int __init acpi_init(void)
>>>>>        acpi_ec_init();
>>>>>        acpi_power_init();
>>>>>        acpi_system_init();
>>>>> +       acpi_debug_init();
>>>>>        return result;
>>>>>  }
>>>>>
>>>>> diff --git a/drivers/acpi/debug.c b/drivers/acpi/debug.c
>>>>> index 20223cb..9cb189f 100644
>>>>> --- a/drivers/acpi/debug.c
>>>>> +++ b/drivers/acpi/debug.c
>>>>> @@ -297,17 +297,15 @@ acpi_system_write_debug(struct file *file,
>>>>>
>>>>>        return count;
>>>>>  }
>>>>> +#endif
>>>>>
>>>>> -static int __init acpi_debug_init(void)
>>>>> +int __init acpi_debug_init(void)
>>>>>  {
>>>>> +#ifdef CONFIG_ACPI_PROCFS
>>>>>        struct proc_dir_entry *entry;
>>>>>        int error = 0;
>>>>>        char *name;
>>>>>
>>>>> -
>>>>> -       if (acpi_disabled)
>>>>> -               return 0;
>>>>> -
>>>>>        /* 'debug_layer' [R/W] */
>>>>>        name = ACPI_SYSTEM_FILE_DEBUG_LAYER;
>>>>>        entry =
>>>>> @@ -338,7 +336,7 @@ static int __init acpi_debug_init(void)
>>>>>        remove_proc_entry(ACPI_SYSTEM_FILE_DEBUG_LAYER, acpi_root_dir);
>>>>>        error = -ENODEV;
>>>>>        goto Done;
>>>>> -}
>>>>> -
>>>>> -subsys_initcall(acpi_debug_init);
>>>>> +#else
>>>>> +       return 0;
>>>>>  #endif
>>>>> +}
>>>>> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
>>>>> index 4a35f6e..44b8402 100644
>>>>> --- a/drivers/acpi/internal.h
>>>>> +++ b/drivers/acpi/internal.h
>>>>> @@ -3,6 +3,12 @@
>>>>>  int acpi_scan_init(void);
>>>>>  int acpi_system_init(void);
>>>>>
>>>>> +#ifdef CONFIG_ACPI_DEBUG
>>>> ==> #if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS)
>>> I could do that, and leave the #ifdefs in debug.c as they were,
>>> but I thought it was cleaner to make it so that if we compile debug.c
>>> (i.e., CONFIG_ACPI_DEBUG=y), it always provides acpi_debug_init().
>>>
>>> I moved the #ifdefs in debug.c so that acpi_debug_init() is a no-op
>>> if CONFIG_ACPI_PROCFS=n.
>>>
>>> So I think my patch already addressed your concern, but let me
>>> know if not.
>> you had two copy
>> +#else
>>>> +       return 0;
>>>>  #endif
>> ...
>>
>> with
>> #if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS) 
>> in .h
>>
>> you only need to do
>>>>> -
>>>>> -       if (acpi_disabled)
>>>>> -               return 0;
>>>>> -
>>>>>        /* 'debug_layer' [R/W] */
>>>>>        name = ACPI_SYSTEM_FILE_DEBUG_LAYER;
>>>>>        entry =
>>>>> @@ -338,7 +336,7 @@ static int __init acpi_debug_init(void)
>>>>>        remove_proc_entry(ACPI_SYSTEM_FILE_DEBUG_LAYER, acpi_root_dir);
>>>>>        error = -ENODEV;
>>>>>        goto Done;
>>>>> -}
>>>>> -
>>>>> -subsys_initcall(acpi_debug_init);
>> in debug.c
>>
>> totally you will have less one #ifdef
> 
> You're right that I have two "#ifdef CONFIG_ACPI_PROCFS" in debug.c,
> and I could get away with only one if I used
>     #if defined(CONFIG_ACPI_DEBUG) && defined(CONFIG_ACPI_PROCFS)
> in internal.h.  I actually did that in my first version of the patch.
> 
> However, I thought it was a bit ugly to put the CONFIG_ACPI_PROCFS
> stuff in internal.h.  That would mean a reader of internal.h has
> to know about the details of how debug.c is implemented.  It is
> completely non-obvious why a definition of acpi_debug_init() should
> depend on CONFIG_ACPI_PROCFS, so the reader would have to go dig
> through debug.c to figure it out.  With my patch, the reader only
> has to know "CONFIG_ACPI_DEBUG enables the build of debug.c."
> 
> If I understand you correctly, you're raising a style issue, and
> there's no functional problem either way.  Right?

besides that, some last_calls are merged to direct call.
wonder if those calling could depend on pci_acpi_init etc.

YH

Re: [PATCH 06/10] ACPI: call acpi_debug_init() explicitly rather than as initcall

[Bjorn Helgaas]

On Wednesday 25 March 2009 01:29:33 pm Yinghai Lu wrote:
> Bjorn Helgaas wrote:
> > If I understand you correctly, you're raising a style issue, and
> > there's no functional problem either way.  Right?
> 
> besides that, some last_calls are merged to direct call.
> wonder if those calling could depend on pci_acpi_init etc.

Can you be specific?  I can't do much with vague wondering.

I changed the following initcalls from subsys_initcall to direct calls:

      ACPI: call acpi_scan_init() explicitly rather than as initcall
      ACPI: call acpi_ec_init() explicitly rather than as initcall
      ACPI: call acpi_power_init() explicitly rather than as initcall
      ACPI: call acpi_system_init() explicitly rather than as initcall
      ACPI: call acpi_debug_init() explicitly rather than as initcall

pci_acpi_init() is called from pci_subsys_init(), which is also a
subsys_initcall, but it's in arch/x86.

In the current tree (before my patches) all the ACPI subsys_initcalls
are done before any of the arch/x86 subsys_initcalls.  So changing the
ACPI subsys_initcalls to direct calls should not change the order with
respect to pci_acpi_init().

This one changed from an arch_initcall to a direct call:

      ACPI: call init_acpi_device_notify() explicitly rather than as initcall

In that case, init_acpi_device_notify() happens before pci_acpi_init()
whether it's an arch_initcall or a direct call.  So this shouldn't be
a problem either.

These two changed from late_initcalls to direct calls:

      ACPI: call acpi_sleep_proc_init() explicitly rather than as initcall
      ACPI: call acpi_wakeup_device_init() explicitly rather than as initcall

These two did change order with respect to pci_acpi_init().  As
late_initcalls, they happened after pci_acpi_init().  As direct calls,
they happen before pci_acpi_init().

However, I do not see any dependency of either one on pci_acpi_init(),
so I don't think it makes any difference.  Do you?

Bjorn

Re: [PATCH 00/10] ACPI: remove several initcalls

[Len Brown]

On Tue, 24 Mar 2009, Bjorn Helgaas wrote:

> These patches change several ACPI initcalls to explicit calls.
> This removes dependencies on link order and makes the code
> clearer.
> 
> Comments welcome.
> 
> ---
> 
> Bjorn Helgaas (10):
>       ACPI: tidy up makefile
>       ACPI: call acpi_wakeup_device_init() explicitly rather than as initcall
>       ACPI: call acpi_sleep_proc_init() explicitly rather than as initcall
>       ACPI: call init_acpi_device_notify() explicitly rather than as initcall
>       ACPI: call acpi_debug_init() explicitly rather than as initcall
>       ACPI: call acpi_system_init() explicitly rather than as initcall
>       ACPI: call acpi_power_init() explicitly rather than as initcall
>       ACPI: call acpi_ec_init() explicitly rather than as initcall
>       ACPI: call acpi_scan_init() explicitly rather than as initcall
>       ACPI: skip DMI power state check when ACPI disabled

nice cleanup, Bjorn -- applied.

I'm fine with the #ifdef in debug.c, BTW.

Indeed, I'd accept a patch to delete the /proc part of debug.c,
since it is obsolete by the modparam code above it, and we warned
over a year ago that it will go away.

thanks,
-Len Brown, Intel Open Source Technology Center