linux-kernel - Re: [PATCH 01/28] dmaengine: use DMA_COMPLETE for dma completion status

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, 17 Oct 2013 10:27:13 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Vinod Koul <vinod.koul@...el.com>
cc:	Dan Williams <dan.j.williams@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, linux@....linux.org.uk
Subject: Re: [PATCH 01/28] dmaengine: use DMA_COMPLETE for dma completion
 status

On Thu, 17 Oct 2013, Vinod Koul wrote:

> On Wed, Oct 16, 2013 at 11:45:48AM -0700, Dan Williams wrote:
> > On Wed, Oct 16, 2013 at 11:29 AM, Guennadi Liakhovetski
> > >
> > > Doesn't this break kernel compilation for a total of 27 commits? Or am I
> > > missing anything?
> > 
> > Yes, I think at the start DMA_COMPLETE should just be a alias for
> > DMA_SUCCESS, then after all the driver renames are in delete
> > DMA_SUCCESS.
> Oops, taht was bad of me. ffixes in v2 and sending patch 29 for removal case

Ok, yes, this should work now. I'm wondering though - is DMA_COMPLTE 
really a better name? AFAICS, we can only differentiate between 2 
possibilities with the current API: a transfer is "in progress" - between 
last used and last completed, and "unknown" - either completed, or 
aborted, or not yet submitted - if the cookie is larger, than last 
completed and we assume, that it has wrapped.

Actually for a driver, that I'm currently working on, I implemented a 
cache of N last cookies (e.g. 128), which is a bitfield, where I just 
record a 1, if that descriptor has failed, and a 0, if completed 
successfully. That way I can report one of 4 states: cookie on queue, 
completed successfully, failed, unknown. I'm not sure, whether I'll keep 
this in the final version, this doesn't really fit the present dmaengine 
API concept. We could make this generic, if desired. Otherwise your 
proposed error callback should help too. But in either case I think with 
the current implementation we cannot find out whether a specific cookie 
completed successfully or failed.

One more observation: I looked at a couple of drivers, using the DMA_ERROR 
state. E.g. mmp_tdma.c, mxs-dma.c. They store errors in a .status field in 
their private data. Then they return that status in their 
.device_tx_status() methods - independent on the cookie! This doesn't look 
right to me... at_hdmac.c does something similarly strange.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/