Merge commit 'v2.6.34' into next

diff --combined Documentation/feature-removal-schedule.txt
index c8659ad,05df0b7..4759af3
--- 1/Documentation/feature-removal-schedule.txt
--- 2/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@@ -519,6 -519,17 +519,6 @@@ Why:      Duplicate functionality with the g
  Who:  Hans de Goede <hdegoede@redhat.com>
  
  ----------------------------
 -
 -What: corgikbd, spitzkbd, tosakbd driver
 -When: 2.6.35
 -Files:        drivers/input/keyboard/{corgi,spitz,tosa}kbd.c
 -Why:  We now have a generic GPIO based matrix keyboard driver that
 -      are fully capable of handling all the keys on these devices.
 -      The original drivers manipulate the GPIO registers directly
 -      and so are difficult to maintain.
 -Who:  Eric Miao <eric.y.miao@gmail.com>
 -
 -----------------------------
  
  What: corgi_ssp and corgi_ts driver
  When: 2.6.35
@@@ -578,3 -589,26 +578,26 @@@ Why:     Useful in 2003, implementation is 
        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>