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: <CAJe_Zhcf1tp2ukE3tqcrzyfEp1jA5Gw=ed1xDQT6FLYn-jR2ug@mail.gmail.com>
Date:	Fri, 30 Sep 2011 21:17:07 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Vinod Koul <vinod.koul@...el.com>
Cc:	linux-kernel@...r.kernel.org, dan.j.williams@...el.com,
	rmk@....linux.org.uk, 21cnbao@...il.com
Subject: Re: [PATCHv4] DMAEngine: Define interleaved transfer request api

On 29 September 2011 16:47, Vinod Koul <vinod.koul@...el.com> wrote:
> On Wed, 2011-09-28 at 20:45 +0530, Jassi Brar wrote:
>> >> +enum xfer_direction {
>> >> +     MEM_TO_MEM,
>> >> +     MEM_TO_DEV,
>> >> +     DEV_TO_MEM,
>> >> +     DEV_TO_DEV,
>> > Use/update dma_data_direction.
>> dma_data_direction is the mapping attribute of a buffer.
>> While that info is what some dmac driver might need ultimately, our
>> main aim here is to tell exactly if Src and Dst is Memory or a
>> device's FIFO.
>>
>> Mapping attribute of src/dst buffers could be very well deducted from
>> xfer_direction, but dma_data_direction isn't meant to tell if Src and
>> Dst is Mem or FIFO.
>> Also, for (SLAVE && !src_inc && !dst_inc) we need to disambiguate
>> three options  Mem->Fifo,  Fifo->Mem,  *Fifo->Fifo*(not impossible)
>> So while using dma_data_direction would work today, that sure is hacky
>> and not future-proof.
> That is why I said use/update, you missed the update part.
>
> One way would be to use direction field with new flag indicating if its
> memory or device transfer, otherwise you can expand this enum.
>
> Point is few things are already there so improve upon it rather than
> have two structures in kernel doing similar things...
>
I don't think dma_data_direction should be messed with here.
Or I am just being ignorant, in that case please do suggest how do
you want dma_data_direction "updated" ?
--
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/