This is a note to let you know that I've just added the patch titled

    pch_dma: Use GFP_ATOMIC because called from interrupt context

to the 3.9-stable tree which can be found at:
    
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     pch_dma-use-gfp_atomic-because-called-from-interrupt-context.patch
and it can be found in the queue-3.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.


>From 5c1ef59168c485318e40ba485c1eba57d81d0faa Mon Sep 17 00:00:00 2001
From: Tomoya MORINAGA <[email protected]>
Date: Tue, 12 Feb 2013 11:25:33 +0900
Subject: pch_dma: Use GFP_ATOMIC because called from interrupt context

From: Tomoya MORINAGA <[email protected]>

commit 5c1ef59168c485318e40ba485c1eba57d81d0faa upstream.

pdc_desc_get() is called from pd_prep_slave_sg, and the function is
called from interrupt context(e.g. Uart driver "pch_uart.c").
In fact, I saw kernel error message.
So, GFP_ATOMIC must be used not GFP_NOIO.

Signed-off-by: Tomoya MORINAGA <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 drivers/dma/pch_dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/dma/pch_dma.c
+++ b/drivers/dma/pch_dma.c
@@ -476,7 +476,7 @@ static struct pch_dma_desc *pdc_desc_get
        dev_dbg(chan2dev(&pd_chan->chan), "scanned %d descriptors\n", i);
 
        if (!ret) {
-               ret = pdc_alloc_desc(&pd_chan->chan, GFP_NOIO);
+               ret = pdc_alloc_desc(&pd_chan->chan, GFP_ATOMIC);
                if (ret) {
                        spin_lock(&pd_chan->lock);
                        pd_chan->descs_allocated++;


Patches currently in stable-queue which might be from [email protected] are

queue-3.9/pch_dma-use-gfp_atomic-because-called-from-interrupt-context.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to