[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150224135622.GH6236@finisterre.sirena.org.uk>
Date: Tue, 24 Feb 2015 22:56:23 +0900
From: Mark Brown <broonie@...nel.org>
To: Stanimir Varbanov <stanimir.varbanov@...aro.org>
Cc: linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-spi@...r.kernel.org,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Kumar Gala <galak@...eaurora.org>,
Andy Gross <agross@...eaurora.org>,
Sagar Dharia <sdharia@...eaurora.org>,
Daniel Sneddon <dsneddon@...eaurora.org>
Subject: Re: [PATCH v2] spi: qup: Add DMA capabilities
On Tue, Feb 24, 2015 at 03:00:03PM +0200, Stanimir Varbanov wrote:
> +static void spi_qup_dma_done(void *data)
> +{
> + struct spi_qup *qup = data;
> +
> + if (atomic_dec_and_test(&qup->dma_outstanding))
> + complete(&qup->done);
> +}
I'm finding it hard to be thrilled about the use of atomics for
synchronization (they're just generally hard to work with) and...
> + cookie = dmaengine_submit(desc);
> + ret = dma_submit_error(cookie);
> + if (ret)
> + return ret;
> + atomic_inc(&qup->dma_outstanding);
..don't we have two potential races here: one if somehow the DMA manages
to complete prior to the atomic_inc() (unlikely but that's what race
conditions are all about really) and one if we are issuing multiple DMAs
and the early ones complete before the later ones are issued?
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists