[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20091027191544S.fujita.tomonori@lab.ntt.co.jp>
Date: Tue, 27 Oct 2009 19:15:59 +0900
From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To: JBeulich@...ell.com
Cc: fujita.tomonori@....ntt.co.jp, mingo@...e.hu, yinghai@...nel.org,
tglx@...utronix.de, tiwai@...e.de, linux-kernel@...r.kernel.org,
jbarnes@...tuousgeek.org, hpa@...or.com
Subject: Re: [PATCH] x86: adjust GFP mask handling for coherent allocations
On Tue, 27 Oct 2009 09:47:32 +0000
"Jan Beulich" <JBeulich@...ell.com> wrote:
> >>> FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> 27.10.09 10:37 >>>
> >On Tue, 27 Oct 2009 09:23:38 +0000
> >"Jan Beulich" <JBeulich@...ell.com> wrote:
> >
> >> Because there's quite a few of them - just search for callers of
> >> dma_alloc_coherent() passing NULL as the first argument. Of course
> >> I'd rather see the fallback gone, but I think this requires cooperation
> >> from/action taken by the driver maintainers first. A first step might be
> >> to add a WRN_ON() for that case, but I don't see it being reasonable
> >> to eliminate the fallback right away. Hence, with it having got broken
> >> in .26 I think it is reasonable to fix it for the time being.
> >
> >Well, the most of them are drivers that nobody cares about (uses).
> >
> >What drivers did you hit this problem with?
>
> drivers/firmware/dell_rbu.c (on .27.x, and in particular with the derivation
> of __GFP_NORETRY from __GFP_DMA, which fortunately doesn't exist in
> newer kernels anymore).
I don't know anything about this driver (and even I'm not sure why
this driver uses dma_alloc_coherent) but why can't this driver use
rbu_device with dma API?
diff --git a/drivers/firmware/dell_rbu.c b/drivers/firmware/dell_rbu.c
index b4704e1..481b009 100644
--- a/drivers/firmware/dell_rbu.c
+++ b/drivers/firmware/dell_rbu.c
@@ -372,8 +372,8 @@ static void img_update_free(void)
memset(rbu_data.image_update_buffer, 0,
rbu_data.image_update_buffer_size);
if (rbu_data.dma_alloc == 1)
- dma_free_coherent(NULL, rbu_data.bios_image_size,
- rbu_data.image_update_buffer, dell_rbu_dmaaddr);
+ dma_free_coherent(&rbu_device->dev, rbu_data.bios_image_size,
+ rbu_data.image_update_buffer, dell_rbu_dmaaddr);
else
free_pages((unsigned long) rbu_data.image_update_buffer,
rbu_data.image_update_ordernum);
@@ -443,7 +443,7 @@ static int img_update_realloc(unsigned long size)
if (img_buf_phys_addr > BIOS_SCAN_LIMIT) {
free_pages((unsigned long) image_update_buffer, ordernum);
ordernum = -1;
- image_update_buffer = dma_alloc_coherent(NULL, size,
+ image_update_buffer = dma_alloc_coherent(&rbu_device->dev, size,
&dell_rbu_dmaaddr, GFP_KERNEL);
dma_alloc = 1;
}
@@ -699,6 +699,8 @@ static int __init dcdrbu_init(void)
"failed\n", __func__);
return PTR_ERR(rbu_device);
}
+ rbu_device->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ rbu_device->dev.dma_mask = &rbu_device->dev.coherent_dma_mask;
rc = sysfs_create_bin_file(&rbu_device->dev.kobj, &rbu_data_attr);
if (rc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists