linux-kernel - Re: [PATCH 01/11] dmaengine: add context parameter to prep_slave_sg and prep_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:	Thu, 2 Feb 2012 21:43:50 +0000
From:	Russell King <rmk@....linux.org.uk>
To:	Alexandre Bounine <alexandre.bounine@....com>
Cc:	vinod.koul@...el.com, dan.j.williams@...el.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Jassi Brar <jaswinder.singh@...aro.org>,
	Kumar Gala <galak@...nel.crashing.org>,
	Matt Porter <mporter@...nel.crashing.org>,
	Li Yang <leoli@...escale.com>
Subject: Re: [PATCH 01/11] dmaengine: add context parameter to
	prep_slave_sg and prep_dma_cyclic

On Thu, Feb 02, 2012 at 04:32:11PM -0500, Alexandre Bounine wrote:
> Add context parameter to device_prep_slave_sg() and device_prep_dma_cyclic()
> interfaces to allow passing client/target specific information associated
> with the data transfer.

I'm slightly concerned about having this as a vague 'void *' pointer.
What that means is that the data being passed through it is entirely
unspecified, and quite specific to the DMA engine.

That's rather worrying when we (on ARM) are moving towards a model
where the same peripheral IP can be backed by multiple different DMA
engines.  We already have peripheral drivers (clients of DMA engine)
which can be attached to completely different DMA engine drivers.

If DMA engines continue to operate conventionally with this parameter
NULL then that's fine for current stuff.  I would suggest that it's
made to be something a little better defined though, as the 'void *'
approach encourages each driver writer to invent their own way to
specify, eg, an interleaved transfer.  We'll then end up with N
different ways to specify the same thing.

Not only that, but peripheral drivers won't know what kind of data to
pass there (they would have to have additional knowledge of the DMA
engine which they're attached to.)

Basically, allowing a DMA engine specific blob of data to be passed
destroys the idea of having a consistent API for peripheral drivers
to use, because they can then no longer be independent of their DMA
engine.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/