linux-kernel - Re: [PATCH 10/18] spi: s3c64xx: Do not require legacy DMA API in case of S3C64XX

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130813201816.GG6427@sirena.org.uk>
Date:	Tue, 13 Aug 2013 21:18:16 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Tomasz Figa <tomasz.figa@...il.com>
Cc:	linux-samsung-soc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
	Dan Williams <djbw@...com>, Jaroslav Kysela <perex@...ex.cz>,
	Kukjin Kim <kgene.kim@...sung.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mike Turquette <mturquette@...aro.org>,
	Padmavathi Venna <padma.v@...sung.com>,
	Russell King <linux@....linux.org.uk>,
	Sangbeom Kim <sbkim73@...sung.com>,
	Takashi Iwai <tiwai@...e.de>, Vinod Koul <vinod.koul@...el.com>
Subject: Re: [PATCH 10/18] spi: s3c64xx: Do not require legacy DMA API in
 case of S3C64XX

On Tue, Aug 13, 2013 at 07:55:47PM +0100, Mark Brown wrote:

> I'm still debugging what's going on here - the basic refcounting all
> looks OK in the SPI driver, I can see it requesting and releasing with
> the refcounts all going back to zero in the DMA driver as expected but
> when we come back to the device later on dmaengine is deciding the
> device is unavailable quite early on in the process.

The failure is happening because this check is failing:

	/* devices with multiple channels need special handling as we need to
	 * ensure that all channels are either private or public.
	 */
	if (dev->chancnt > 1 && !dma_has_cap(DMA_PRIVATE, dev->cap_mask))
		list_for_each_entry(chan, &dev->channels, device_node) {
			/* some channels are already publicly allocated */
			if (chan->client_count) {

which is happening because dma1chan0 (which is on the same DMA
controller as the SPI controller) and in fact every other DMA channel
had references grabbed by the network stack dmaengine helpers which I'd
enabled in config.  The fact that they do that is unhelpful, it renders
the API mostly useless, but is nothing to do with this series.

Having tweaked the config everything appears to work so:

Tested-by: Mark Brown <broonie@...aro.org>

though the whole thing with the filter function is as I say a bit fun
from a code review point of view.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)