From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: James Hogan <james.hogan@imgtec.com>, Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org, stable@vger.kernel.org
Subject: Re: [PATCH] MIPS: dma-default: Fix 32-bit fall back to GFP_DMA
Date: Thu, 26 Mar 2015 21:18:50 +0300 [thread overview]
Message-ID: <55144D8A.8050004@cogentembedded.com> (raw)
In-Reply-To: <1427388993-17697-1-git-send-email-james.hogan@imgtec.com>
Hello.
On 03/26/2015 07:56 PM, James Hogan wrote:
> If there is a DMA zone (usually 24bit = 16MB I believe), but no DMA32
> zone, as is the case for some 32-bit kernels, then massage_gfp_flags()
> will cause DMA memory allocated for devices with a 32..63-bit
> coherent_dma_mask to fall back to using __GFP_DMA, even though there may
> only be 32-bits of physical address available anyway.
> Correct that case to compare against a mask the size of phys_addr_t
> instead of always using a 64-bit mask.
> Fixes: a2e715a86c6d ("MIPS: DMA: Fix computation of DMA flags from device's coherent_dma_mask.")
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: linux-mips@linux-mips.org
> Cc: <stable@vger.kernel.org> # 2.6.36+
> ---
> This works around problems encountered on Malta with ethernet and IDE
> drivers being unable to allocate any coherent memory when the entire
> 16MB DMA zone is taken up with static kernel data (a separate problem),
> even though their coherent_dma_masks are 32-bit. This can happen when
> PROVE_RCU and PROVE_LOCKING are set, especially since commit
> 1413c0389333 ("lockdep: Increase static allocations") was applied in
> v3.16.
> ---
> arch/mips/mm/dma-default.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
> index af5f046e627e..501557026768 100644
> --- a/arch/mips/mm/dma-default.c
> +++ b/arch/mips/mm/dma-default.c
> @@ -100,7 +100,7 @@ static gfp_t massage_gfp_flags(const struct device *dev, gfp_t gfp)
> else
> #endif
> #if defined(CONFIG_ZONE_DMA) && !defined(CONFIG_ZONE_DMA32)
> - if (dev->coherent_dma_mask < DMA_BIT_MASK(64))
> + if (dev->coherent_dma_mask < DMA_BIT_MASK(sizeof(phys_addr_t)*8))
Cold you add spaces around *, just to be consisted with the other binary
operators? This seems a preferred kernel style anyway.
WBR, Sergei
prev parent reply other threads:[~2015-03-26 18:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 16:56 [PATCH] MIPS: dma-default: Fix 32-bit fall back to GFP_DMA James Hogan
2015-03-26 16:56 ` James Hogan
2015-03-26 18:18 ` Sergei Shtylyov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55144D8A.8050004@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=james.hogan@imgtec.com \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.