diff options
| author | David S. Miller <davem@davemloft.net> | 2010-05-12 00:05:35 -0700 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2010-05-12 00:05:35 -0700 |
| commit | 278554bd6579206921f5d8a523649a7a57f8850d (patch) | |
| tree | 4e6c527daf0910e455b3aa72e2c96b0479e430be /Documentation/feature-removal-schedule.txt | |
| parent | 5a147e8bf982f9dd414c1dd751fe02c1942506b2 (diff) | |
| parent | cea0d767c29669bf89f86e4aee46ef462d2ebae8 (diff) | |
Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
Documentation/feature-removal-schedule.txt
drivers/net/wireless/ath/ar9170/usb.c
drivers/scsi/iscsi_tcp.c
net/ipv4/ipmr.c
Diffstat (limited to 'Documentation/feature-removal-schedule.txt')
| -rw-r--r-- | Documentation/feature-removal-schedule.txt | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index a1c6e927798..e592dade642 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -626,3 +626,26 @@ Files: net/netfilter/xt_NOTRACK.c When: April 2011 Why: Superseded by xt_CT Who: Netfilter developer team <netfilter-devel@vger.kernel.org> + +--------------------------- + +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> |