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:	Mon, 10 Mar 2014 07:52:51 -0700
From:	David Woodhouse <dwmw2@...radead.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	"mika.westerberg@...ux.intel.com" <mika.westerberg@...ux.intel.com>,
	"Koul, Vinod" <vinod.koul@...el.com>,
	"Krogerus, Heikki" <heikki.krogerus@...el.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	yuanyabin1978@...a.com, linux-kernel@...r.kernel.org,
	Ben Dooks <ben-linux@...ff.org>,
	Peter Pearse <peter.pearse@....com>,
	Dan Williams <dan.j.williams@...el.com>,
	linux-arm-kernel@...ts.infradead.org,
	Alessandro Rubini <rubini@...pv.it>
Subject: Re: [PATCH 06/13] DMAENGINE: driver for the ARM PL080/PL081
 PrimeCells

On Mon, 2014-03-10 at 14:32 +0000, Russell King - ARM Linux wrote:
> Okay, so how do you get the DMA address which is to be programmed into
> the DMA controller - bearing in mind that different devices in the
> system may have different bus:physical offsets?

There's no answer to that in the general case. The question of how you
program it into the DMA controller, and where you *get* the information
from, is very board-specific. As is the question of whether it's even
*possible* for the DMA controller to "fake" the source of its
transactions. It works for PCIe in certain cases (especially in SoCs)
but certainly doesn't work everywhere.

But that's OK, because in the general case we'd just do the sensible
thing and the DMA would appear to come from the DMA controller itself.
We're only talking about adding the *possibility* for doing otherwise,
not making it mandatory.

> ACPI may allow you to work this out for each slave device, but now
> try thinking about this same problem without ACPI.

Actually, if it's really true that the *kernel* is supposed to tell the
DMA controller which source-id to use for a given channel, instead of it
being programmed in advance by the BIOS, then ACPI doesn't solve that
for us in this case either. The whole thing seems to be designed such
that the DMA just *does* appear to come from the slave, not the DMA
controller. And we haven't yet worked out how we're supposed to make
that happen. If indeed we *are* supposed to :)

-- 
dwmw2


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ