linux-kernel - Re: [PATCH v2 0/3] dmaengine: add per channel capabilities api

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-next>] [day] [month] [year] [list]

Date:	Sun, 20 Jan 2013 11:37:35 -0500
From:	Matt Porter <mporter@...com>
To:	Vinod Koul <vinod.koul@...el.com>
Cc:	Dan Williams <djbw@...com>, Chris Ball <cjb@...top.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux MMC List <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH v2 0/3] dmaengine: add per channel capabilities api

On Sun, Jan 20, 2013 at 12:37:34PM +0000, Vinod Koul wrote:
> On Thu, Jan 10, 2013 at 02:07:03PM -0500, Matt Porter wrote:
> > The call is implemented as follows:
> > 
> > 	struct dmaengine_chan_caps
> > 	*dma_get_channel_caps(struct dma_chan *chan,
> > 			      enum dma_transfer_direction dir);
> > 
> > The dma transfer direction parameter may appear a bit out of place
> > but it is necessary since the direction field in struct
> > dma_slave_config was deprecated. In some cases, EDMA for one, it
> > is necessary for the dmaengine driver to have the burst and address
> > width slave configuration parameters available in order to compute
> > the maximum segment size that can be handle. Due to this requirement,
> > the calling order of this api is as follows:
> Well you are passing direction as argument so even in EDMA it doesn't seem to
> help you as you seem to need burst and width!. So why do you even need the
> direction to compute the capablities

Yes, I need burst and width, but they are dependent on direction (dst vs
src, as stored in the slave channel config). Ok, so I think I know where
this is leading...the problem is probably that I made an implicit
dependency on burst and width here. The expectation in this
implementation is that dmaengine_slave_config() has already been called
and as a result, the dmaengine driver has either src_* or dst_*
attributes populated depending on the direction of the channel. Given
that, the call to dma_get_channel_caps() needs to provide the direction
in order for the driver to know which of src_*/dst_* attributes are
valid in order to do the max segment size calculation.

An alternative, since the slave driver is the one that provided the
info in the first place is:

	struct dmaengine_chan_caps
	*dma_get_channel_caps(struct dma_chan *chan,
			      enum dma_slave_buswidth addr_width,
			      u32 maxburst);

where the attributes required by the edma driver to find the max
segment size are now explicitly provided. This approach also removes
the ordering requirement of calling dmaengine_slave_config() first. Is
this what you had in mind?

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