linux-kernel - Re: [PATCH 2/2] Blackfin: fix dma-mapping build errors

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]

Message-ID: <8bd0f97a0906221929y51af5000w63e2edb7e54abe74@mail.gmail.com>
Date:	Mon, 22 Jun 2009 22:29:29 -0400
From:	Mike Frysinger <vapier.adi@...il.com>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	linux-kernel@...r.kernel.org,
	uclinux-dist-devel@...ckfin.uclinux.org
Subject: Re: [PATCH 2/2] Blackfin: fix dma-mapping build errors

On Mon, Jun 22, 2009 at 22:14, FUJITA Tomonori wrote:
> On Mon, 22 Jun 2009 21:54:46 -0400 Mike Frysinger wrote:
>> The recent deprecation of dma_sync_{sg,single} ironically broke Blackfin
>> systems.
>
> Oops, sorry about that.
>
>> This is because we don't define dma_sync_sg_for_cpu at all, so
>> until the DMA asm-generic conversion/cleanup is done after the next
>> release, simply redirect the dma_sync_sg_for_cpu to the debug version.
>
> This doesn't look correct (though it works). dma-debug.h is supposed
> to be used by architectures that support DMA_API_DEBUG feature
> (blackfin doesn't support it). dma_sync_sg_for_cpu is not the
> debug version of dma_sync_sg_for_cpu.

guessing you meant "debug_dma_sync_sg_for_cpu is not the debug version
of dma_sync_sg_for_cpu"

> I think that simply adding dummy dma_sync_single_for_device() is a
> proper solution (as blackfin already does wrt dma_sync_single_for_cpu
> and dma_sync_single_for_device).
>
> Architectures are also supposed to have dma_sync_sg_for_cpu and
> dma_sync_sg_for_device, so let's add both.

i'm not really familiar with the DMA mapping functions, so if you say
this is the way to go, then it's fine by me.  not like it'll lead to
any runtime failures for us.
-mike
--
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/