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] [day] [month] [year] [list]
Date:	Wed, 17 Oct 2012 13:27:22 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Kukjin Kim <kgene.kim@...sung.com>
Cc:	arm@...nel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, "'Ben Dooks'" <ben-linux@...ff.org>,
	"'Grant Likely'" <grant.likely@...retlab.ca>,
	linux-samsung-soc@...r.kernel.org,
	spi-devel-general@...ts.sourceforge.net
Subject: Re: [PATCH v2 v2 v2 8/8] spi/s3c64xx: use correct dma_transfer_direction type

On Wednesday 17 October 2012, Kukjin Kim wrote:
> BTW, don't we need following accordingly?
> 
> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
> index 1a81c90..a0bb55e 100644
> --- a/drivers/spi/spi-s3c64xx.c
> +++ b/drivers/spi/spi-s3c64xx.c
> @@ -1067,11 +1067,11 @@ static int __devinit s3c64xx_spi_get_dmares(
> 
>         if (tx) {
>                 dma_data = &sdd->tx_dma;
> -               dma_data->direction = DMA_TO_DEVICE;
> +               dma_data->direction = DMA_MEM_TO_DEV;
>                 chan_str = "tx";
>         } else {
>                 dma_data = &sdd->rx_dma;
> -               dma_data->direction = DMA_FROM_DEVICE;
> +               dma_data->direction = DMA_DEV_TO_MEM;
>                 chan_str = "rx";
>         }
> 

Yes, you are absolutely right, sorry for not seeing that earlier.
New version below.

	Arnd

>From c10356b9846b13651a8a24c3a31e029ffe6eafd9 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@...db.de>
Date: Mon, 30 Apr 2012 16:31:27 +0000
Subject: [PATCH] spi/s3c64xx: use correct dma_transfer_direction type

There is a subtle difference between dma_transfer_direction and
dma_data_direction: the former is used by the dmaengine framework,
while the latter is used by the dma-mapping API. Although the
purpose is comparable, the actual values are different and must
not be mixed. In this case, the driver just wants to use
dma_transfer_direction.

Without this patch, building s3c6400_defconfig results in:

drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_dmacb':
drivers/spi/spi-s3c64xx.c:239:21: warning: comparison between
	'enum dma_data_direction' and 'enum dma_transfer_direction' [-Wenum-compare]

As pointed out by Kukjin Kim, this also changes the use of constants
from DMA_FROM_DEVICE/DMA_TO_DEVICE to DMA_DEV_TO_MEM/DMA_MEM_TO_DEV.

Signed-off-by: Arnd Bergmann <arnd@...db.de>
Acked-by: Kukjin Kim <kgene.kim@...sung.com>
Cc: Ben Dooks <ben-linux@...ff.org>
Cc: Grant Likely <grant.likely@...retlab.ca>
Cc: linux-arm-kernel@...ts.infradead.org
Cc: linux-samsung-soc@...r.kernel.org
Cc: spi-devel-general@...ts.sourceforge.net

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index d1c8441f..cd43b4b 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -132,7 +132,7 @@
 
 struct s3c64xx_spi_dma_data {
 	unsigned		ch;
-	enum dma_data_direction direction;
+	enum dma_transfer_direction direction;
 	enum dma_ch	dmach;
 	struct property		*dma_prop;
 };
@@ -1065,11 +1065,11 @@ static int __devinit s3c64xx_spi_get_dmares(
 
 	if (tx) {
 		dma_data = &sdd->tx_dma;
-		dma_data->direction = DMA_TO_DEVICE;
+		dma_data->direction = DMA_MEM_TO_DEV;
 		chan_str = "tx";
 	} else {
 		dma_data = &sdd->rx_dma;
-		dma_data->direction = DMA_FROM_DEVICE;
+		dma_data->direction = DMA_DEV_TO_MEM;
 		chan_str = "rx";
 	}
 
--
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