linux-kernel - Re: [PATCH 01/10] dmaengine: add new enum dma_transfer

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:	Sat, 15 Oct 2011 22:34:32 +0530
From:	Vinod Koul <vinod.koul@...ux.intel.com>
To:	Russell King <rmk@....linux.org.uk>
Cc:	dan.j.williams@...el.com, linux-kernel@...r.kernel.org,
	jaswinder.singh@...aro.org, 21cnbao@...il.com
Subject: Re: [PATCH 01/10] dmaengine: add new enum dma_transfer_direction

On Sat, 2011-10-15 at 13:46 +0100, Russell King wrote:
> On Fri, Oct 14, 2011 at 11:08:16AM +0530, Vinod Koul wrote:
> > This new enum removes usage of dma_data_direction for dma direction. The new
> > enum cleans tells the DMA direction and mode
> > This further paves way for merging the dmaengine _prep operations and also for
> > interleaved dma
> >  
> >  /**
> >   * enum dma_ctrl_flags - DMA flags to augment operation preparation,
> > @@ -267,7 +279,7 @@ enum dma_slave_buswidth {
> >   * struct, if applicable.
> >   */
> >  struct dma_slave_config {
> > -	enum dma_data_direction direction;
> > +	enum dma_transfer_direction direction;
> 
> I thought we were killing this off - surely now is a good time, rather
> than allowing it to persist with this ambiguous change of functionality.
Ah yes, I will probably do that next week, this is by product of global
replace done on this file :)
> 
> >  	dma_addr_t src_addr;
> >  	dma_addr_t dst_addr;
> >  	enum dma_slave_buswidth src_addr_width;
> > @@ -490,11 +502,11 @@ struct dma_device {
> >  
> >  	struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> >  		struct dma_chan *chan, struct scatterlist *sgl,
> > -		unsigned int sg_len, enum dma_data_direction direction,
> > +		unsigned int sg_len, enum dma_transfer_direction direction,
> 
> Does this make any sense?  The API takes a single scatterlist of memory
> locations - so MEM_TO_MEM and DEV_TO_DEV are meaningless for this API.
> 
> If it took two scatterlists and two device addresses, then maybe it would -
> but I don't see the point of this change (and all the users of this API
> also needing to change) when the API is specifically for memory scatterlist
> to/from a device.

dma_data_direction is meaningless to dmacs. We were overloading that to
convey slave direction, so we came up with better way to handle this.
The big plus point would be for the proposed interleaved dmaengine api,
this would convey what is mode (memcpy/slave) and direction in case of
slave cleanly.

-- 
~Vinod

--
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/