linux-kernel - RE: [RFC][PATCH] DMA: Expand dmaengine implementation for more DMACs

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] [day] [month] [year] [list]

Message-ID: <BAE9DCEF64577A439B3A37F36F9B691C02A878CB@orsmsx418.amr.corp.intel.com>
Date:	Wed, 11 Jul 2007 11:02:15 -0700
From:	"Nelson, Shannon" <shannon.nelson@...el.com>
To:	"Peter Pearse" <peter.pearse@....com>
Cc:	<linux-kernel@...r.kernel.org>,
	"Dan Williams" <dan.j.williams@...il.com>
Subject: RE: [RFC][PATCH] DMA: Expand dmaengine implementation for more DMACs

Dan Williams [mailto:dan.j.williams@...il.com] 
>On 7/3/07, Peter Pearse <peter.pearse@....com> wrote:
>> Hi,
>>
>> The existing DMAC used by the dmaengine API (Intel IOAT) assumes all
>> possible clients can use any available DMA channel.
>>
>> Some other DMACs restrict particular peripherals to 
>particular DMA channels.
>>
>> The patch below (against v2.6.22-rc7) extends the dmaengine 
>implementation
>> to allow such DMACs to differentiate between clients.
>>
>Hi Peter,
>
>Have a look at:
>http://marc.info/?l=linux-raid&m=118290909528910&w=2
>http://marc.info/?l=linux-raid&m=118290909523734&w=2
>
>It seems your requirement could be satisfied by a natural extension of
>the 'dma_cap_mask' implementation.  'dma_cap_mask' allows clients to
>only be notified of channels that meet a certain capability profile.
>
>However since your driver is pretty much guaranteed to be the only
>dmaengine driver in the system you can safely do something like the
>following in your client callback:
>

Peter,

If the client is looking for a specific channel capability, that can be
worked with Dan's version of the interface as he suggests with the
dma_cap_mask.  However, it sounds like you need not just channel
capabilities, but also client capabilities information, which I assume
you would carry in the "void *client_data" that you suggested, allowing
the DMAC itself to Ack/Nak the provisioning.  Dan's other suggestion
below has the client controlling the provisioning by accepting a
particular channel.  If the DMAC is the one that has the restriction
information and needs to enforce the restriction based on the specific
client, I suspect this may not help.

Can you give us an example of exactly how your DMAC restriction works?

Is it possible for you to pull this off with the suggested dma_cap_mask?
The only info the client would need is the particular capability bit for
a specific channel type.

Thanks,
sln
-
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/