--- /dev/null
+From 880641bb9da2473e9ecf6c708d993b29928c1b3c Mon Sep 17 00:00:00 2001
+From: Jeff Moyer <jmoyer@redhat.com>
+Date: Mon, 5 Mar 2012 14:59:12 -0800
+Subject: aio: wake up waiters when freeing unused kiocbs
+
+From: Jeff Moyer <jmoyer@redhat.com>
+
+commit 880641bb9da2473e9ecf6c708d993b29928c1b3c upstream.
+
+Bart Van Assche reported a hung fio process when either hot-removing
+storage or when interrupting the fio process itself. The (pruned) call
+trace for the latter looks like so:
+
+ fio D 0000000000000001 0 6849 6848 0x00000004
+ ffff880092541b88 0000000000000046 ffff880000000000 ffff88012fa11dc0
+ ffff88012404be70 ffff880092541fd8 ffff880092541fd8 ffff880092541fd8
+ ffff880128b894d0 ffff88012404be70 ffff880092541b88 000000018106f24d
+ Call Trace:
+ schedule+0x3f/0x60
+ io_schedule+0x8f/0xd0
+ wait_for_all_aios+0xc0/0x100
+ exit_aio+0x55/0xc0
+ mmput+0x2d/0x110
+ exit_mm+0x10d/0x130
+ do_exit+0x671/0x860
+ do_group_exit+0x44/0xb0
+ get_signal_to_deliver+0x218/0x5a0
+ do_signal+0x65/0x700
+ do_notify_resume+0x65/0x80
+ int_signal+0x12/0x17
+
+The problem lies with the allocation batching code. It will
+opportunistically allocate kiocbs, and then trim back the list of iocbs
+when there is not enough room in the completion ring to hold all of the
+events.
+
+In the case above, what happens is that the pruning back of events ends
+up freeing up the last active request and the context is marked as dead,
+so it is thus responsible for waking up waiters. Unfortunately, the
+code does not check for this condition, so we end up with a hung task.
+
+Signed-off-by: Jeff Moyer <jmoyer@redhat.com>
+Reported-by: Bart Van Assche <bvanassche@acm.org>
+Tested-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/aio.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/aio.c
++++ b/fs/aio.c
+@@ -490,6 +490,8 @@ static void kiocb_batch_free(struct kioc
+ kmem_cache_free(kiocb_cachep, req);
+ ctx->reqs_active--;
+ }
++ if (unlikely(!ctx->reqs_active && ctx->dead))
++ wake_up_all(&ctx->wait);
+ spin_unlock_irq(&ctx->ctx_lock);
+ }
+
--- /dev/null
+From 62aca403657fe30e5235c5331e9871e676d9ea0a Mon Sep 17 00:00:00 2001
+From: Andrew Morton <akpm@linux-foundation.org>
+Date: Mon, 5 Mar 2012 14:59:19 -0800
+Subject: alpha: fix 32/64-bit bug in futex support
+
+From: Andrew Morton <akpm@linux-foundation.org>
+
+commit 62aca403657fe30e5235c5331e9871e676d9ea0a upstream.
+
+Michael Cree said:
+
+: : I have noticed some user space problems (pulseaudio crashes in pthread
+: : code, glibc/nptl test suite failures, java compiler freezes on SMP alpha
+: : systems) that arise when using a 2.6.39 or later kernel on Alpha.
+: : Bisecting between 2.6.38 and 2.6.39 (using glibc/nptl test suite as
+: : criterion for good/bad kernel) eventually leads to:
+: :
+: : 8d7718aa082aaf30a0b4989e1f04858952f941bc is the first bad commit
+: : commit 8d7718aa082aaf30a0b4989e1f04858952f941bc
+: : Author: Michel Lespinasse <walken@google.com>
+: : Date: Thu Mar 10 18:50:58 2011 -0800
+: :
+: : futex: Sanitize futex ops argument types
+: :
+: : Change futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic
+: : prototypes to use u32 types for the futex as this is the data type the
+: : futex core code uses all over the place.
+: :
+: : Looking at the commit I see there is a change of the uaddr argument in
+: : the Alpha architecture specific code for futexes from int to u32, but I
+: : don't see why this should cause a problem.
+
+Richard Henderson said:
+
+: futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
+: u32 oldval, u32 newval)
+: ...
+: : "r"(uaddr), "r"((long)oldval), "r"(newval)
+:
+:
+: There is no 32-bit compare instruction. These are implemented by
+: consistently extending the values to a 64-bit type. Since the
+: load instruction sign-extends, we want to sign-extend the other
+: quantity as well (despite the fact it's logically unsigned).
+:
+: So:
+:
+: - : "r"(uaddr), "r"((long)oldval), "r"(newval)
+: + : "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
+:
+: should do the trick.
+
+Michael said:
+
+: This fixes the glibc test suite failures and the pulseaudio related
+: crashes, but it does not fix the java compiiler lockups that I was (and
+: are still) observing. That is some other problem.
+
+Reported-by: Michael Cree <mcree@orcon.net.nz>
+Tested-by: Michael Cree <mcree@orcon.net.nz>
+Acked-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
+Cc: Richard Henderson <rth@twiddle.net>
+Cc: Michel Lespinasse <walken@google.com>
+Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
+Reviewed-by: Matt Turner <mattst88@gmail.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/alpha/include/asm/futex.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/alpha/include/asm/futex.h
++++ b/arch/alpha/include/asm/futex.h
+@@ -108,7 +108,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
+ " lda $31,3b-2b(%0)\n"
+ " .previous\n"
+ : "+r"(ret), "=&r"(prev), "=&r"(cmp)
+- : "r"(uaddr), "r"((long)oldval), "r"(newval)
++ : "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
+ : "memory");
+
+ *uval = prev;
--- /dev/null
+From e39d40c65dfd8390b50c03482ae9e289b8a8f351 Mon Sep 17 00:00:00 2001
+From: Gusakov Andrey <dron0gus@gmail.com>
+Date: Sat, 3 Mar 2012 07:32:36 +0900
+Subject: ARM: S3C24XX: DMA resume regression fix
+
+From: Gusakov Andrey <dron0gus@gmail.com>
+
+commit e39d40c65dfd8390b50c03482ae9e289b8a8f351 upstream.
+
+s3c2410_dma_suspend suspends channels from 0 to dma_channels.
+s3c2410_dma_resume resumes channels in reverse order. So
+pointer should be decremented instead of being incremented.
+
+Signed-off-by: Gusakov Andrey <dron0gus@gmail.com>
+Reviewed-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/plat-s3c24xx/dma.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/plat-s3c24xx/dma.c
++++ b/arch/arm/plat-s3c24xx/dma.c
+@@ -1249,7 +1249,7 @@ static void s3c2410_dma_resume(void)
+ struct s3c2410_dma_chan *cp = s3c2410_chans + dma_channels - 1;
+ int channel;
+
+- for (channel = dma_channels - 1; channel >= 0; cp++, channel--)
++ for (channel = dma_channels - 1; channel >= 0; cp--, channel--)
+ s3c2410_dma_resume_chan(cp);
+ }
+
--- /dev/null
+From 8f2f748b0656257153bcf0941df8d6060acc5ca6 Mon Sep 17 00:00:00 2001
+From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
+Date: Thu, 23 Feb 2012 15:27:15 +0530
+Subject: CPU hotplug, cpusets, suspend: Don't touch cpusets during suspend/resume
+
+From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
+
+commit 8f2f748b0656257153bcf0941df8d6060acc5ca6 upstream.
+
+Currently, during CPU hotplug, the cpuset callbacks modify the cpusets
+to reflect the state of the system, and this handling is asymmetric.
+That is, upon CPU offline, that CPU is removed from all cpusets. However
+when it comes back online, it is put back only to the root cpuset.
+
+This gives rise to a significant problem during suspend/resume. During
+suspend, we offline all non-boot cpus and during resume we online them back.
+Which means, after a resume, all cpusets (except the root cpuset) will be
+restricted to just one single CPU (the boot cpu). But the whole point of
+suspend/resume is to restore the system to a state which is as close as
+possible to how it was before suspend.
+
+So to fix this, don't touch cpusets during suspend/resume. That is, modify
+the cpuset-related CPU hotplug callback to just ignore CPU hotplug when it
+is initiated as part of the suspend/resume sequence.
+
+Reported-by: Prashanth Nageshappa <prashanth@linux.vnet.ibm.com>
+Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Link: http://lkml.kernel.org/r/4F460D7B.1020703@linux.vnet.ibm.com
+Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/sched.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/kernel/sched.c
++++ b/kernel/sched.c
+@@ -8001,7 +8001,7 @@ int __init sched_create_sysfs_power_savi
+ static int cpuset_cpu_active(struct notifier_block *nfb, unsigned long action,
+ void *hcpu)
+ {
+- switch (action & ~CPU_TASKS_FROZEN) {
++ switch (action) {
+ case CPU_ONLINE:
+ case CPU_DOWN_FAILED:
+ cpuset_update_active_cpus();
+@@ -8014,7 +8014,7 @@ static int cpuset_cpu_active(struct noti
+ static int cpuset_cpu_inactive(struct notifier_block *nfb, unsigned long action,
+ void *hcpu)
+ {
+- switch (action & ~CPU_TASKS_FROZEN) {
++ switch (action) {
+ case CPU_DOWN_PREPARE:
+ cpuset_update_active_cpus();
+ return NOTIFY_OK;
--- /dev/null
+From 52abb700e16a9aa4cbc03f3d7f80206cbbc80680 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Tue, 6 Mar 2012 23:18:54 +0100
+Subject: genirq: Clear action->thread_mask if IRQ_ONESHOT is not set
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 52abb700e16a9aa4cbc03f3d7f80206cbbc80680 upstream.
+
+Xommit ac5637611(genirq: Unmask oneshot irqs when thread was not woken)
+fails to unmask when a !IRQ_ONESHOT threaded handler is handled by
+handle_level_irq.
+
+This happens because thread_mask is or'ed unconditionally in
+irq_wake_thread(), but for !IRQ_ONESHOT interrupts never cleared. So
+the check for !desc->thread_active fails and keeps the interrupt
+disabled.
+
+Keep the thread_mask zero for !IRQ_ONESHOT interrupts.
+
+Document the thread_mask magic while at it.
+
+Reported-and-tested-by: Sven Joachim <svenjoac@gmx.de>
+Reported-and-tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/irq/manage.c | 44 ++++++++++++++++++++++++++++++++++++++------
+ 1 file changed, 38 insertions(+), 6 deletions(-)
+
+--- a/kernel/irq/manage.c
++++ b/kernel/irq/manage.c
+@@ -985,6 +985,11 @@ __setup_irq(unsigned int irq, struct irq
+
+ /* add new interrupt at end of irq queue */
+ do {
++ /*
++ * Or all existing action->thread_mask bits,
++ * so we can find the next zero bit for this
++ * new action.
++ */
+ thread_mask |= old->thread_mask;
+ old_ptr = &old->next;
+ old = *old_ptr;
+@@ -993,14 +998,41 @@ __setup_irq(unsigned int irq, struct irq
+ }
+
+ /*
+- * Setup the thread mask for this irqaction. Unlikely to have
+- * 32 resp 64 irqs sharing one line, but who knows.
++ * Setup the thread mask for this irqaction for ONESHOT. For
++ * !ONESHOT irqs the thread mask is 0 so we can avoid a
++ * conditional in irq_wake_thread().
+ */
+- if (new->flags & IRQF_ONESHOT && thread_mask == ~0UL) {
+- ret = -EBUSY;
+- goto out_mask;
++ if (new->flags & IRQF_ONESHOT) {
++ /*
++ * Unlikely to have 32 resp 64 irqs sharing one line,
++ * but who knows.
++ */
++ if (thread_mask == ~0UL) {
++ ret = -EBUSY;
++ goto out_mask;
++ }
++ /*
++ * The thread_mask for the action is or'ed to
++ * desc->thread_active to indicate that the
++ * IRQF_ONESHOT thread handler has been woken, but not
++ * yet finished. The bit is cleared when a thread
++ * completes. When all threads of a shared interrupt
++ * line have completed desc->threads_active becomes
++ * zero and the interrupt line is unmasked. See
++ * handle.c:irq_wake_thread() for further information.
++ *
++ * If no thread is woken by primary (hard irq context)
++ * interrupt handlers, then desc->threads_active is
++ * also checked for zero to unmask the irq line in the
++ * affected hard irq flow handlers
++ * (handle_[fasteoi|level]_irq).
++ *
++ * The new action gets the first zero bit of
++ * thread_mask assigned. See the loop above which or's
++ * all existing action->thread_mask bits.
++ */
++ new->thread_mask = 1 << ffz(thread_mask);
+ }
+- new->thread_mask = 1 << ffz(thread_mask);
+
+ if (!shared) {
+ init_waitqueue_head(&desc->wait_for_threads);
--- /dev/null
+From ef8781989a1bcd05aa47e853917c37df44917194 Mon Sep 17 00:00:00 2001
+From: Ludovic Desroches <ludovic.desroches@atmel.com>
+Date: Thu, 9 Feb 2012 16:33:53 +0100
+Subject: mmc: atmel-mci: don't use dma features when using DMA with no chan available
+
+From: Ludovic Desroches <ludovic.desroches@atmel.com>
+
+commit ef8781989a1bcd05aa47e853917c37df44917194 upstream.
+
+Some callbacks are set too early -- i.e. we can have dma capabilities but
+we can't get a dma channel. So wait to get the dma channel before setting
+callbacks and change logs consequently.
+
+Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
+Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
+Signed-off-by: Chris Ball <cjb@laptop.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/atmel-mci.c | 21 ++++++++++-----------
+ 1 file changed, 10 insertions(+), 11 deletions(-)
+
+--- a/drivers/mmc/host/atmel-mci.c
++++ b/drivers/mmc/host/atmel-mci.c
+@@ -1944,12 +1944,12 @@ static bool atmci_filter(struct dma_chan
+ }
+ }
+
+-static void atmci_configure_dma(struct atmel_mci *host)
++static bool atmci_configure_dma(struct atmel_mci *host)
+ {
+ struct mci_platform_data *pdata;
+
+ if (host == NULL)
+- return;
++ return false;
+
+ pdata = host->pdev->dev.platform_data;
+
+@@ -1966,12 +1966,15 @@ static void atmci_configure_dma(struct a
+ host->dma.chan =
+ dma_request_channel(mask, atmci_filter, pdata->dma_slave);
+ }
+- if (!host->dma.chan)
+- dev_notice(&host->pdev->dev, "DMA not available, using PIO\n");
+- else
++ if (!host->dma.chan) {
++ dev_warn(&host->pdev->dev, "no DMA channel available\n");
++ return false;
++ } else {
+ dev_info(&host->pdev->dev,
+ "Using %s for DMA transfers\n",
+ dma_chan_name(host->dma.chan));
++ return true;
++ }
+ }
+
+ static inline unsigned int atmci_get_version(struct atmel_mci *host)
+@@ -2081,8 +2084,7 @@ static int __init atmci_probe(struct pla
+
+ /* Get MCI capabilities and set operations according to it */
+ atmci_get_cap(host);
+- if (host->caps.has_dma) {
+- dev_info(&pdev->dev, "using DMA\n");
++ if (host->caps.has_dma && atmci_configure_dma(host)) {
+ host->prepare_data = &atmci_prepare_data_dma;
+ host->submit_data = &atmci_submit_data_dma;
+ host->stop_transfer = &atmci_stop_transfer_dma;
+@@ -2092,15 +2094,12 @@ static int __init atmci_probe(struct pla
+ host->submit_data = &atmci_submit_data_pdc;
+ host->stop_transfer = &atmci_stop_transfer_pdc;
+ } else {
+- dev_info(&pdev->dev, "no DMA, no PDC\n");
++ dev_info(&pdev->dev, "using PIO\n");
+ host->prepare_data = &atmci_prepare_data;
+ host->submit_data = &atmci_submit_data;
+ host->stop_transfer = &atmci_stop_transfer;
+ }
+
+- if (host->caps.has_dma)
+- atmci_configure_dma(host);
+-
+ platform_set_drvdata(pdev, host);
+
+ /* We need at least one slot to succeed */
--- /dev/null
+From 5b6b0ad6e572b32a641116aaa5f897ffebe31e44 Mon Sep 17 00:00:00 2001
+From: Sascha Hauer <s.hauer@pengutronix.de>
+Date: Fri, 17 Feb 2012 11:51:49 +0100
+Subject: mmc: sdhci-esdhc-imx: fix for mmc cards on i.MX5
+
+From: Sascha Hauer <s.hauer@pengutronix.de>
+
+commit 5b6b0ad6e572b32a641116aaa5f897ffebe31e44 upstream.
+
+On i.MX53 we have to write a special SDHCI_CMD_ABORTCMD to the
+SDHCI_TRANSFER_MODE register during a MMC_STOP_TRANSMISSION
+command. This works for SD cards. However, with MMC cards
+the MMC_SET_BLOCK_COUNT command is used instead, but this
+needs the same handling. Fix MMC cards by testing for the
+MMC_SET_BLOCK_COUNT command aswell. Tested on a custom i.MX53
+board with a Transcend MMC+ card and eMMC.
+
+The kernel started used MMC_SET_BLOCK_COUNT in 3.0, so this
+is a regression for these boards introduced in 3.0; it should
+go to 3.0/3.1/3.2-stable.
+
+Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
+Acked-by: Shawn Guo <shawn.guo@linaro.org>
+Signed-off-by: Chris Ball <cjb@laptop.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-esdhc-imx.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-esdhc-imx.c
++++ b/drivers/mmc/host/sdhci-esdhc-imx.c
+@@ -269,8 +269,9 @@ static void esdhc_writew_le(struct sdhci
+ imx_data->scratchpad = val;
+ return;
+ case SDHCI_COMMAND:
+- if ((host->cmd->opcode == MMC_STOP_TRANSMISSION)
+- && (imx_data->flags & ESDHC_FLAG_MULTIBLK_NO_INT))
++ if ((host->cmd->opcode == MMC_STOP_TRANSMISSION ||
++ host->cmd->opcode == MMC_SET_BLOCK_COUNT) &&
++ (imx_data->flags & ESDHC_FLAG_MULTIBLK_NO_INT))
+ val |= SDHCI_CMD_ABORTCMD;
+
+ if (is_imx6q_usdhc(imx_data)) {
--- /dev/null
+From ee932bf9acb2e2c6a309e808000f24856330e3f9 Mon Sep 17 00:00:00 2001
+From: Scott Talbert <talbert@techie.net>
+Date: Tue, 21 Feb 2012 13:06:00 +0000
+Subject: Move Logitech Harmony 900 from cdc_ether to zaurus
+
+From: Scott Talbert <talbert@techie.net>
+
+commit ee932bf9acb2e2c6a309e808000f24856330e3f9 upstream.
+
+In the current kernel implementation, the Logitech Harmony 900 remote
+control is matched to the cdc_ether driver through the generic
+USB_CDC_SUBCLASS_MDLM entry. However, this device appears to be of the
+pseudo-MDLM (Belcarra) type, rather than the standard one. This patch
+blacklists the Harmony 900 from the cdc_ether driver and whitelists it for
+the pseudo-MDLM driver in zaurus.
+
+Signed-off-by: Scott Talbert <talbert@techie.net>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/usb/cdc_ether.c | 7 +++++++
+ drivers/net/usb/zaurus.c | 7 +++++++
+ 2 files changed, 14 insertions(+)
+
+--- a/drivers/net/usb/cdc_ether.c
++++ b/drivers/net/usb/cdc_ether.c
+@@ -570,6 +570,13 @@ static const struct usb_device_id produc
+ .driver_info = 0,
+ },
+
++/* Logitech Harmony 900 - uses the pseudo-MDLM (BLAN) driver */
++{
++ USB_DEVICE_AND_INTERFACE_INFO(0x046d, 0xc11f, USB_CLASS_COMM,
++ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
++ .driver_info = 0,
++},
++
+ /*
+ * WHITELIST!!!
+ *
+--- a/drivers/net/usb/zaurus.c
++++ b/drivers/net/usb/zaurus.c
+@@ -349,6 +349,13 @@ static const struct usb_device_id produc
+ ZAURUS_MASTER_INTERFACE,
+ .driver_info = OLYMPUS_MXL_INFO,
+ },
++
++/* Logitech Harmony 900 - uses the pseudo-MDLM (BLAN) driver */
++{
++ USB_DEVICE_AND_INTERFACE_INFO(0x046d, 0xc11f, USB_CLASS_COMM,
++ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
++ .driver_info = (unsigned long) &bogus_mdlm_info,
++},
+ { }, // END
+ };
+ MODULE_DEVICE_TABLE(usb, products);
regset-return-efault-not-eio-on-host-side-memory-fault.patch
mfd-fix-acpi-conflict-check.patch
mfd-test-for-jack-detection-when-deciding-if-wm8994-should-suspend.patch
+genirq-clear-action-thread_mask-if-irq_oneshot-is-not-set.patch
+arm-s3c24xx-dma-resume-regression-fix.patch
+move-logitech-harmony-900-from-cdc_ether-to-zaurus.patch
+cpu-hotplug-cpusets-suspend-don-t-touch-cpusets-during-suspend-resume.patch
+alpha-fix-32-64-bit-bug-in-futex-support.patch
+mmc-atmel-mci-don-t-use-dma-features-when-using-dma-with-no-chan-available.patch
+mmc-sdhci-esdhc-imx-fix-for-mmc-cards-on-i.mx5.patch
+aio-wake-up-waiters-when-freeing-unused-kiocbs.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
