ACPI: schedule obsolete features for deletion
[sfrench/cifs-2.6.git] / Documentation / feature-removal-schedule.txt
index 031029e89fd9c21970189094715ae872c6efb02e..2ee16b49e10e13324a6dc66defb8c73f92d8e91c 100644 (file)
@@ -151,15 +151,6 @@ Who:       Thomas Gleixner <tglx@linutronix.de>
 
 ---------------------------
 
-What:  I2C interface of the it87 driver
-When:  January 2007
-Why:   The ISA interface is faster and should be always available. The I2C
-       probing is also known to cause trouble in at least one case (see
-       bug #5889.)
-Who:   Jean Delvare <khali@linux-fr.org>
-
----------------------------
-
 What:  Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
        (temporary transition config option provided until then)
        The transition config option will also be removed at the same time.
@@ -216,22 +207,6 @@ Who:       Thomas Gleixner <tglx@linutronix.de>
 
 ---------------------------
 
-What:  Bridge netfilter deferred IPv4/IPv6 output hook calling
-When:  January 2007
-Why:   The deferred output hooks are a layering violation causing unusual
-       and broken behaviour on bridge devices. Examples of things they
-       break include QoS classifation using the MARK or CLASSIFY targets,
-       the IPsec policy match and connection tracking with VLANs on a
-       bridge. Their only use is to enable bridge output port filtering
-       within iptables with the physdev match, which can also be done by
-       combining iptables and ebtables using netfilter marks. Until it
-       will get removed the hook deferral is disabled by default and is
-       only enabled when needed.
-
-Who:   Patrick McHardy <kaber@trash.net>
-
----------------------------
-
 What:  PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
 When:  October 2008
 Why:   The stacking of class devices makes these values misleading and
@@ -259,3 +234,70 @@ Why:       The new layer 3 independant connection tracking replaces the old
 Who:   Patrick McHardy <kaber@trash.net>
 
 ---------------------------
+
+What:  ACPI hooks (X86_SPEEDSTEP_CENTRINO_ACPI) in speedstep-centrino driver
+When:  December 2006
+Why:   Speedstep-centrino driver with ACPI hooks and acpi-cpufreq driver are
+       functionally very much similar. They talk to ACPI in same way. Only
+       difference between them is the way they do frequency transitions.
+       One uses MSRs and the other one uses IO ports. Functionaliy of
+       speedstep_centrino with ACPI hooks is now merged into acpi-cpufreq.
+       That means one common driver will support all Intel Enhanced Speedstep
+       capable CPUs. That means less confusion over name of
+       speedstep-centrino driver (with that driver supposed to be used on
+       non-centrino platforms). That means less duplication of code and
+       less maintenance effort and no possibility of these two drivers
+       going out of sync.
+       Current users of speedstep_centrino with ACPI hooks are requested to
+       switch over to acpi-cpufreq driver. speedstep-centrino will continue
+       to work using older non-ACPI static table based scheme even after this
+       date.
+
+Who:   Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
+
+---------------------------
+
+What:  ACPI hotkey driver (CONFIG_ACPI_HOTKEY)
+When:  2.6.21
+Why:   hotkey.c was an attempt to consolidate multiple drivers that use
+       ACPI to implement hotkeys.  However, hotkeys are not documented
+       in the ACPI specification, so the drivers used undocumented
+       vendor-specific hooks and turned out to be more different than
+       the same.
+
+       Further, the keys and the features supplied by each platform
+       are different, so there will always be a need for
+       platform-specific drivers.
+
+       So the new plan is to delete hotkey.c and instead, work on the
+       platform specific drivers to try to make them look the same
+       to the user when they supply the same features.
+
+       hotkey.c has always depended on CONFIG_EXPERIMENTAL
+
+Who:   Len Brown <len.brown@intel.com>
+
+---------------------------
+
+What:  /sys/firmware/acpi/namespace
+When:  2.6.21
+Why:   The ACPI namespace is effectively the symbol list for
+       the BIOS.  The device names are completely arbitrary
+       and have no place being exposed to user-space.
+
+       For those interested in the BIOS ACPI namespace,
+       the BIOS can be extracted and disassembled with acpidump
+       and iasl as documented in the pmtools package here:
+       http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils
+
+Who:   Len Brown <len.brown@intel.com>
+
+---------------------------
+
+What:  /proc/acpi/button
+When:  August 2007
+Why:   /proc/acpi/button has been replaced by events to the input layer
+       since 2.6.20.
+Who:   Len Brown <len.brown@intel.com>
+
+---------------------------