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]

Message-ID: <20131017095308.GF14013@intel.com>
Date:	Thu, 17 Oct 2013 15:23:08 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
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, Oct 17, 2013 at 10:27:13AM +0200, Guennadi Liakhovetski wrote:
> 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.
well, once you submit N, and chekcing status, if you get last > N, then you
assume it completed. If last is M then M is completed and M + 1 running and rest
in queue. You know which one is last submitted in client

> 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.
The propsed error callback will tell you if dmaengine detected a failure or not.
That should with above cover well

> 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.
Yup bunch of ones arent being good citizens..

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