path: root/Documentation/feature-removal-schedule.txt
diff options
Diffstat (limited to 'Documentation/feature-removal-schedule.txt')
1 files changed, 9 insertions, 74 deletions
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index f487c6918d7..492e81df296 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -108,42 +108,6 @@ Who: Pavel Machek <pavel@ucw.cz>
-What: Video4Linux obsolete drivers using V4L1 API
-When: kernel 2.6.39
-Files: drivers/staging/se401/* drivers/staging/usbvideo/*
-Check: drivers/staging/se401/se401.c drivers/staging/usbvideo/usbvideo.c
-Why: There are some drivers still using V4L1 API, despite all efforts we've done
- to migrate. Those drivers are for obsolete hardware that the old maintainer
- didn't care (or not have the hardware anymore), and that no other developer
- could find any hardware to buy. They probably have no practical usage today,
- and people with such old hardware could probably keep using an older version
- of the kernel. Those drivers will be moved to staging on 2.6.38 and, if nobody
- cares enough to port and test them with V4L2 API, they'll be removed on 2.6.39.
-Who: Mauro Carvalho Chehab <mchehab@infradead.org>
-What: Video4Linux: Remove obsolete ioctl's
-When: kernel 2.6.39
-Files: include/media/videodev2.h
-Why: Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong
- type of R/W arguments. They were fixed, but the old ioctl names are
- still there, maintained to avoid breaking binary compatibility:
- #define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int)
- #define VIDIOC_S_PARM_OLD _IOW('V', 22, struct v4l2_streamparm)
- #define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct v4l2_control)
- #define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct v4l2_audio)
- #define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct v4l2_audioout)
- #define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct v4l2_cropcap)
- There's no sense on preserving those forever, as it is very doubtful
- that someone would try to use a such old binary with a modern kernel.
- Removing them will allow us to remove some magic done at the V4L ioctl
- handler.
-Who: Mauro Carvalho Chehab <mchehab@infradead.org>
What: sys_sysctl
When: September 2010
@@ -270,14 +234,6 @@ Who: Zhang Rui <rui.zhang@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>
What: /proc/acpi/event
When: February 2008
Why: /proc/acpi/event has been replaced by events via the input layer
@@ -431,26 +387,6 @@ Who: Tejun Heo <tj@kernel.org>
-What: Support for lcd_switch and display_get in asus-laptop driver
-When: March 2010
-Why: These two features use non-standard interfaces. There are the
- only features that really need multiple path to guess what's
- the right method name on a specific laptop.
- Removing them will allow to remove a lot of code an significantly
- clean the drivers.
- This will affect the backlight code which won't be able to know
- if the backlight is on or off. The platform display file will also be
- write only (like the one in eeepc-laptop).
- This should'nt affect a lot of user because they usually know
- when their display is on or off.
-Who: Corentin Chary <corentin.chary@gmail.com>
What: sysfs-class-rfkill state file
When: Feb 2014
Files: net/rfkill/core.c
@@ -585,16 +521,6 @@ Who: NeilBrown <neilb@suse.de>
-What: i2c_adapter.id
-When: June 2011
-Why: This field is deprecated. I2C device drivers shouldn't change their
- behavior based on the underlying I2C adapter. Instead, the I2C
- adapter driver should instantiate the I2C devices and provide the
- needed platform-specific information.
-Who: Jean Delvare <khali@linux-fr.org>
What: cancel_rearming_delayed_work[queue]()
When: 2.6.39
@@ -645,3 +571,12 @@ Who: Florian Westphal <fw@strlen.de>
Files: include/linux/netfilter_ipv4/ipt_addrtype.h
+What: i2c_driver.attach_adapter
+ i2c_driver.detach_adapter
+When: September 2011
+Why: These legacy callbacks should no longer be used as i2c-core offers
+ a variety of preferable alternative ways to instantiate I2C devices.
+Who: Jean Delvare <khali@linux-fr.org>