linux-kernel - Re: [PATCHv4] DMAEngine: Define interleaved transfer request 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABE8wwtcO_su0cF6YocVjAYKhUb=TTwqttfaZkC+RWGLKJimdQ@mail.gmail.com>
Date:	Tue, 11 Oct 2011 09:44:50 -0700
From:	"Williams, Dan J" <dan.j.williams@...el.com>
To:	Jassi Brar <jaswinder.singh@...aro.org>
Cc:	Vinod Koul <vinod.koul@...el.com>,
	Russell King <rmk@....linux.org.uk>,
	Barry Song <21cnbao@...il.com>, linux-kernel@...r.kernel.org,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>,
	Dave Jiang <dave.jiang@...el.com>, Alexandre.Bounine@....com
Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

[ Adding Alexandre ]

On Fri, Oct 7, 2011 at 4:27 AM, Jassi Brar <jaswinder.singh@...aro.org> wrote:
> On 7 October 2011 11:15, Vinod Koul <vinod.koul@...el.com> wrote:
>
>> Thru this patch Jassi gave a very good try at merging DMA_SLAVE and
>> memcpy, but more we debate this, I am still not convinced about merging
>> memcpy and DMA_SLAVE yet.
>>
> Nobody is merging memcpy and DMA_SLAVE right away.
> The api's primary purpose is to support interleave transfers.
> Possibility to merge other prepares into this is a side-effect.
>
>> I would still argue that if we split this on same lines as current
>> mechanism, we have clean way to convey all details for both cases.
>>
> Do you mean to have separate interleaved transfer apis for Slave
> and Mem->Mem ? Please clarify.
>

This is a tangent, but it would be nice if this API extension also
covered the needs of the incoming RapidIO case which wants to specify
new device context information per operation (and not once at
configuration time, like slave case).  Would it be enough if the
transfer template included a (struct device *context) member at the
end?  Most dma users could ignore it, but RapidIO could use it to do
something like:

   struct rio_dev *rdev = container_of(context, typeof(*rdev), device);

That might not be enough, but I'm concerned that making the context a
(void *) is too flexible.  I'd rather have something like this than
acquiring a lock in rio_dma_prep_slave_sg() and holding it over
->prep().  The alternative is to extend device_prep_slave_sg to take
an extra parameter, but that impacts all other slave implementations
with a dead parameter.

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