linux-kernel - Re: dmaengine.c: question about device_alloc_chan

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: <Pine.LNX.4.64.0809212139040.7264@axis700.grange>
Date:	Sun, 21 Sep 2008 21:50:18 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
cc:	Dan Williams <dan.j.williams@...el.com>,
	Timur Tabi <timur@...escale.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: dmaengine.c: question about device_alloc_chan_resources

On Sun, 21 Sep 2008, Haavard Skinnemoen wrote:

> > 2/ What about platform specific concerns where dma_cap_mask_t is not
> > descriptive enough e.g. only one memcpy channel can address a certain
> > bus?  Currently a client implementation can have some intelligence to
> > return DMA_DUP for channels that do not have the platform capability.
> 
> Currently, clients requesting the DMA_SLAVE capability can specify
> which particular DMA device they need. Would it make sense to allow
> other clients to do that as well?

This is how it is documented in dmaengine.h:

 * @slave: data for preparing slave transfer. Must be non-NULL iff the
 *  DMA_SLAVE capability is requested.

But, looking at dma_client_chan_alloc() it seems, any client requesting a 
channel can provide a slave and link it to a specific dma_dev, regardless 
what capabilities the client is requesting, or am I missing something? If 
so, then yes, please, let's allow all do this. Wouldn't it be better to 
move the .dma_dev member to dma_client?

> Also, struct dma_slave can be extended with
> controller-/platform-specific fields. Maybe we need a similar mechanism
> for passing platform-specific constraints when requesting "regular"
> channels?

As far as I understand, this extension can only be done by "wrapping" 
dma_slave with driver-specific data:

 * If dma_dev is non-NULL, the client can not be bound to other DMA
 * masters than the one corresponding to this device. The DMA master
 * driver may use this to determine if there is controller-specific
 * data wrapped around this struct. Drivers of platform code that sets
 * the dma_dev field must therefore make sure to use an appropriate
 * controller-specific dma slave structure wrapping this struct.

i.e., there is no "void *priv" or similar. So, the same "wrapping" can be 
used with dma_client, even more conveniently so, if we move .dma_dev into 
it.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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/