linux-kernel - Re: [PATCHv2] DMAEngine: Define generic 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_ZhfjmCOOAsBnB+adZbRq=G5CWvk6ZHpukufe+_JHCN+_Gw@mail.gmail.com>
Date:	Fri, 16 Sep 2011 16:33:25 +0530
From:	Jassi Brar <jaswinder.singh@...aro.org>
To:	Barry Song <21cnbao@...il.com>
Cc:	dan.j.williams@...el.com, vkoul@...radead.org,
	linux-kernel@...r.kernel.org, rmk+kernel@....linux.org.uk
Subject: Re: [PATCHv2] DMAEngine: Define generic transfer request api

On 16 September 2011 12:47, Barry Song <21cnbao@...il.com> wrote:
> 2011/9/15 Jassi Brar <jaswinder.singh@...aro.org>:
>> --- a/drivers/dma/dmaengine.c
>> +++ b/drivers/dma/dmaengine.c
>> @@ -699,6 +699,8 @@ int dma_async_device_register(struct dma_device *device)
>>                !device->device_prep_dma_cyclic);
>>        BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
>>                !device->device_control);
>> +       BUG_ON(dma_has_cap(DMA_GENXFER, device->cap_mask) &&
>> +               !device->device_prep_dma_genxfer);
>
> i don't think it is what i want here. device_prep_dma_genxfer should
> be able to cover memcpy, slave or other modes, but not parallel with
> them.

ATM this api is indeed parallel to others like memcpy, slave_sg etc.
because I have dropped the 'op' member in v2. The idea is to merge
other prepares one at a time and ultimately have this api consume
those that it can. So the 'op' would be restored when we merge
the first 'prepare' into this.


> For example, if i use genxfer, but my devices are slave. i might not
> need a device_prep_slave_sg since i have already prep_dma_genxfer, but
> anyway, i need a DMA_SLAVE_CONFIG to set burst size or others. then
> i'd like to have DMA_SLAVE flag but without device_prep_slave_sg
> callback.

As I already said, this api could be used for interleaved Mem->Mem
as well as Mem<->Dev
If your channels are Slave, please set the DMA_SLAVE flag and provide the
'device_control' callback.

I think I should have simply removed the check
    BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
                   !device->device_prep_slave_sg);
Because obviously we now have a _valid_ case of SLAVE channel but
supporting a different prepare - device_prep_dma_genxfer.  Will do that in v3.
--
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/