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:	Sun, 17 Nov 2013 17:37:53 +0100
From:	Florian Meier <florian.meier@...lo.de>
To:	Joe Perches <joe@...ches.com>
CC:	Stephen Warren <swarren@...dotorg.org>,
	Vinod Koul <vinod.koul@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	devicetree <devicetree@...r.kernel.org>,
	alsa-devel@...a-project.org, Liam Girdwood <lgirdwood@...il.com>,
	linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>,
	linux-rpi-kernel <linux-rpi-kernel@...ts.infradead.org>,
	dmaengine <dmaengine@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCHv7] dmaengine: Add support for BCM2835

On 17.11.2013 17:02, Joe Perches wrote:
> On Sun, 2013-11-17 at 16:39 +0100, Florian Meier wrote:
>> Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
>> Currently it only supports cyclic DMA.
> []
>> diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
> []
>> +static int bcm2835_dma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
>> +	unsigned long arg)
>> +{
>> +	struct bcm2835_chan *c = to_bcm2835_dma_chan(chan);
>> +	int ret;
>> +
>> +	switch (cmd) {
>> +	case DMA_SLAVE_CONFIG:
>> +		return bcm2835_dma_slave_config(c,
>> +				(struct dma_slave_config *)arg);
>> +
>> +	case DMA_TERMINATE_ALL:
>> +		bcm2835_dma_terminate_all(c);
>> +		break;
>> +
>> +	default:
>> +		ret = -ENXIO;
>> +		break;
>> +	}
>> +
>> +	return ret;
>> +}
> 
> case DMA_TERMINATE_ALL returns an uninitialized ret;

Oh yes - stupid mistake. Thank you!

> []
> 
>> +static struct dma_chan *bcm2835_dma_xlate(struct of_phandle_args *spec,
>> +					   struct of_dma *ofdma)
>> +{
>> +	struct bcm2835_dmadev *d = ofdma->of_dma_data;
>> +	struct dma_chan *chan, *candidate;
>> +
>> +retry:
>> +	candidate = NULL;
>> +
>> +	/* Walk the list of channels registered with the current instance and
>> +	 * find one that is currently unused */
>> +	list_for_each_entry(chan, &d->ddev.channels, device_node)
>> +		if (chan->client_count == 0) {
>> +			candidate = chan;
>> +			break;
>> +		}
>> +
>> +	if (!candidate)
>> +		return NULL;
>> +
>> +	/* dma_get_slave_channel will return NULL if we lost a race between
>> +	 * the lookup and the reservation */
>> +	chan = dma_get_slave_channel(candidate);
> 
> Can that race happen consistently?
> Does this avoid being a tight loop?

I would say this can not happen.
If I get everything right, the conflicting process will not
get NULL (because it has won the race). In the worst case,
a new process enters the race, but this will only continue until all
channels are used. In that case no candidate exists and the loop will
exit.

At least, the code is directly taken from mmp_pdma.c ;-)

Greetings,
Florian

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