linux-kernel - Re: [PATCH 06/13] DMAENGINE: driver for the ARM PL080/PL081 PrimeCells

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

Trying to understand this, bear with me if I'm thinking sidewise...

On Mon, Mar 10, 2014 at 3:52 PM, David Woodhouse <dwmw2@...radead.org> wrote:

> 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.

So what exactly is a source-id in this case? I'm thinking something
like a logical signal number, like 0x18 is a certain PCM device or
something. That is usually just the number of a rail routed in silicon from
the DMAC to the peripheral in question and doesn't have much to do
with how memory is mapped and data transferred in bursts or single
requests.

> The whole thing seems to be designed such
> that the DMA just *does* appear to come from the slave, not the DMA
> controller.

This sounds like the tag on the bus is set such that the transactions get
some number (maybe the above source-id) transmitted on a few bits
depending on bus arbitration protocol, during transactions making it
appear as if that device is driving the transaction.

Again as Russell stated that doesn't necessarily influence any memory
coherency or the physical address pointer written into the DMAC
hardware at all, does it? The transfers can still happen between the
peripheral and DMAC, and the IOMMU can still be sitting in the middle
of things, in front of the DMAC not the device, needing to be flushed etc.

Sorry if I don't get it... maybe this is one of these funny Intel things
I cannot wrap my head around properly.

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/