---------------------------
+What: x86 floppy disable_hlt
+When: 2012
+Why: ancient workaround of dubious utility clutters the
+ code used by everybody else.
+Who: Len Brown <len.brown@intel.com>
+
+---------------------------
+
+What: CONFIG_APM_CPU_IDLE, and its ability to call APM BIOS in idle
+When: 2012
+Why: This optional sub-feature of APM is of dubious reliability,
+ and ancient APM laptops are likely better served by calling HLT.
+ Deleting CONFIG_APM_CPU_IDLE allows x86 to stop exporting
+ the pm_idle function pointer to modules.
+Who: Len Brown <len.brown@intel.com>
+
+----------------------------
+
+What: x86_32 "no-hlt" cmdline param
+When: 2012
+Why: remove a branch from idle path, simplify code used by everybody.
+ This option disabled the use of HLT in idle and machine_halt()
+ for hardware that was flakey 15-years ago. Today we have
+ "idle=poll" that removed HLT from idle, and so if such a machine
+ is still running the upstream kernel, "idle=poll" is likely sufficient.
+Who: Len Brown <len.brown@intel.com>
+
+----------------------------
+
+What: x86 "idle=mwait" cmdline param
+When: 2012
+Why: simplify x86 idle code
+Who: Len Brown <len.brown@intel.com>
+
+----------------------------
+
What: PRISM54
When: 2.6.34
---------------------------
-What: AR9170USB
-When: 2.6.40
-
-Why: This driver is deprecated and the firmware is no longer
- maintained. The replacement driver "carl9170" has been
- around for a while, so the devices are still supported.
-
-Who: Christian Lamparter <chunkeey@googlemail.com>
-
----------------------------
-
What: IRQF_SAMPLE_RANDOM
Check: IRQF_SAMPLE_RANDOM
When: July 2009
What: CONFIG_ACPI_PROCFS_POWER
When: 2.6.39
Why: sysfs I/F for ACPI power devices, including AC and Battery,
- has been working in upstream kenrel since 2.6.24, Sep 2007.
+ has been working in upstream kernel since 2.6.24, Sep 2007.
In 2.6.37, we make the sysfs I/F always built in and this option
disabled by default.
Remove this option and the ACPI power procfs interface in 2.6.39.
---------------------------
-What: /sys/o2cb symlink
-When: January 2010
-Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb
- exists as a symlink for backwards compatibility for old versions of
- ocfs2-tools. 2 years should be sufficient time to phase in new versions
- which know to look in /sys/fs/o2cb.
-Who: ocfs2-devel@oss.oracle.com
-
----------------------------
-
What: Ability for non root users to shm_get hugetlb pages based on mlock
resource limits
When: 2.6.31
----------------------------
-What: capifs
-When: February 2011
-Files: drivers/isdn/capi/capifs.*
-Why: udev fully replaces this special file system that only contains CAPI
- NCCI TTY device nodes. User space (pppdcapiplugin) works without
- noticing the difference.
-Who: Jan Kiszka <jan.kiszka@web.de>
-
-----------------------------
-
What: KVM paravirt mmu host support
When: January 2011
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
----------------------------
-What: namespace cgroup (ns_cgroup)
-When: 2.6.38
-Why: The ns_cgroup leads to some problems:
- * cgroup creation is out-of-control
- * cgroup name can conflict when pids are looping
- * it is not possible to have a single process handling
- a lot of namespaces without falling in a exponential creation time
- * we may want to create a namespace without creating a cgroup
-
- The ns_cgroup is replaced by a compatibility flag 'clone_children',
- where a newly created cgroup will copy the parent cgroup values.
- The userspace has to manually create a cgroup and add a task to
- the 'tasks' file.
-Who: Daniel Lezcano <daniel.lezcano@free.fr>
-
-----------------------------
-
What: iwlwifi disable_hw_scan module parameters
When: 2.6.40
Why: Hareware scan is the prefer method for iwlwifi devices for
----------------------------
- What: cancel_rearming_delayed_work[queue]()
- When: 2.6.39
-
- Why: The functions have been superceded by cancel_delayed_work_sync()
- quite some time ago. The conversion is trivial and there is no
- in-kernel user left.
- Who: Tejun Heo <tj@kernel.org>
-
- ----------------------------
-
What: Legacy, non-standard chassis intrusion detection interface.
When: June 2011
Why: The adm9240, w83792d and w83793 hardware monitoring drivers have
Who: Jean Delvare <khali@linux-fr.org>
----------------------------
+
+What: Support for UVCIOC_CTRL_ADD in the uvcvideo driver
+When: 2.6.42
+Why: The information passed to the driver by this ioctl is now queried
+ dynamically from the device.
+Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+----------------------------
+
+What: Support for UVCIOC_CTRL_MAP_OLD in the uvcvideo driver
+When: 2.6.42
+Why: Used only by applications compiled against older driver versions.
+ Superseded by UVCIOC_CTRL_MAP which supports V4L2 menu controls.
+Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+----------------------------
+
+What: Support for UVCIOC_CTRL_GET and UVCIOC_CTRL_SET in the uvcvideo driver
+When: 2.6.42
+Why: Superseded by the UVCIOC_CTRL_QUERY ioctl.
+Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+----------------------------
+
+What: For VIDIOC_S_FREQUENCY the type field must match the device node's type.
+ If not, return -EINVAL.
+When: 3.2
+Why: It makes no sense to switch the tuner to radio mode by calling
+ VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by
+ calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a
+ move to more consistent handling of tv and radio tuners.
+Who: Hans Verkuil <hans.verkuil@cisco.com>
+
+----------------------------
+
+What: Opening a radio device node will no longer automatically switch the
+ tuner mode from tv to radio.
+When: 3.3
+Why: Just opening a V4L device should not change the state of the hardware
+ like that. It's very unexpected and against the V4L spec. Instead, you
+ switch to radio mode by calling VIDIOC_S_FREQUENCY. This is the second
+ and last step of the move to consistent handling of tv and radio tuners.
+Who: Hans Verkuil <hans.verkuil@cisco.com>
+
+----------------------------
* per-CPU workqueues:
*/
struct workqueue_struct {
- unsigned int flags; /* I: WQ_* flags */
+ unsigned int flags; /* W: WQ_* flags */
union {
struct cpu_workqueue_struct __percpu *pcpu;
struct cpu_workqueue_struct *single;
mayday_mask_t mayday_mask; /* cpus requesting rescue */
struct worker *rescuer; /* I: rescue worker */
+ int nr_drainers; /* W: drain in progress */
int saved_max_active; /* W: saved cwq max_active */
const char *name; /* I: workqueue name */
#ifdef CONFIG_LOCKDEP
debug_work_activate(work);
/* if dying, only works from the same workqueue are allowed */
- if (unlikely(wq->flags & WQ_DYING) &&
+ if (unlikely(wq->flags & WQ_DRAINING) &&
WARN_ON_ONCE(!is_chained_work(wq)))
return;
}
EXPORT_SYMBOL_GPL(flush_workqueue);
+ /**
+ * drain_workqueue - drain a workqueue
+ * @wq: workqueue to drain
+ *
+ * Wait until the workqueue becomes empty. While draining is in progress,
+ * only chain queueing is allowed. IOW, only currently pending or running
+ * work items on @wq can queue further work items on it. @wq is flushed
+ * repeatedly until it becomes empty. The number of flushing is detemined
+ * by the depth of chaining and should be relatively short. Whine if it
+ * takes too long.
+ */
+ void drain_workqueue(struct workqueue_struct *wq)
+ {
+ unsigned int flush_cnt = 0;
+ unsigned int cpu;
+
+ /*
+ * __queue_work() needs to test whether there are drainers, is much
+ * hotter than drain_workqueue() and already looks at @wq->flags.
+ * Use WQ_DRAINING so that queue doesn't have to check nr_drainers.
+ */
+ spin_lock(&workqueue_lock);
+ if (!wq->nr_drainers++)
+ wq->flags |= WQ_DRAINING;
+ spin_unlock(&workqueue_lock);
+ reflush:
+ flush_workqueue(wq);
+
+ for_each_cwq_cpu(cpu, wq) {
+ struct cpu_workqueue_struct *cwq = get_cwq(cpu, wq);
+
+ if (!cwq->nr_active && list_empty(&cwq->delayed_works))
+ continue;
+
+ if (++flush_cnt == 10 ||
+ (flush_cnt % 100 == 0 && flush_cnt <= 1000))
+ pr_warning("workqueue %s: flush on destruction isn't complete after %u tries\n",
+ wq->name, flush_cnt);
+ goto reflush;
+ }
+
+ spin_lock(&workqueue_lock);
+ if (!--wq->nr_drainers)
+ wq->flags &= ~WQ_DRAINING;
+ spin_unlock(&workqueue_lock);
+ }
+ EXPORT_SYMBOL_GPL(drain_workqueue);
+
static bool start_flush_work(struct work_struct *work, struct wq_barrier *barr,
bool wait_executing)
{
}
}
- /* just in case, make sure it's actually aligned
- * - this is affected by PERCPU() alignment in vmlinux.lds.S
- */
+ /* just in case, make sure it's actually aligned */
BUG_ON(!IS_ALIGNED(wq->cpu_wq.v, align));
return wq->cpu_wq.v ? 0 : -ENOMEM;
}
*/
void destroy_workqueue(struct workqueue_struct *wq)
{
- unsigned int flush_cnt = 0;
unsigned int cpu;
- /*
- * Mark @wq dying and drain all pending works. Once WQ_DYING is
- * set, only chain queueing is allowed. IOW, only currently
- * pending or running work items on @wq can queue further work
- * items on it. @wq is flushed repeatedly until it becomes empty.
- * The number of flushing is detemined by the depth of chaining and
- * should be relatively short. Whine if it takes too long.
- */
- wq->flags |= WQ_DYING;
- reflush:
- flush_workqueue(wq);
-
- for_each_cwq_cpu(cpu, wq) {
- struct cpu_workqueue_struct *cwq = get_cwq(cpu, wq);
-
- if (!cwq->nr_active && list_empty(&cwq->delayed_works))
- continue;
-
- if (++flush_cnt == 10 ||
- (flush_cnt % 100 == 0 && flush_cnt <= 1000))
- printk(KERN_WARNING "workqueue %s: flush on "
- "destruction isn't complete after %u tries\n",
- wq->name, flush_cnt);
- goto reflush;
- }
+ /* drain it before proceeding with destruction */
+ drain_workqueue(wq);
/*
* wq list is used to freeze wq, remove from list after