[PATCH][RFC] Clean up Kconfig logic for IA64 ACPI

[PATCH][RFC] Clean up Kconfig logic for IA64 ACPI

[Noah J. Misch]

Greetings,

I found the Kconfig logic for ACPI and IA64, as defined in arch/ia64/Kconfig and
drivers/acpi/Kconfig to be a bit redundant and hard to follow.  It appears to do
the following:

1) Set ACPI=y, ACPI_INTERPRETER=y, ACPI_EFI=y, and ACPI_KERNEL_CONFIG=y if and
only if not configuring for the HP simulator (arch/ia64/Kconfig).

2) Show the configs in drivers/acpi/Kconfig unless configuring for the HP
simulator (arch/IA64/Kconfig).

3) Set ACPI_BOOT=y under the same conditions as #1 (drivers/acpi/Kconfig).

4) Set ACPI_INTERPRETER=y if and only if !IA64_SGI_SN (drivers/acpi/Kconfig).

5) Automatically set or allow a number of specific ACPI options if
ACPI_INTERPRETER but not IA64_SGI_SN (drivers/acpi/Kconfig).

6) Set ACPI_EFI=y if ACPI_INTERPRETER (drivers/acpi/Kconfig).

There's a fair amount of textual and logical redundancy there, as well as
dependencies on and selections of obsolete options.  This had even caused
compilation failures in certain corner cases.  This patch corrects that:

1) Remove the copies of ACPI, ACPI_INTERPRETER, and ACPI_EFI from
arch/ia64/Kconfig and instead make IA64 select ACPI unless configuring for the
HP simulator.

2) Delete ACPI_KERNEL_CONFIG from arch/ia64/Kconfig.  It no longer affects any
part of the kernel, and it appears as though ACPI_BOOT has fully superseded it.

3) Remove all dependencies in drivers/acpi/Kconfig that reference IA64_SGI_SN.
That option no longer exists, and even if it did, only ACPI_INTERPRETER need
depend on it, and the rest of the options it currently guards would follow suit.

I have compiled a wide variety of IA64 kernels with this patch applied, so I am
fairly confident that it is not introducing new problems.  The patch applies to
linux-2.5 BK and linux-ia64-2.5 BK as of 2003-11-02 at 0000 UTC.

This should not change any user-visible configuration semantics.  Indeed, the
only user-visible change is the visible defaulting of ACPI.  Please let me know
what you think.  I consider this 2.7 material.

Thanks,
Noah

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
#	           ChangeSet	1.1296.83.15 -> 1.1296.83.16
#	   arch/ia64/Kconfig	1.46    -> 1.47
#	drivers/acpi/Kconfig	1.26    -> 1.27
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 03/10/27	noah@caltech.edu	1.1296.83.16
# Merge ACPI Kconfig entries from arch/ia64/Kconfig into drivers/acpi/Kconfig.
# Eliminate references to obsolete ACPI_KERNEL_CONFIG and IA64_SGI_SN config
# variables.  Add help text to ACPI_BOOT, for the benefit of developers
# perusing drivers/acpi/Kconfig.
# --------------------------------------------
#
diff -Nru a/arch/ia64/Kconfig b/arch/ia64/Kconfig
--- a/arch/ia64/Kconfig	Sat Nov  1 14:43:25 2003
+++ b/arch/ia64/Kconfig	Sat Nov  1 14:43:25 2003
@@ -11,6 +11,7 @@

 config IA64
 	bool
+	select ACPI if !IA64_HP_SIM
 	default y
 	help
 	  The Itanium Processor Family is Intel's 64-bit successor to
@@ -130,57 +131,6 @@
 	bool "64KB"

 endchoice
-
-config ACPI
-	bool
-	depends on !IA64_HP_SIM
-	default y
-	---help---
-	  ACPI/OSPM support for Linux is currently under development. As such,
-	  this support is preliminary and EXPERIMENTAL.  Configuring ACPI
-	  support enables kernel interfaces that allow higher level software
-	  (OSPM) to manipulate ACPI defined hardware and software interfaces,
-	  including the evaluation of ACPI control methods.  If unsure, choose
-	  N here.  Note, this option will enlarge your kernel by about 120K.
-
-	  This support requires an ACPI compliant platform (hardware/firmware).
-	  If both ACPI and Advanced Power Management (APM) support are
-	  configured, whichever is loaded first shall be used.
-
-	  This code DOES NOT currently provide a complete OSPM implementation
-	  -- it has not yet reached APM's level of functionality.  When fully
-	  implemented, Linux ACPI/OSPM will provide a more robust functional
-	  replacement for legacy configuration and power management
-	  interfaces, including the Plug-and-Play BIOS specification (PnP
-	  BIOS), the Multi-Processor Specification (MPS), and the Advanced
-	  Power Management specification (APM).
-
-	  Linux support for ACPI/OSPM is based on Intel Corporation's ACPI
-	  Component Architecture (ACPI CA). The latest ACPI CA source code,
-	  documentation, debug builds, and implementation status information
-	  can be downloaded from:
-	  <http://developer.intel.com/technology/iapc/acpi/downloads.htm>.
-
-	  The ACPI Sourceforge project may also be of interest:
-	  <http://sf.net/projects/acpi/>
-
-config ACPI_EFI
-	bool
-	depends on !IA64_HP_SIM
-	default y
-
-config ACPI_INTERPRETER
-	bool
-	depends on !IA64_HP_SIM
-	default y
-
-config ACPI_KERNEL_CONFIG
-	bool
-	depends on !IA64_HP_SIM
-	default y
-	help
-	  If you say `Y' here, Linux's ACPI support will use the
-	  hardware-level system descriptions found on IA-64 systems.

 config IA64_BRL_EMU
 	bool
diff -Nru a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
--- a/drivers/acpi/Kconfig	Sat Nov  1 14:43:25 2003
+++ b/drivers/acpi/Kconfig	Sat Nov  1 14:43:25 2003
@@ -9,7 +9,7 @@

 config ACPI
 	bool "ACPI Support"
-	depends on IA64 || X86
+	depends on IA64 && !IA64_HP_SIM || X86

 	default y
 	---help---
@@ -44,11 +44,15 @@
 	bool
 	depends on ACPI || X86_HT
 	default y
+	help
+	  If you say `Y' here, Linux will read the ACPI tables at boot to
+	  discover system characteristics such as processors, APICs, and
+	  PCI IRQ routing.  This replaces traditional mechanisms for
+	  discovering those properties.

 config ACPI_INTERPRETER
 	bool
 	depends on ACPI
-	depends on !IA64_SGI_SN
 	default y

 config ACPI_SLEEP
@@ -101,7 +105,6 @@
 config ACPI_BUTTON
 	tristate "Button"
 	depends on ACPI_INTERPRETER
-	depends on !IA64_SGI_SN
 	default m
 	help
 	  This driver registers for events based on buttons, such as the
@@ -113,7 +116,6 @@
 config ACPI_FAN
 	tristate "Fan"
 	depends on ACPI_INTERPRETER
-	depends on !IA64_SGI_SN
 	default m
 	help
 	  This driver adds support for ACPI fan devices, allowing user-mode
@@ -122,7 +124,6 @@
 config ACPI_PROCESSOR
 	tristate "Processor"
 	depends on ACPI_INTERPRETER
-	depends on !IA64_SGI_SN
 	default m
 	help
 	  This driver installs ACPI as the idle handler for Linux, and uses
@@ -207,7 +208,6 @@
 config ACPI_DEBUG
 	bool "Debug Statements"
 	depends on ACPI_INTERPRETER
-	depends on !IA64_SGI_SN
 	default n
 	help
 	  The ACPI driver can optionally report errors with a great deal
@@ -217,7 +217,6 @@
 config ACPI_BUS
 	bool
 	depends on ACPI_INTERPRETER
-	depends on !IA64_SGI_SN
 	default y

 config ACPI_EC
@@ -233,19 +232,16 @@
 config ACPI_POWER
 	bool
 	depends on ACPI_INTERPRETER
-	depends on !IA64_SGI_SN
 	default y

 config ACPI_PCI
 	bool
 	depends on ACPI_INTERPRETER
-	depends on !IA64_SGI_SN
 	default PCI

 config ACPI_SYSTEM
 	bool
 	depends on ACPI_INTERPRETER
-	depends on !IA64_SGI_SN
 	default y
 	help
 	  This driver will enable your system to shut down using ACPI, and
@@ -260,7 +256,6 @@
 config ACPI_RELAXED_AML
 	bool "Relaxed AML"
 	depends on ACPI_INTERPRETER
-	depends on !IA64_SGI_SN
 	default n
 	help
 	  If you say `Y' here, the ACPI interpreter will relax its checking

Re: [ACPI] [PATCH][RFC] Clean up Kconfig logic for IA64 ACPI

[Matthew Wilcox]

On Sat, Nov 01, 2003 at 04:35:11PM -0800, Noah J. Misch wrote:
> Greetings,
> 
> I found the Kconfig logic for ACPI and IA64, as defined in arch/ia64/Kconfig and
> drivers/acpi/Kconfig to be a bit redundant and hard to follow.  It appears to do
> the following:

I posted a similar patch here:

http://marc.theaimsgroup.com/?l=linux-ia64&m=106555019402117&w=2

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [ACPI] [PATCH][RFC] Clean up Kconfig logic for IA64 ACPI

[Noah J. Misch]

On Sun, 2 Nov 2003, Matthew Wilcox wrote:

> > I found the Kconfig logic for ACPI and IA64, as defined in arch/ia64/Kconfig and
> > drivers/acpi/Kconfig to be a bit redundant and hard to follow.  It appears to do
> > the following:
>
> I posted a similar patch here:
>
> http://marc.theaimsgroup.com/?l=linux-ia64&m=106555019402117&w=2

I do not read linux-ia64 regularly, so I did not notice your work.  I apologize
for not acknowledging it.

Why not include drivers/Kconfig and scrap the individual subdirectory includes,
as i386 does?

Also, it looks like your patch makes ACPI non-mandatory.  Is that intentional?

Thanks,
Noah

Re: [ACPI] [PATCH][RFC] Clean up Kconfig logic for IA64 ACPI

[Matthew Wilcox]

On Sat, Nov 01, 2003 at 08:05:44PM -0800, Noah J. Misch wrote:
> I do not read linux-ia64 regularly, so I did not notice your work.  I
> apologize for not acknowledging it.

No problem ;-)

> Why not include drivers/Kconfig and scrap the individual subdirectory
> includes, as i386 does?

At that time, I hadn't done the work to create drivers/Kconfig ;-)
The main problem for ia64 is the simulator stuff.  Maybe something like:

if !IA64_HP_SIM
source "drivers/Kconfig"
endif

if IA64_HP_SIM
source "drivers/base/Kconfig"
source "drivers/scsi/Kconfig"
source "net/Kconfig"
source "drivers/block/Kconfig"
source "arch/ia64/hp/sim/Kconfig"
endif

(I guess Kconfig needs an "else" keyword).

(Also the duplication of drivers/block/Kconfig is no longer necessary).

> Also, it looks like your patch makes ACPI non-mandatory.  Is that intentional?

Hmmm... no ;-)  I agree the "select" should probably go in -- we seem
to be infected with ACPI for the foreseeable future ;-(

I imagine these kinds of patches can go into 2.6.1 -- the freeze should
let up a bit by then.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

IA64/simulators - Kconfig logic for drivers/*

[Noah J. Misch]

On Sun, 2 Nov 2003, Matthew Wilcox wrote:

> > Why not include drivers/Kconfig and scrap the individual subdirectory
> > includes, as i386 does?
>
> At that time, I hadn't done the work to create drivers/Kconfig ;-)
> The main problem for ia64 is the simulator stuff.  Maybe something like:
>
> if !IA64_HP_SIM
> source "drivers/Kconfig"
> endif
>
> if IA64_HP_SIM
> source "drivers/base/Kconfig"
> source "drivers/scsi/Kconfig"
> source "net/Kconfig"
> source "drivers/block/Kconfig"
> source "arch/ia64/hp/sim/Kconfig"
> endif

I would guess that everyone who uses a simulator is a kernel developer or maybe
an application developer.  I worry that the risk of hiding useful configs from
simulator users by lax maintenance of that block of Kconfig logic exceeds the
risk of those people trying to build a simulator kernel with all kinds of
hardware drivers and finding that it doesn't work.  A quieter configuration is
nice, however.  Hmmm.

What about something like the following - create a new config, ARCH_SIMULATOR,
that IA64_HP_SIM and any other barebones simulators set.  Then put an "if
!ARCH_SIMULATOR" on the subdir includes in drivers/Kconfig that definitely don't
apply to simulators (drivers specifically for real hardware).  That increases
the probability that people who add new features that simulator users might want
will know to unmask them, since far more people see drivers/Kconfig than do
arch/ia64/Kconfig, and it handles similar simulators in a uniform way.

You could also extend that strategy by, for example masking the SCSI low level
drivers menu with an "if !ARCH_SIMULATOR" so simulator users see the generic
SCSI machinery but not all the irrelevant hardware drivers.

What do you think?

Re: IA64/simulators - Kconfig logic for drivers/*

[David Mosberger]

>>>>> On Sat, 1 Nov 2003 22:41:07 -0800 (PST), "Noah J. Misch" <noah@caltech.edu> said:

  Noah> On Sun, 2 Nov 2003, Matthew Wilcox wrote:
  >> > Why not include drivers/Kconfig and scrap the individual subdirectory
  >> > includes, as i386 does?

  >> At that time, I hadn't done the work to create drivers/Kconfig ;-)
  >> The main problem for ia64 is the simulator stuff.  Maybe something like:

  >> if !IA64_HP_SIM
  >> source "drivers/Kconfig"
  >> endif

  >> if IA64_HP_SIM
  >> source "drivers/base/Kconfig"
  >> source "drivers/scsi/Kconfig"
  >> source "net/Kconfig"
  >> source "drivers/block/Kconfig"
  >> source "arch/ia64/hp/sim/Kconfig"
  >> endif

  Noah> I would guess that everyone who uses a simulator is a kernel
  Noah> developer or maybe an application developer.  I worry that the
  Noah> risk of hiding useful configs from simulator users by lax
  Noah> maintenance of that block of Kconfig logic exceeds the risk of
  Noah> those people trying to build a simulator kernel with all kinds
  Noah> of hardware drivers and finding that it doesn't work.  A
  Noah> quieter configuration is nice, however.  Hmmm.

I suspect it should be possible to do this much cleaner with the new
Kconfig system.  For example, if all PCI-dependent drivers really do
specify "depends on PCI" (or something equivalent), then a good
portion of the hopeless drivers would automagically go away from the
simulator configuration.  What's there now "works", but it clearly
could stand some modernization.

	--david