Merge branch 'for-2.6.34-incoming' into for-2.6.35-incoming

[pandora-kernel.git] / Documentation / feature-removal-schedule.txt

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index a5cc0db..05df0b7 100644 (file)
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -582,3 +582,33 @@ Why:       The paravirt mmu host support is slower than non-paravirt mmu, both
 Who:   Avi Kivity <avi@redhat.com>
 
 ----------------------------
+
+What:  "acpi=ht" boot option
+When:  2.6.35
+Why:   Useful in 2003, implementation is a hack.
+       Generally invoked by accident today.
+       Seen as doing more harm than good.
+Who:   Len Brown <len.brown@intel.com>
+
+----------------------------
+
+What:  video4linux /dev/vtx teletext API support
+When:  2.6.35
+Files: drivers/media/video/saa5246a.c drivers/media/video/saa5249.c
+       include/linux/videotext.h
+Why:   The vtx device nodes have been superseded by vbi device nodes
+       for many years. No applications exist that use the vtx support.
+       Of the two i2c drivers that actually support this API the saa5249
+       has been impossible to use for a year now and no known hardware
+       that supports this device exists. The saa5246a is theoretically
+       supported by the old mxb boards, but it never actually worked.
+
+       In summary: there is no hardware that can use this API and there
+       are no applications actually implementing this API.
+
+       The vtx support still reserves minors 192-223 and we would really
+       like to reuse those for upcoming new functionality. In the unlikely
+       event that new hardware appears that wants to use the functionality
+       provided by the vtx API, then that functionality should be build
+       around the sliced VBI API instead.
+Who:   Hans Verkuil <hverkuil@xs4all.nl>