Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | The following is a list of files and features that are going to be |
2 | removed in the kernel source tree. Every entry should contain what | |
3 | exactly is going away, why it is happening, and who is going to be doing | |
4 | the work. When the feature is removed from the kernel, it should also | |
5 | be removed from this file. | |
6 | ||
7 | --------------------------- | |
8 | ||
45a5c8ba DG |
9 | What: USER_SCHED |
10 | When: 2.6.34 | |
11 | ||
12 | Why: USER_SCHED was implemented as a proof of concept for group scheduling. | |
13 | The effect of USER_SCHED can already be achieved from userspace with | |
14 | the help of libcgroup. The removal of USER_SCHED will also simplify | |
15 | the scheduler code with the removal of one major ifdef. There are also | |
16 | issues USER_SCHED has with USER_NS. A decision was taken not to fix | |
17 | those and instead remove USER_SCHED. Also new group scheduling | |
18 | features will not be implemented for USER_SCHED. | |
19 | ||
20 | Who: Dhaval Giani <dhaval@linux.vnet.ibm.com> | |
21 | ||
22 | --------------------------- | |
23 | ||
4d8cd268 LR |
24 | What: PRISM54 |
25 | When: 2.6.34 | |
26 | ||
27 | Why: prism54 FullMAC PCI / Cardbus devices used to be supported only by the | |
28 | prism54 wireless driver. After Intersil stopped selling these | |
29 | devices in preference for the newer more flexible SoftMAC devices | |
30 | a SoftMAC device driver was required and prism54 did not support | |
31 | them. The p54pci driver now exists and has been present in the kernel for | |
32 | a while. This driver supports both SoftMAC devices and FullMAC devices. | |
33 | The main difference between these devices was the amount of memory which | |
34 | could be used for the firmware. The SoftMAC devices support a smaller | |
35 | amount of memory. Because of this the SoftMAC firmware fits into FullMAC | |
36 | devices's memory. p54pci supports not only PCI / Cardbus but also USB | |
37 | and SPI. Since p54pci supports all devices prism54 supports | |
38 | you will have a conflict. I'm not quite sure how distributions are | |
39 | handling this conflict right now. prism54 was kept around due to | |
40 | claims users may experience issues when using the SoftMAC driver. | |
41 | Time has passed users have not reported issues. If you use prism54 | |
42 | and for whatever reason you cannot use p54pci please let us know! | |
43 | E-mail us at: linux-wireless@vger.kernel.org | |
44 | ||
45 | For more information see the p54 wiki page: | |
46 | ||
47 | http://wireless.kernel.org/en/users/Drivers/p54 | |
48 | ||
49 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> | |
50 | ||
51 | --------------------------- | |
52 | ||
9d9b8fb0 RG |
53 | What: IRQF_SAMPLE_RANDOM |
54 | Check: IRQF_SAMPLE_RANDOM | |
55 | When: July 2009 | |
56 | ||
57 | Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy | |
58 | sources in the kernel's current entropy model. To resolve this, every | |
59 | input point to the kernel's entropy pool needs to better document the | |
60 | type of entropy source it actually is. This will be replaced with | |
61 | additional add_*_randomness functions in drivers/char/random.c | |
62 | ||
63 | Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com> | |
64 | ||
65 | --------------------------- | |
66 | ||
6ee7d330 | 67 | What: The ieee80211_regdom module parameter |
8a5117d8 | 68 | When: March 2010 / desktop catchup |
6ee7d330 LR |
69 | |
70 | Why: This was inherited by the CONFIG_WIRELESS_OLD_REGULATORY code, | |
71 | and currently serves as an option for users to define an | |
72 | ISO / IEC 3166 alpha2 code for the country they are currently | |
73 | present in. Although there are userspace API replacements for this | |
74 | through nl80211 distributions haven't yet caught up with implementing | |
75 | decent alternatives through standard GUIs. Although available as an | |
76 | option through iw or wpa_supplicant its just a matter of time before | |
77 | distributions pick up good GUI options for this. The ideal solution | |
78 | would actually consist of intelligent designs which would do this for | |
79 | the user automatically even when travelling through different countries. | |
80 | Until then we leave this module parameter as a compromise. | |
81 | ||
82 | When userspace improves with reasonable widely-available alternatives for | |
83 | this we will no longer need this module parameter. This entry hopes that | |
84 | by the super-futuristically looking date of "March 2010" we will have | |
85 | such replacements widely available. | |
86 | ||
87 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> | |
88 | ||
89 | --------------------------- | |
90 | ||
8a5117d8 LR |
91 | What: CONFIG_WIRELESS_OLD_REGULATORY - old static regulatory information |
92 | When: March 2010 / desktop catchup | |
93 | ||
b2e1b302 LR |
94 | Why: The old regulatory infrastructure has been replaced with a new one |
95 | which does not require statically defined regulatory domains. We do | |
96 | not want to keep static regulatory domains in the kernel due to the | |
97 | the dynamic nature of regulatory law and localization. We kept around | |
98 | the old static definitions for the regulatory domains of: | |
8a5117d8 | 99 | |
b2e1b302 LR |
100 | * US |
101 | * JP | |
102 | * EU | |
8a5117d8 | 103 | |
b2e1b302 | 104 | and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was |
8a5117d8 LR |
105 | set. We will remove this option once the standard Linux desktop catches |
106 | up with the new userspace APIs we have implemented. | |
107 | ||
b2e1b302 LR |
108 | Who: Luis R. Rodriguez <lrodriguez@atheros.com> |
109 | ||
110 | --------------------------- | |
111 | ||
471d0558 | 112 | What: dev->power.power_state |
1ebfd79e PM |
113 | When: July 2007 |
114 | Why: Broken design for runtime control over driver power states, confusing | |
115 | driver-internal runtime power management with: mechanisms to support | |
116 | system-wide sleep state transitions; event codes that distinguish | |
117 | different phases of swsusp "sleep" transitions; and userspace policy | |
118 | inputs. This framework was never widely used, and most attempts to | |
119 | use it were broken. Drivers should instead be exposing domain-specific | |
120 | interfaces either to kernel or to userspace. | |
121 | Who: Pavel Machek <pavel@suse.cz> | |
122 | ||
123 | --------------------------- | |
124 | ||
42d12f5a MCC |
125 | What: Video4Linux API 1 ioctls and from Video devices. |
126 | When: July 2009 | |
127 | Files: include/linux/videodev.h | |
128 | Check: include/linux/videodev.h | |
11a5a10e | 129 | Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6 |
875c296b MCC |
130 | series. The old API have lots of drawbacks and don't provide enough |
131 | means to work with all video and audio standards. The newer API is | |
132 | already available on the main drivers and should be used instead. | |
133 | Newer drivers should use v4l_compat_translate_ioctl function to handle | |
134 | old calls, replacing to newer ones. | |
135 | Decoder iocts are using internally to allow video drivers to | |
136 | communicate with video decoders. This should also be improved to allow | |
137 | V4L2 calls being translated into compatible internal ioctls. | |
11a5a10e MCC |
138 | Compatibility ioctls will be provided, for a while, via |
139 | v4l1-compat module. | |
140 | Who: Mauro Carvalho Chehab <mchehab@infradead.org> | |
875c296b MCC |
141 | |
142 | --------------------------- | |
143 | ||
bf45d9b0 DB |
144 | What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) |
145 | When: November 2005 | |
146 | Files: drivers/pcmcia/: pcmcia_ioctl.c | |
147 | Why: With the 16-bit PCMCIA subsystem now behaving (almost) like a | |
148 | normal hotpluggable bus, and with it using the default kernel | |
149 | infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA | |
150 | control ioctl needed by cardmgr and cardctl from pcmcia-cs is | |
151 | unnecessary, and makes further cleanups and integration of the | |
152 | PCMCIA subsystem into the Linux kernel device driver model more | |
153 | difficult. The features provided by cardmgr and cardctl are either | |
154 | handled by the kernel itself now or are available in the new | |
155 | pcmciautils package available at | |
156 | http://kernel.org/pub/linux/utils/kernel/pcmcia/ | |
157 | Who: Dominik Brodowski <linux@brodo.de> | |
7af4cc3f HW |
158 | |
159 | --------------------------- | |
160 | ||
7058cb02 EB |
161 | What: sys_sysctl |
162 | When: September 2010 | |
163 | Option: CONFIG_SYSCTL_SYSCALL | |
164 | Why: The same information is available in a more convenient from | |
165 | /proc/sys, and none of the sysctl variables appear to be | |
166 | important performance wise. | |
167 | ||
168 | Binary sysctls are a long standing source of subtle kernel | |
169 | bugs and security issues. | |
170 | ||
171 | When I looked several months ago all I could find after | |
172 | searching several distributions were 5 user space programs and | |
173 | glibc (which falls back to /proc/sys) using this syscall. | |
174 | ||
175 | The man page for sysctl(2) documents it as unusable for user | |
176 | space programs. | |
177 | ||
178 | sysctl(2) is not generally ABI compatible to a 32bit user | |
179 | space application on a 64bit and a 32bit kernel. | |
180 | ||
181 | For the last several months the policy has been no new binary | |
182 | sysctls and no one has put forward an argument to use them. | |
183 | ||
184 | Binary sysctls issues seem to keep happening appearing so | |
185 | properly deprecating them (with a warning to user space) and a | |
186 | 2 year grace warning period will mean eventually we can kill | |
187 | them and end the pain. | |
188 | ||
189 | In the mean time individual binary sysctls can be dealt with | |
190 | in a piecewise fashion. | |
191 | ||
192 | Who: Eric Biederman <ebiederm@xmission.com> | |
193 | ||
194 | --------------------------- | |
195 | ||
ac515898 CH |
196 | What: remove EXPORT_SYMBOL(kernel_thread) |
197 | When: August 2006 | |
198 | Files: arch/*/kernel/*_ksyms.c | |
f0a594c1 | 199 | Check: kernel_thread |
ac515898 CH |
200 | Why: kernel_thread is a low-level implementation detail. Drivers should |
201 | use the <linux/kthread.h> API instead which shields them from | |
202 | implementation details and provides a higherlevel interface that | |
203 | prevents bugs and code duplication | |
204 | Who: Christoph Hellwig <hch@lst.de> | |
205 | ||
206 | --------------------------- | |
207 | ||
f71d20e9 AV |
208 | What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports |
209 | (temporary transition config option provided until then) | |
210 | The transition config option will also be removed at the same time. | |
211 | When: before 2.6.19 | |
212 | Why: Unused symbols are both increasing the size of the kernel binary | |
213 | and are often a sign of "wrong API" | |
214 | Who: Arjan van de Ven <arjan@linux.intel.com> | |
215 | ||
216 | --------------------------- | |
217 | ||
d81d9d6b | 218 | What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment |
acbd39fb | 219 | When: October 2008 |
d81d9d6b KS |
220 | Why: The stacking of class devices makes these values misleading and |
221 | inconsistent. | |
222 | Class devices should not carry any of these properties, and bus | |
223 | devices have SUBSYTEM and DRIVER as a replacement. | |
224 | Who: Kay Sievers <kay.sievers@suse.de> | |
225 | ||
226 | --------------------------- | |
6c805d2c | 227 | |
b981c591 | 228 | What: ACPI procfs interface |
8b8eb7d8 ZR |
229 | When: July 2008 |
230 | Why: ACPI sysfs conversion should be finished by January 2008. | |
231 | ACPI procfs interface will be removed in July 2008 so that | |
232 | there is enough time for the user space to catch up. | |
b981c591 ZR |
233 | Who: Zhang Rui <rui.zhang@intel.com> |
234 | ||
235 | --------------------------- | |
236 | ||
1bb67c25 LB |
237 | What: /proc/acpi/button |
238 | When: August 2007 | |
239 | Why: /proc/acpi/button has been replaced by events to the input layer | |
240 | since 2.6.20. | |
241 | Who: Len Brown <len.brown@intel.com> | |
242 | ||
243 | --------------------------- | |
54b290a2 | 244 | |
14e04fb3 LB |
245 | What: /proc/acpi/event |
246 | When: February 2008 | |
247 | Why: /proc/acpi/event has been replaced by events via the input layer | |
248 | and netlink since 2.6.23. | |
249 | Who: Len Brown <len.brown@intel.com> | |
250 | ||
251 | --------------------------- | |
252 | ||
914d97fd | 253 | What: i386/x86_64 bzImage symlinks |
19b4e7f4 | 254 | When: April 2010 |
914d97fd TG |
255 | |
256 | Why: The i386/x86_64 merge provides a symlink to the old bzImage | |
257 | location so not yet updated user space tools, e.g. package | |
258 | scripts, do not break. | |
259 | Who: Thomas Gleixner <tglx@linutronix.de> | |
038a5008 LT |
260 | |
261 | --------------------------- | |
262 | ||
f9ef8a23 | 263 | What (Why): |
079aa88f JE |
264 | - xt_recent: the old ipt_recent proc dir |
265 | (superseded by /proc/net/xt_recent) | |
266 | ||
f9ef8a23 JE |
267 | When: January 2009 or Linux 2.7.0, whichever comes first |
268 | Why: Superseded by newer revisions or modules | |
269 | Who: Jan Engelhardt <jengelh@computergmbh.de> | |
eb189d8b MB |
270 | |
271 | --------------------------- | |
272 | ||
8a0cecff DB |
273 | What: GPIO autorequest on gpio_direction_{input,output}() in gpiolib |
274 | When: February 2010 | |
275 | Why: All callers should use explicit gpio_request()/gpio_free(). | |
276 | The autorequest mechanism in gpiolib was provided mostly as a | |
277 | migration aid for legacy GPIO interfaces (for SOC based GPIOs). | |
278 | Those users have now largely migrated. Platforms implementing | |
279 | the GPIO interfaces without using gpiolib will see no changes. | |
280 | Who: David Brownell <dbrownell@users.sourceforge.net> | |
281 | --------------------------- | |
282 | ||
eb189d8b | 283 | What: b43 support for firmware revision < 410 |
c557289c MB |
284 | When: The schedule was July 2008, but it was decided that we are going to keep the |
285 | code as long as there are no major maintanance headaches. | |
286 | So it _could_ be removed _any_ time now, if it conflicts with something new. | |
eb189d8b MB |
287 | Why: The support code for the old firmware hurts code readability/maintainability |
288 | and slightly hurts runtime performance. Bugfixes for the old firmware | |
289 | are not provided by Broadcom anymore. | |
290 | Who: Michael Buesch <mb@bu3sch.de> | |
e88bb415 DM |
291 | |
292 | --------------------------- | |
293 | ||
52f7c21b MF |
294 | What: /sys/o2cb symlink |
295 | When: January 2010 | |
296 | Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb | |
297 | exists as a symlink for backwards compatibility for old versions of | |
298 | ocfs2-tools. 2 years should be sufficient time to phase in new versions | |
299 | which know to look in /sys/fs/o2cb. | |
300 | Who: ocfs2-devel@oss.oracle.com | |
d2f5e808 MW |
301 | |
302 | --------------------------- | |
303 | ||
2584e517 RT |
304 | What: Ability for non root users to shm_get hugetlb pages based on mlock |
305 | resource limits | |
306 | When: 2.6.31 | |
307 | Why: Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or | |
308 | have CAP_IPC_LOCK to be able to allocate shm segments backed by | |
309 | huge pages. The mlock based rlimit check to allow shm hugetlb is | |
310 | inconsistent with mmap based allocations. Hence it is being | |
311 | deprecated. | |
312 | Who: Ravikiran Thirumalai <kiran@scalex86.org> | |
313 | ||
314 | --------------------------- | |
315 | ||
16d75239 RH |
316 | What: CONFIG_THERMAL_HWMON |
317 | When: January 2009 | |
318 | Why: This option was introduced just to allow older lm-sensors userspace | |
319 | to keep working over the upgrade to 2.6.26. At the scheduled time of | |
320 | removal fixed lm-sensors (2.x or 3.x) should be readily available. | |
321 | Who: Rene Herman <rene.herman@gmail.com> | |
22bb1be4 JB |
322 | |
323 | --------------------------- | |
324 | ||
325 | What: Code that is now under CONFIG_WIRELESS_EXT_SYSFS | |
326 | (in net/core/net-sysfs.c) | |
327 | When: After the only user (hal) has seen a release with the patches | |
328 | for enough time, probably some time in 2010. | |
329 | Why: Over 1K .text/.data size reduction, data is available in other | |
330 | ways (ioctls) | |
331 | Who: Johannes Berg <johannes@sipsolutions.net> | |
58401572 KPO |
332 | |
333 | --------------------------- | |
334 | ||
335 | What: CONFIG_NF_CT_ACCT | |
336 | When: 2.6.29 | |
337 | Why: Accounting can now be enabled/disabled without kernel recompilation. | |
338 | Currently used only to set a default value for a feature that is also | |
339 | controlled by a kernel/module/sysfs/sysctl parameter. | |
340 | Who: Krzysztof Piotr Oledzki <ole@ans.pl> | |
341 | ||
46dfa040 FT |
342 | --------------------------- |
343 | ||
753b7aea DJ |
344 | What: sysfs ui for changing p4-clockmod parameters |
345 | When: September 2009 | |
346 | Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and | |
347 | e088e4c9cdb618675874becb91b2fd581ee707e6. | |
348 | Removal is subject to fixing any remaining bugs in ACPI which may | |
349 | cause the thermal throttling not to happen at the right time. | |
350 | Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com> | |
0e57aa11 TG |
351 | |
352 | ----------------------------- | |
353 | ||
354 | What: __do_IRQ all in one fits nothing interrupt handler | |
355 | When: 2.6.32 | |
356 | Why: __do_IRQ was kept for easy migration to the type flow handlers. | |
357 | More than two years of migration time is enough. | |
358 | Who: Thomas Gleixner <tglx@linutronix.de> | |
cb065c06 TG |
359 | |
360 | ----------------------------- | |
361 | ||
f110ca48 AC |
362 | What: fakephp and associated sysfs files in /sys/bus/pci/slots/ |
363 | When: 2011 | |
364 | Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to | |
365 | represent a machine's physical PCI slots. The change in semantics | |
366 | had userspace implications, as the hotplug core no longer allowed | |
367 | drivers to create multiple sysfs files per physical slot (required | |
368 | for multi-function devices, e.g.). fakephp was seen as a developer's | |
369 | tool only, and its interface changed. Too late, we learned that | |
370 | there were some users of the fakephp interface. | |
371 | ||
372 | In 2.6.30, the original fakephp interface was restored. At the same | |
373 | time, the PCI core gained the ability that fakephp provided, namely | |
374 | function-level hot-remove and hot-add. | |
375 | ||
376 | Since the PCI core now provides the same functionality, exposed in: | |
377 | ||
378 | /sys/bus/pci/rescan | |
379 | /sys/bus/pci/devices/.../remove | |
380 | /sys/bus/pci/devices/.../rescan | |
381 | ||
382 | there is no functional reason to maintain fakephp as well. | |
383 | ||
384 | We will keep the existing module so that 'modprobe fakephp' will | |
385 | present the old /sys/bus/pci/slots/... interface for compatibility, | |
386 | but users are urged to migrate their applications to the API above. | |
387 | ||
388 | After a reasonable transition period, we will remove the legacy | |
389 | fakephp interface. | |
390 | Who: Alex Chiang <achiang@hp.com> | |
3f307fb3 JD |
391 | |
392 | --------------------------- | |
393 | ||
c64fb016 JB |
394 | What: CONFIG_RFKILL_INPUT |
395 | When: 2.6.33 | |
396 | Why: Should be implemented in userspace, policy daemon. | |
397 | Who: Johannes Berg <johannes@sipsolutions.net> | |
9cbc1cb8 | 398 | |
cdc321ff EP |
399 | --------------------------- |
400 | ||
401 | What: CONFIG_INOTIFY | |
402 | When: 2.6.33 | |
403 | Why: last user (audit) will be converted to the newer more generic | |
404 | and more easily maintained fsnotify subsystem | |
405 | Who: Eric Paris <eparis@redhat.com> | |
406 | ||
45f458e9 AK |
407 | ---------------------------- |
408 | ||
37c90e88 | 409 | What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be |
410 | exported interface anymore. | |
411 | When: 2.6.33 | |
412 | Why: cpu_policy_rwsem has a new cleaner definition making it local to | |
413 | cpufreq core and contained inside cpufreq.c. Other dependent | |
414 | drivers should not use it in order to safely avoid lockdep issues. | |
415 | Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> | |
93fe4483 TH |
416 | |
417 | ---------------------------- | |
418 | ||
419 | What: sound-slot/service-* module aliases and related clutters in | |
420 | sound/sound_core.c | |
421 | When: August 2010 | |
422 | Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR | |
423 | (14) and requests modules using custom sound-slot/service-* | |
424 | module aliases. The only benefit of doing this is allowing | |
425 | use of custom module aliases which might as well be considered | |
426 | a bug at this point. This preemptive claiming prevents | |
427 | alternative OSS implementations. | |
428 | ||
429 | Till the feature is removed, the kernel will be requesting | |
430 | both sound-slot/service-* and the standard char-major-* module | |
431 | aliases and allow turning off the pre-claiming selectively via | |
432 | CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss | |
433 | kernel parameter. | |
434 | ||
435 | After the transition phase is complete, both the custom module | |
436 | aliases and switches to disable it will go away. This removal | |
437 | will also allow making ALSA OSS emulation independent of | |
438 | sound_core. The dependency will be broken then too. | |
439 | Who: Tejun Heo <tj@kernel.org> | |
d0153ca3 AK |
440 | |
441 | ---------------------------- | |
442 | ||
443 | What: Support for VMware's guest paravirtuliazation technique [VMI] will be | |
444 | dropped. | |
445 | When: 2.6.37 or earlier. | |
446 | Why: With the recent innovations in CPU hardware acceleration technologies | |
447 | from Intel and AMD, VMware ran a few experiments to compare these | |
448 | techniques to guest paravirtualization technique on VMware's platform. | |
449 | These hardware assisted virtualization techniques have outperformed the | |
450 | performance benefits provided by VMI in most of the workloads. VMware | |
451 | expects that these hardware features will be ubiquitous in a couple of | |
452 | years, as a result, VMware has started a phased retirement of this | |
453 | feature from the hypervisor. We will be removing this feature from the | |
454 | Kernel too. Right now we are targeting 2.6.37 but can retire earlier if | |
455 | technical reasons (read opportunity to remove major chunk of pvops) | |
456 | arise. | |
457 | ||
458 | Please note that VMI has always been an optimization and non-VMI kernels | |
459 | still work fine on VMware's platform. | |
460 | Latest versions of VMware's product which support VMI are, | |
461 | Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence | |
462 | releases for these products will continue supporting VMI. | |
463 | ||
464 | For more details about VMI retirement take a look at this, | |
465 | http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html | |
466 | ||
467 | Who: Alok N Kataria <akataria@vmware.com> | |
468 | ||
469 | ---------------------------- | |
b180d050 JD |
470 | |
471 | What: adt7473 hardware monitoring driver | |
472 | When: February 2010 | |
473 | Why: Obsoleted by the adt7475 driver. | |
474 | Who: Jean Delvare <khali@linux-fr.org> | |
475 | ||
476 | --------------------------- | |
728900f6 CC |
477 | What: Support for lcd_switch and display_get in asus-laptop driver |
478 | When: March 2010 | |
479 | Why: These two features use non-standard interfaces. There are the | |
480 | only features that really need multiple path to guess what's | |
481 | the right method name on a specific laptop. | |
482 | ||
483 | Removing them will allow to remove a lot of code an significantly | |
484 | clean the drivers. | |
485 | ||
486 | This will affect the backlight code which won't be able to know | |
487 | if the backlight is on or off. The platform display file will also be | |
488 | write only (like the one in eeepc-laptop). | |
489 | ||
490 | This should'nt affect a lot of user because they usually know | |
491 | when their display is on or off. | |
492 | ||
493 | Who: Corentin Chary <corentin.chary@gmail.com> | |
494 | ||
495 | ---------------------------- | |
ceafe1d2 HG |
496 | |
497 | What: usbvideo quickcam_messenger driver | |
498 | When: 2.6.35 | |
499 | Files: drivers/media/video/usbvideo/quickcam_messenger.[ch] | |
500 | Why: obsolete v4l1 driver replaced by gspca_stv06xx | |
501 | Who: Hans de Goede <hdegoede@redhat.com> | |
502 | ||
503 | ---------------------------- | |
504 | ||
505 | What: ov511 v4l1 driver | |
506 | When: 2.6.35 | |
507 | Files: drivers/media/video/ov511.[ch] | |
508 | Why: obsolete v4l1 driver replaced by gspca_ov519 | |
509 | Who: Hans de Goede <hdegoede@redhat.com> | |
510 | ||
511 | ---------------------------- | |
512 | ||
513 | What: w9968cf v4l1 driver | |
514 | When: 2.6.35 | |
515 | Files: drivers/media/video/w9968cf*.[ch] | |
516 | Why: obsolete v4l1 driver replaced by gspca_ov519 | |
517 | Who: Hans de Goede <hdegoede@redhat.com> | |
518 | ||
519 | ---------------------------- | |
520 | ||
521 | What: ovcamchip sensor framework | |
522 | When: 2.6.35 | |
523 | Files: drivers/media/video/ovcamchip/* | |
524 | Why: Only used by obsoleted v4l1 drivers | |
525 | Who: Hans de Goede <hdegoede@redhat.com> | |
526 | ||
527 | ---------------------------- | |
528 | ||
529 | What: stv680 v4l1 driver | |
530 | When: 2.6.35 | |
531 | Files: drivers/media/video/stv680.[ch] | |
532 | Why: obsolete v4l1 driver replaced by gspca_stv0680 | |
533 | Who: Hans de Goede <hdegoede@redhat.com> | |
534 | ||
535 | ---------------------------- | |
536 | ||
537 | What: zc0301 v4l driver | |
538 | When: 2.6.35 | |
539 | Files: drivers/media/video/zc0301/* | |
540 | Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only | |
541 | supports 2 USB-ID's (because it only supports a limited set of | |
542 | sensors) wich are also supported by the gspca_zc3xx driver | |
543 | (which supports 53 USB-ID's in total) | |
544 | Who: Hans de Goede <hdegoede@redhat.com> | |
74e7e725 EM |
545 | |
546 | ---------------------------- | |
547 | ||
548 | What: corgikbd, spitzkbd, tosakbd driver | |
549 | When: 2.6.35 | |
550 | Files: drivers/input/keyboard/{corgi,spitz,tosa}kbd.c | |
551 | Why: We now have a generic GPIO based matrix keyboard driver that | |
552 | are fully capable of handling all the keys on these devices. | |
553 | The original drivers manipulate the GPIO registers directly | |
554 | and so are difficult to maintain. | |
555 | Who: Eric Miao <eric.y.miao@gmail.com> |