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]

Date:	Thu, 6 Oct 2011 14:36:10 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	"Williams, Dan J" <dan.j.williams@...el.com>
Cc:	Russell King <rmk@....linux.org.uk>,
	Barry Song <21cnbao@...il.com>,
	Vinod Koul <vinod.koul@...el.com>,
	linux-kernel@...r.kernel.org,
	DL-SHA-WorkGroupLinux <workgroup.linux@....com>,
	Dave Jiang <dave.jiang@...el.com>
Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

On 5 October 2011 23:49, Williams, Dan J <dan.j.williams@...el.com> wrote:
> On Mon, Oct 3, 2011 at 11:23 AM, Jassi Brar <jaswinder.singh@...aro.org> wrote:
>> You are assuming only Slave usage.
>> src_inc/dst_inc are mainly for 'Memset' type operation.
>
> There currently are not any users of offloaded memset in the kernel,
> do you have one in mind?  Otherwise I would not design for it this
> early.
>
Let me explain the circumstances that led me to the crime ...

# This api is common for Mem->Mem and Slave interleaved transfers.

For Mem->Mem
******************
# Memcpy is simply an 'interleaved' transfer of 1 frame containing
  1 chunk of very large size.
  So we might as well merge device_prep_dma_memcpy into this api.
# And Memset is simply a Memcpy with fixed source address.
  Hence the src_inc.

For Slave
***********
# Considering most cases where ...
    src_inc  &&  dst_inc  => Invalid
   !src_inc  &&  dst_inc  => DEV_TO_MEM
    src_inc  && !dst_inc  => MEM_TO_DEV
   !src_inc  && !dst_inc  => DEV_TO_DEV
would get dmac drivers the direction per transfer.
That is _IF_ the api specifies that clients can not do memset
to/from device's FIFO and use full buffers even for dummy data.
But as Russell noted, some clients already do dma between fixed
memory address and FIFO, we have to support 'slave-memset'
and rather have explicit flag 'enum xfer_direction' for direction.
So we still need src/dst_inc albeit for not so important role.

>
>> In Slave transfer they would help avoid allocating full length RX buffer
>> when the client only wants to send data but the controller works
>> only in full-duplex and vice-versa (thanks to RMK for pointing the case,
>> and I remember S3C24XX do have such SPI controller).
>> More generally when one needs to transmit the same data, or discard
>> the received data, for a certain period of time.
>
> In the slave case I would think the driver would know the address
> increment attributes of the slave and would not need to be told on
> each operation by the client?
>
Consider the same example of full-duplex-only SPI controller.
For some transfers the client might move real data (memory
side address increments) while for other transfers the client
would have to provide dummy data, by keep memory side address
constant, just to keep active the useful transfer in other direction.
So this has to be a per-transfer thing rather than a property
of the channel.

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