linux-kernel - Re: [PATCH] DMAENGINE: generic slave channel control v3

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]

Date:	Thu, 29 Jul 2010 01:04:12 +0200
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	linux-kernel@...r.kernel.org, Vinod Koul <vinod.koul@...el.com>,
	Alan Cox <alan@...ux.intel.com>
Subject: Re: [PATCH] DMAENGINE: generic slave channel control v3

2010/7/28 Dan Williams <dan.j.williams@...el.com>:

> What are the rules for when a new dma_slave_config can be set?

My idea is that these are done immediately before any work
to be carried out.

> Looking at the driver implementations it seems there is nothing
> preventing a concurrent call to device_control to occur at "wrong
> time"?  Is there a synchronization context I'm missing?

I do imagine that the code using this will be naturally serialized,
since you need to configure the channel before using it for
something. i.e. the channel is typically STOPPED. If you like
I can add checking for this to the coh901318 and ste_dma40
patches. (It wouldn't affect this one though.)

Drivers that want to support reconfiguring while a channel is
running a transfer may have to look harder.

Yours,
Linus Walleij
--
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/