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:	Mon, 06 Feb 2012 20:58:54 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	"Bounine, Alexandre" <Alexandre.Bounine@....com>
Cc:	Russell King <rmk@....linux.org.uk>, dan.j.williams@...el.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	Jassi Brar <jaswinder.singh@...aro.org>,
	Kumar Gala <galak@...nel.crashing.org>,
	Matt Porter <mporter@...nel.crashing.org>,
	Li Yang <leoli@...escale.com>
Subject: RE: [PATCH 01/11] dmaengine: add context parameter toprep_slave_sg
 and prep_dma_cyclic

On Mon, 2012-02-06 at 07:04 -0800, Bounine, Alexandre wrote:
> I was thinking about keeping the original scatterlist for dmac unchanged,
> but allocating another scatterlist in rio_dma_prep_slave_sg() and chaining
> two lists together. After it passed to device specific function, it parses
> first section of the chain for additional transfer parameters and use
> following scatterlist as intended for dmac.
hmmm, but that wouldn't make it generic for other systems like proposed
MSM box mode..., right?
> 
> But Russell's idea (See https://lkml.org/lkml/2012/2/3/269 ) seems to be
> a better way without added complexity and I am ready to take that path and
> make new patches if you and Dan agree with it. 
but it still doesn't fix his concerns for the using void pointer.

If we agree that this is the way, then I was thinking to add arch specif
calls which cast the context pointer to void for passing to dmac. The
arch specific struct gets defined in dmaengine_arch.h <or something
similar>. That way clients cant define their own stuff and we continue
to be generic as well as cater to arch specific requirements.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ