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, 31 Jul 2014 14:44:56 +0200
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Vinod Koul <vinod.koul@...el.com>
CC:	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	dmaengine@...r.kernel.org, Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Antoine Ténart <antoine@...e-electrons.com>,
	Thomas Petazzoni <thomas@...e-electrons.com>,
	Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
	Boris Brezillon <boris@...e-electrons.com>,
	Matt Porter <matt.porter@...aro.org>,
	laurent.pinchart@...asonboard.com, ludovic.desroches@...el.com,
	Gregory Clement <gregory.clement@...e-electrons.com>,
	Nicolas Ferre <nicolas.ferre@...el.com>
Subject: Re: [PATCH] Documentation: dmaengine: Add a documentation for the
 dma controller API

On 07/31/2014 09:44 AM, Maxime Ripard wrote:
[...]
>    - Having to set device_slave_caps or not?

Yes. This should in my opinion be mandatory for new drivers. One of the 
issues with the DMAengine API is that it is really hard to write generic 
drivers that do not already know about the capabilities of the DMA 
controller. E.g. if you have a peripheral that is used on SoC A it assumes 
that the DMA controller it is connected to has the capabilities of the DMA 
controller in SoC A. If the same peripheral is now used on SoC B with a DMA 
controller with different capabilities this often ends up with ugly ifdefery 
in the peripheral driver. The peripheral driver shouldn't have to know which 
specific DMA controller it is connected to (It's a bit as if a GPIO consumer 
needed to know which GPIO controller is connected to). We got away with the 
current approach since there is not that much diversity in the mixing of 
peripherals and DMA controllers (each vendor pretty has their own DMA 
controller which it uses for their own peripherals). But with more recent 
code consolidation we are on a path to generic DMA support within subsystem 
frameworks (there is generic DMA support for audio, there is generic DMA 
support for SPI and I also have a (currently) out of tree patch for generic 
DMA support for IIO). Also these generic drivers need to be able to discover 
the capabilities of the DMA controller to be able to make the right decisions.

- Lars
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ