linux-kernel - Re: is_device_dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Jun 2009 17:12:14 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	malcolm.blaney@...tek.com.au
Cc:	linux-kernel@...r.kernel.org
Subject: Re: is_device_dma_capable

On Tue, 16 Jun 2009 16:54:24 +0930
Malcom Blaney <malcolm.blaney@...tek.com.au> wrote:

> I'm using the parport_pc driver with a dma buffer, which is provided
> by calling dma_alloc_coherent in arch/x86/include/asm/dma-mapping.h.
> 
> This is no longer working for me in 2.6.29.2, the previous version I
> was using is 2.6.25.10, which was fine with the same hardware.
> 
> The problem is that the call to is_device_dma_capable returns false,
> so dma_alloc_coherent returns NULL. Do I need to set the dma_mask in
> the driver for this to work correctly?

You use X86_32, right?

In 2.6.25, X86_32 and X86_64 had the own dma_alloc_coherent
implementations; X86_32 accepted a device having dma_mask that is not
initialized however X86_64 didn't, I think.

When we merged them, we chose to prohibit a device having dma_mask
that is not initialized. I'm not sure the DMA docs say this but IMO
it's good to require drivers to set up dma_mask (and
coherent_dma_mask) properly if the drivers want DMA.
--
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/