linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx
@ 2022-09-27 11:21 Vincent Whitchurch
  2022-09-27 11:21 ` [PATCH v2 1/4] spi: Save current RX and TX DMA devices Vincent Whitchurch
                   ` (4 more replies)
  0 siblings, 5 replies; 13+ messages in thread
From: Vincent Whitchurch @ 2022-09-27 11:21 UTC (permalink / raw)
  To: broonie, krzysztof.kozlowski, andi
  Cc: kernel, Vincent Whitchurch, alim.akhtar, linux-spi, linux-kernel,
	linux-samsung-soc, linux-arm-kernel

v2:
- Drop merged patch adding new test to spi-loopback-test
- Fix compiler warning in !HAS_DMA builds
- Add support to split transfers to core

This series fixes some bugs I found while running spi-loopback-test with
spi-s3c64xx.  The first problem (which I actually noticed while trying to fix
the second problem with transfers >64KiB) seems to be a generic issue which
affects several drivers so I fixed it in the core.

The series has been tested on ARTPEC-8, which has a version of the IP similar
to Exynos 7 and with 64 byte FIFOs (compatible with "tesla,fsd-spi").

Cc: alim.akhtar@samsung.com
Cc: linux-spi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org

Vincent Whitchurch (4):
  spi: Save current RX and TX DMA devices
  spi: Fix cache corruption due to DMA/PIO overlap
  spi: Split transfers larger than max size
  spi: s3c64xx: Fix large transfers with DMA

 drivers/spi/spi-s3c64xx.c |   9 +++
 drivers/spi/spi.c         | 137 ++++++++++++++++++++++++++++----------
 include/linux/spi/spi.h   |   4 ++
 3 files changed, 114 insertions(+), 36 deletions(-)

-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH v2 1/4] spi: Save current RX and TX DMA devices
  2022-09-27 11:21 [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx Vincent Whitchurch
@ 2022-09-27 11:21 ` Vincent Whitchurch
  2022-09-27 11:21 ` [PATCH v2 2/4] spi: Fix cache corruption due to DMA/PIO overlap Vincent Whitchurch
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 13+ messages in thread
From: Vincent Whitchurch @ 2022-09-27 11:21 UTC (permalink / raw)
  To: broonie, krzysztof.kozlowski, andi
  Cc: kernel, Vincent Whitchurch, alim.akhtar, linux-spi, linux-kernel,
	linux-samsung-soc, linux-arm-kernel

Save the current RX and TX DMA devices to avoid having to duplicate the
logic to pick them, since we'll need access to them in some more
functions to fix a bug in the cache handling.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
---
 drivers/spi/spi.c       | 19 ++++---------------
 include/linux/spi/spi.h |  4 ++++
 2 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index ad254b94308e..dd885df23870 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1147,6 +1147,8 @@ static int __spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)
 		}
 	}
 
+	ctlr->cur_rx_dma_dev = rx_dev;
+	ctlr->cur_tx_dma_dev = tx_dev;
 	ctlr->cur_msg_mapped = true;
 
 	return 0;
@@ -1154,26 +1156,13 @@ static int __spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)
 
 static int __spi_unmap_msg(struct spi_controller *ctlr, struct spi_message *msg)
 {
+	struct device *rx_dev = ctlr->cur_rx_dma_dev;
+	struct device *tx_dev = ctlr->cur_tx_dma_dev;
 	struct spi_transfer *xfer;
-	struct device *tx_dev, *rx_dev;
 
 	if (!ctlr->cur_msg_mapped || !ctlr->can_dma)
 		return 0;
 
-	if (ctlr->dma_tx)
-		tx_dev = ctlr->dma_tx->device->dev;
-	else if (ctlr->dma_map_dev)
-		tx_dev = ctlr->dma_map_dev;
-	else
-		tx_dev = ctlr->dev.parent;
-
-	if (ctlr->dma_rx)
-		rx_dev = ctlr->dma_rx->device->dev;
-	else if (ctlr->dma_map_dev)
-		rx_dev = ctlr->dma_map_dev;
-	else
-		rx_dev = ctlr->dev.parent;
-
 	list_for_each_entry(xfer, &msg->transfers, transfer_list) {
 		if (!ctlr->can_dma(ctlr, msg->spi, xfer))
 			continue;
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 6ea889df0813..fbf8c0d95968 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -378,6 +378,8 @@ extern struct spi_device *spi_new_ancillary_device(struct spi_device *spi, u8 ch
  * @cleanup: frees controller-specific state
  * @can_dma: determine whether this controller supports DMA
  * @dma_map_dev: device which can be used for DMA mapping
+ * @cur_rx_dma_dev: device which is currently used for RX DMA mapping
+ * @cur_tx_dma_dev: device which is currently used for TX DMA mapping
  * @queued: whether this controller is providing an internal message queue
  * @kworker: pointer to thread struct for message pump
  * @pump_messages: work struct for scheduling work to the message pump
@@ -610,6 +612,8 @@ struct spi_controller {
 					   struct spi_device *spi,
 					   struct spi_transfer *xfer);
 	struct device *dma_map_dev;
+	struct device *cur_rx_dma_dev;
+	struct device *cur_tx_dma_dev;
 
 	/*
 	 * These hooks are for drivers that want to use the generic
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH v2 2/4] spi: Fix cache corruption due to DMA/PIO overlap
  2022-09-27 11:21 [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx Vincent Whitchurch
  2022-09-27 11:21 ` [PATCH v2 1/4] spi: Save current RX and TX DMA devices Vincent Whitchurch
@ 2022-09-27 11:21 ` Vincent Whitchurch
  2022-09-30 11:20   ` Marek Szyprowski
  2022-09-27 11:21 ` [PATCH v2 3/4] spi: Split transfers larger than max size Vincent Whitchurch
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 13+ messages in thread
From: Vincent Whitchurch @ 2022-09-27 11:21 UTC (permalink / raw)
  To: broonie, krzysztof.kozlowski, andi
  Cc: kernel, Vincent Whitchurch, alim.akhtar, linux-spi, linux-kernel,
	linux-samsung-soc, linux-arm-kernel

The SPI core DMA mapping support performs cache management once for the
entire message and not between transfers, and this leads to cache
corruption if a message has two or more RX transfers with both
transfers targeting the same cache line, and the controller driver
decides to handle one using DMA and the other using PIO (for example,
because one is much larger than the other).

Fix it by syncing before/after the actual transfers.  This also means
that we can skip the sync during the map/unmap of the message.

Fixes: 99adef310f68 ("spi: Provide core support for DMA mapping transfers")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
---
 drivers/spi/spi.c | 109 +++++++++++++++++++++++++++++++++++++---------
 1 file changed, 88 insertions(+), 21 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index dd885df23870..f41a8c2752b8 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1010,9 +1010,9 @@ static void spi_set_cs(struct spi_device *spi, bool enable, bool force)
 }
 
 #ifdef CONFIG_HAS_DMA
-int spi_map_buf(struct spi_controller *ctlr, struct device *dev,
-		struct sg_table *sgt, void *buf, size_t len,
-		enum dma_data_direction dir)
+static int spi_map_buf_attrs(struct spi_controller *ctlr, struct device *dev,
+			     struct sg_table *sgt, void *buf, size_t len,
+			     enum dma_data_direction dir, unsigned long attrs)
 {
 	const bool vmalloced_buf = is_vmalloc_addr(buf);
 	unsigned int max_seg_size = dma_get_max_seg_size(dev);
@@ -1078,28 +1078,39 @@ int spi_map_buf(struct spi_controller *ctlr, struct device *dev,
 		sg = sg_next(sg);
 	}
 
-	ret = dma_map_sg(dev, sgt->sgl, sgt->nents, dir);
-	if (!ret)
-		ret = -ENOMEM;
+	ret = dma_map_sgtable(dev, sgt, dir, attrs);
 	if (ret < 0) {
 		sg_free_table(sgt);
 		return ret;
 	}
 
-	sgt->nents = ret;
-
 	return 0;
 }
 
-void spi_unmap_buf(struct spi_controller *ctlr, struct device *dev,
-		   struct sg_table *sgt, enum dma_data_direction dir)
+int spi_map_buf(struct spi_controller *ctlr, struct device *dev,
+		struct sg_table *sgt, void *buf, size_t len,
+		enum dma_data_direction dir)
+{
+	return spi_map_buf_attrs(ctlr, dev, sgt, buf, len, dir, 0);
+}
+
+static void spi_unmap_buf_attrs(struct spi_controller *ctlr,
+				struct device *dev, struct sg_table *sgt,
+				enum dma_data_direction dir,
+				unsigned long attrs)
 {
 	if (sgt->orig_nents) {
-		dma_unmap_sg(dev, sgt->sgl, sgt->orig_nents, dir);
+		dma_unmap_sgtable(dev, sgt, dir, attrs);
 		sg_free_table(sgt);
 	}
 }
 
+void spi_unmap_buf(struct spi_controller *ctlr, struct device *dev,
+		   struct sg_table *sgt, enum dma_data_direction dir)
+{
+	spi_unmap_buf_attrs(ctlr, dev, sgt, dir, 0);
+}
+
 static int __spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)
 {
 	struct device *tx_dev, *rx_dev;
@@ -1124,24 +1135,30 @@ static int __spi_map_msg(struct spi_controller *ctlr, struct spi_message *msg)
 		rx_dev = ctlr->dev.parent;
 
 	list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+		/* The sync is done before each transfer. */
+		unsigned long attrs = DMA_ATTR_SKIP_CPU_SYNC;
+
 		if (!ctlr->can_dma(ctlr, msg->spi, xfer))
 			continue;
 
 		if (xfer->tx_buf != NULL) {
-			ret = spi_map_buf(ctlr, tx_dev, &xfer->tx_sg,
-					  (void *)xfer->tx_buf, xfer->len,
-					  DMA_TO_DEVICE);
+			ret = spi_map_buf_attrs(ctlr, tx_dev, &xfer->tx_sg,
+						(void *)xfer->tx_buf,
+						xfer->len, DMA_TO_DEVICE,
+						attrs);
 			if (ret != 0)
 				return ret;
 		}
 
 		if (xfer->rx_buf != NULL) {
-			ret = spi_map_buf(ctlr, rx_dev, &xfer->rx_sg,
-					  xfer->rx_buf, xfer->len,
-					  DMA_FROM_DEVICE);
+			ret = spi_map_buf_attrs(ctlr, rx_dev, &xfer->rx_sg,
+						xfer->rx_buf, xfer->len,
+						DMA_FROM_DEVICE, attrs);
 			if (ret != 0) {
-				spi_unmap_buf(ctlr, tx_dev, &xfer->tx_sg,
-					      DMA_TO_DEVICE);
+				spi_unmap_buf_attrs(ctlr, tx_dev,
+						&xfer->tx_sg, DMA_TO_DEVICE,
+						attrs);
+
 				return ret;
 			}
 		}
@@ -1164,17 +1181,52 @@ static int __spi_unmap_msg(struct spi_controller *ctlr, struct spi_message *msg)
 		return 0;
 
 	list_for_each_entry(xfer, &msg->transfers, transfer_list) {
+		/* The sync has already been done after each transfer. */
+		unsigned long attrs = DMA_ATTR_SKIP_CPU_SYNC;
+
 		if (!ctlr->can_dma(ctlr, msg->spi, xfer))
 			continue;
 
-		spi_unmap_buf(ctlr, rx_dev, &xfer->rx_sg, DMA_FROM_DEVICE);
-		spi_unmap_buf(ctlr, tx_dev, &xfer->tx_sg, DMA_TO_DEVICE);
+		spi_unmap_buf_attrs(ctlr, rx_dev, &xfer->rx_sg,
+				    DMA_FROM_DEVICE, attrs);
+		spi_unmap_buf_attrs(ctlr, tx_dev, &xfer->tx_sg,
+				    DMA_TO_DEVICE, attrs);
 	}
 
 	ctlr->cur_msg_mapped = false;
 
 	return 0;
 }
+
+static void spi_dma_sync_for_device(struct spi_controller *ctlr,
+				    struct spi_transfer *xfer)
+{
+	struct device *rx_dev = ctlr->cur_rx_dma_dev;
+	struct device *tx_dev = ctlr->cur_tx_dma_dev;
+
+	if (!ctlr->cur_msg_mapped)
+		return;
+
+	if (xfer->tx_sg.orig_nents)
+		dma_sync_sgtable_for_device(tx_dev, &xfer->tx_sg, DMA_TO_DEVICE);
+	if (xfer->rx_sg.orig_nents)
+		dma_sync_sgtable_for_device(rx_dev, &xfer->rx_sg, DMA_FROM_DEVICE);
+}
+
+static void spi_dma_sync_for_cpu(struct spi_controller *ctlr,
+				 struct spi_transfer *xfer)
+{
+	struct device *rx_dev = ctlr->cur_rx_dma_dev;
+	struct device *tx_dev = ctlr->cur_tx_dma_dev;
+
+	if (!ctlr->cur_msg_mapped)
+		return;
+
+	if (xfer->rx_sg.orig_nents)
+		dma_sync_sgtable_for_cpu(rx_dev, &xfer->rx_sg, DMA_FROM_DEVICE);
+	if (xfer->tx_sg.orig_nents)
+		dma_sync_sgtable_for_cpu(tx_dev, &xfer->tx_sg, DMA_TO_DEVICE);
+}
 #else /* !CONFIG_HAS_DMA */
 static inline int __spi_map_msg(struct spi_controller *ctlr,
 				struct spi_message *msg)
@@ -1187,6 +1239,16 @@ static inline int __spi_unmap_msg(struct spi_controller *ctlr,
 {
 	return 0;
 }
+
+static void spi_dma_sync_for_device(struct spi_controller *ctrl,
+				    struct spi_transfer *xfer)
+{
+}
+
+static void spi_dma_sync_for_cpu(struct spi_controller *ctrl,
+				 struct spi_transfer *xfer)
+{
+}
 #endif /* !CONFIG_HAS_DMA */
 
 static inline int spi_unmap_msg(struct spi_controller *ctlr,
@@ -1445,8 +1507,11 @@ static int spi_transfer_one_message(struct spi_controller *ctlr,
 			reinit_completion(&ctlr->xfer_completion);
 
 fallback_pio:
+			spi_dma_sync_for_device(ctlr, xfer);
 			ret = ctlr->transfer_one(ctlr, msg->spi, xfer);
 			if (ret < 0) {
+				spi_dma_sync_for_cpu(ctlr, xfer);
+
 				if (ctlr->cur_msg_mapped &&
 				   (xfer->error & SPI_TRANS_FAIL_NO_START)) {
 					__spi_unmap_msg(ctlr, msg);
@@ -1469,6 +1534,8 @@ static int spi_transfer_one_message(struct spi_controller *ctlr,
 				if (ret < 0)
 					msg->status = ret;
 			}
+
+			spi_dma_sync_for_cpu(ctlr, xfer);
 		} else {
 			if (xfer->len)
 				dev_err(&msg->spi->dev,
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH v2 3/4] spi: Split transfers larger than max size
  2022-09-27 11:21 [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx Vincent Whitchurch
  2022-09-27 11:21 ` [PATCH v2 1/4] spi: Save current RX and TX DMA devices Vincent Whitchurch
  2022-09-27 11:21 ` [PATCH v2 2/4] spi: Fix cache corruption due to DMA/PIO overlap Vincent Whitchurch
@ 2022-09-27 11:21 ` Vincent Whitchurch
  2023-06-22 19:48   ` Eddie James
  2022-09-27 11:21 ` [PATCH v2 4/4] spi: s3c64xx: Fix large transfers with DMA Vincent Whitchurch
  2022-09-28 17:27 ` [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx Mark Brown
  4 siblings, 1 reply; 13+ messages in thread
From: Vincent Whitchurch @ 2022-09-27 11:21 UTC (permalink / raw)
  To: broonie, krzysztof.kozlowski, andi
  Cc: kernel, Vincent Whitchurch, alim.akhtar, linux-spi, linux-kernel,
	linux-samsung-soc, linux-arm-kernel

A couple of drivers call spi_split_transfers_maxsize() from their
->prepare_message() callbacks to split transfers which are too big for
them to handle.  Add support in the core to do this based on
->max_transfer_size() to avoid code duplication.

Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
---
 drivers/spi/spi.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index f41a8c2752b8..44e4352d948b 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1649,6 +1649,15 @@ static int __spi_pump_transfer_message(struct spi_controller *ctlr,
 
 	trace_spi_message_start(msg);
 
+	ret = spi_split_transfers_maxsize(ctlr, msg,
+					  spi_max_transfer_size(msg->spi),
+					  GFP_KERNEL | GFP_DMA);
+	if (ret) {
+		msg->status = ret;
+		spi_finalize_current_message(ctlr);
+		return ret;
+	}
+
 	if (ctlr->prepare_message) {
 		ret = ctlr->prepare_message(ctlr, msg);
 		if (ret) {
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [PATCH v2 4/4] spi: s3c64xx: Fix large transfers with DMA
  2022-09-27 11:21 [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx Vincent Whitchurch
                   ` (2 preceding siblings ...)
  2022-09-27 11:21 ` [PATCH v2 3/4] spi: Split transfers larger than max size Vincent Whitchurch
@ 2022-09-27 11:21 ` Vincent Whitchurch
  2022-09-28 17:27 ` [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx Mark Brown
  4 siblings, 0 replies; 13+ messages in thread
From: Vincent Whitchurch @ 2022-09-27 11:21 UTC (permalink / raw)
  To: broonie, krzysztof.kozlowski, andi
  Cc: kernel, Vincent Whitchurch, alim.akhtar, linux-spi, linux-kernel,
	linux-samsung-soc, linux-arm-kernel

The COUNT_VALUE in the PACKET_CNT register is 16-bit so the maximum
value is 65535.  Asking the driver to transfer a larger size currently
leads to the DMA transfer timing out.  Implement ->max_transfer_size()
and have the core split the transfer as needed.

Fixes: 230d42d422e7 ("spi: Add s3c64xx SPI Controller driver")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
---
 drivers/spi/spi-s3c64xx.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 651c35dd9124..71d324ec9a70 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -84,6 +84,7 @@
 #define S3C64XX_SPI_ST_TX_FIFORDY		(1<<0)
 
 #define S3C64XX_SPI_PACKET_CNT_EN		(1<<16)
+#define S3C64XX_SPI_PACKET_CNT_MASK		GENMASK(15, 0)
 
 #define S3C64XX_SPI_PND_TX_UNDERRUN_CLR		(1<<4)
 #define S3C64XX_SPI_PND_TX_OVERRUN_CLR		(1<<3)
@@ -711,6 +712,13 @@ static int s3c64xx_spi_prepare_message(struct spi_master *master,
 	return 0;
 }
 
+static size_t s3c64xx_spi_max_transfer_size(struct spi_device *spi)
+{
+	struct spi_controller *ctlr = spi->controller;
+
+	return ctlr->can_dma ? S3C64XX_SPI_PACKET_CNT_MASK : SIZE_MAX;
+}
+
 static int s3c64xx_spi_transfer_one(struct spi_master *master,
 				    struct spi_device *spi,
 				    struct spi_transfer *xfer)
@@ -1152,6 +1160,7 @@ static int s3c64xx_spi_probe(struct platform_device *pdev)
 	master->unprepare_transfer_hardware = s3c64xx_spi_unprepare_transfer;
 	master->prepare_message = s3c64xx_spi_prepare_message;
 	master->transfer_one = s3c64xx_spi_transfer_one;
+	master->max_transfer_size = s3c64xx_spi_max_transfer_size;
 	master->num_chipselect = sci->num_cs;
 	master->use_gpio_descriptors = true;
 	master->dma_alignment = 8;
-- 
2.34.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx
  2022-09-27 11:21 [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx Vincent Whitchurch
                   ` (3 preceding siblings ...)
  2022-09-27 11:21 ` [PATCH v2 4/4] spi: s3c64xx: Fix large transfers with DMA Vincent Whitchurch
@ 2022-09-28 17:27 ` Mark Brown
  4 siblings, 0 replies; 13+ messages in thread
From: Mark Brown @ 2022-09-28 17:27 UTC (permalink / raw)
  To: andi, krzysztof.kozlowski, Vincent Whitchurch
  Cc: alim.akhtar, linux-samsung-soc, linux-spi, kernel, linux-kernel,
	linux-arm-kernel

On Tue, 27 Sep 2022 13:21:13 +0200, Vincent Whitchurch wrote:
> v2:
> - Drop merged patch adding new test to spi-loopback-test
> - Fix compiler warning in !HAS_DMA builds
> - Add support to split transfers to core
> 
> This series fixes some bugs I found while running spi-loopback-test with
> spi-s3c64xx.  The first problem (which I actually noticed while trying to fix
> the second problem with transfers >64KiB) seems to be a generic issue which
> affects several drivers so I fixed it in the core.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/4] spi: Save current RX and TX DMA devices
      commit: f25723dcef4a38f6a39e17afeabd1adf6402230e
[2/4] spi: Fix cache corruption due to DMA/PIO overlap
      commit: 0c17ba73c08ff2690c1eff8df374b6709eed55ce
[3/4] spi: Split transfers larger than max size
      commit: 8d699ff95534747e394e0830399b8d5dcf03e738
[4/4] spi: s3c64xx: Fix large transfers with DMA
      commit: 1224e29572f655facfcd850cf0f0a4784f36a903

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 2/4] spi: Fix cache corruption due to DMA/PIO overlap
  2022-09-27 11:21 ` [PATCH v2 2/4] spi: Fix cache corruption due to DMA/PIO overlap Vincent Whitchurch
@ 2022-09-30 11:20   ` Marek Szyprowski
  2022-09-30 12:10     ` Robin Murphy
  0 siblings, 1 reply; 13+ messages in thread
From: Marek Szyprowski @ 2022-09-30 11:20 UTC (permalink / raw)
  To: Vincent Whitchurch, broonie, krzysztof.kozlowski, andi,
	Christoph Hellwig, Robin Murphy
  Cc: kernel, alim.akhtar, linux-spi, linux-kernel, linux-samsung-soc,
	linux-arm-kernel, iommu

Hi,

CCed: Christoph and Robin, as the issue is partially dma-mapping related.

On 27.09.2022 13:21, Vincent Whitchurch wrote:
> The SPI core DMA mapping support performs cache management once for the
> entire message and not between transfers, and this leads to cache
> corruption if a message has two or more RX transfers with both
> transfers targeting the same cache line, and the controller driver
> decides to handle one using DMA and the other using PIO (for example,
> because one is much larger than the other).
>
> Fix it by syncing before/after the actual transfers.  This also means
> that we can skip the sync during the map/unmap of the message.
>
> Fixes: 99adef310f68 ("spi: Provide core support for DMA mapping transfers")
> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
> ---

This patch landed in linux next-20220929 as commit 0c17ba73c08f ("spi: 
Fix cache corruption due to DMA/PIO overlap"). Unfortunately it causes 
kernel oops on one of my test systems:

8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[0000000c] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in: cmac bnep btsdio hci_uart btbcm s5p_mfc btintel 
brcmfmac bluetooth videobuf2_dma_contig videobuf2_memops videobuf2_v4l2 
videobuf2_common videodev cfg80211 mc ecdh_generic ecc brcmutil
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 
6.0.0-rc7-next-20220929-dirty #12903
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events ax88796c_work
PC is at dma_direct_sync_sg_for_device+0x24/0xb8
LR is at spi_transfer_one_message+0x4c4/0xabc
pc : [<c01cbcf0>]    lr : [<c0739fcc>]    psr: 20000013
...
Process kworker/0:1 (pid: 12, stack limit = 0xca429928)
Stack: (0xe0071d38 to 0xe0072000)
...
  dma_direct_sync_sg_for_device from spi_transfer_one_message+0x4c4/0xabc
  spi_transfer_one_message from __spi_pump_transfer_message+0x300/0x770
  __spi_pump_transfer_message from __spi_sync+0x304/0x3f4
  __spi_sync from spi_sync+0x28/0x40
  spi_sync from axspi_read_rxq+0x98/0xc8
  axspi_read_rxq from ax88796c_work+0x7a8/0xf6c
  ax88796c_work from process_one_work+0x288/0x774
  process_one_work from worker_thread+0x44/0x504
  worker_thread from kthread+0xf0/0x124
  kthread from ret_from_fork+0x14/0x2c
Exception stack(0xe0071fb0 to 0xe0071ff8)
...
---[ end trace 0000000000000000 ]---

This happens because sg_free_table() doesn't clear table->orig_nents nor 
table->nents. If the given spi xfer object is reused without dma-mapped 
buffer, then a NULL pointer de-reference happens at table->sgl 
spi_dma_sync_for_device()/spi_dma_sync_for_cpu(). A possible fix would 
be to zero table->orig_nents in spi_unmap_buf_attrs(). I will send a 
patch for this soon.

However, I think that clearing table->orig_nents and table->nents should 
be added to __sg_free_table() in lib/scatterlist.c to avoid this kind of 
issue in the future. This however will be a significant change that 
might break code somewhere, if it relies on the nents/orig_nents value 
after calling sg_free_table(). Christoph, Robin - what is your opinion?


>   drivers/spi/spi.c | 109 +++++++++++++++++++++++++++++++++++++---------
>   1 file changed, 88 insertions(+), 21 deletions(-)
>
> ...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 2/4] spi: Fix cache corruption due to DMA/PIO overlap
  2022-09-30 11:20   ` Marek Szyprowski
@ 2022-09-30 12:10     ` Robin Murphy
  2022-10-03 11:29       ` Vincent Whitchurch
  0 siblings, 1 reply; 13+ messages in thread
From: Robin Murphy @ 2022-09-30 12:10 UTC (permalink / raw)
  To: Marek Szyprowski, Vincent Whitchurch, broonie,
	krzysztof.kozlowski, andi, Christoph Hellwig
  Cc: kernel, alim.akhtar, linux-spi, linux-kernel, linux-samsung-soc,
	linux-arm-kernel, iommu

On 2022-09-30 12:20, Marek Szyprowski wrote:
> Hi,
> 
> CCed: Christoph and Robin, as the issue is partially dma-mapping related.
> 
> On 27.09.2022 13:21, Vincent Whitchurch wrote:
>> The SPI core DMA mapping support performs cache management once for the
>> entire message and not between transfers, and this leads to cache
>> corruption if a message has two or more RX transfers with both
>> transfers targeting the same cache line, and the controller driver
>> decides to handle one using DMA and the other using PIO (for example,
>> because one is much larger than the other).
>>
>> Fix it by syncing before/after the actual transfers.  This also means
>> that we can skip the sync during the map/unmap of the message.
>>
>> Fixes: 99adef310f68 ("spi: Provide core support for DMA mapping transfers")
>> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
>> ---
> 
> This patch landed in linux next-20220929 as commit 0c17ba73c08f ("spi:
> Fix cache corruption due to DMA/PIO overlap"). Unfortunately it causes
> kernel oops on one of my test systems:
> 
> 8<--- cut here ---
> Unable to handle kernel NULL pointer dereference at virtual address 0000000c
> [0000000c] *pgd=00000000
> Internal error: Oops: 5 [#1] PREEMPT SMP ARM
> Modules linked in: cmac bnep btsdio hci_uart btbcm s5p_mfc btintel
> brcmfmac bluetooth videobuf2_dma_contig videobuf2_memops videobuf2_v4l2
> videobuf2_common videodev cfg80211 mc ecdh_generic ecc brcmutil
> CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted
> 6.0.0-rc7-next-20220929-dirty #12903
> Hardware name: Samsung Exynos (Flattened Device Tree)
> Workqueue: events ax88796c_work
> PC is at dma_direct_sync_sg_for_device+0x24/0xb8
> LR is at spi_transfer_one_message+0x4c4/0xabc
> pc : [<c01cbcf0>]    lr : [<c0739fcc>]    psr: 20000013
> ...
> Process kworker/0:1 (pid: 12, stack limit = 0xca429928)
> Stack: (0xe0071d38 to 0xe0072000)
> ...
>    dma_direct_sync_sg_for_device from spi_transfer_one_message+0x4c4/0xabc
>    spi_transfer_one_message from __spi_pump_transfer_message+0x300/0x770
>    __spi_pump_transfer_message from __spi_sync+0x304/0x3f4
>    __spi_sync from spi_sync+0x28/0x40
>    spi_sync from axspi_read_rxq+0x98/0xc8
>    axspi_read_rxq from ax88796c_work+0x7a8/0xf6c
>    ax88796c_work from process_one_work+0x288/0x774
>    process_one_work from worker_thread+0x44/0x504
>    worker_thread from kthread+0xf0/0x124
>    kthread from ret_from_fork+0x14/0x2c
> Exception stack(0xe0071fb0 to 0xe0071ff8)
> ...
> ---[ end trace 0000000000000000 ]---
> 
> This happens because sg_free_table() doesn't clear table->orig_nents nor
> table->nents. If the given spi xfer object is reused without dma-mapped
> buffer, then a NULL pointer de-reference happens at table->sgl
> spi_dma_sync_for_device()/spi_dma_sync_for_cpu(). A possible fix would
> be to zero table->orig_nents in spi_unmap_buf_attrs(). I will send a
> patch for this soon.
> 
> However, I think that clearing table->orig_nents and table->nents should
> be added to __sg_free_table() in lib/scatterlist.c to avoid this kind of
> issue in the future. This however will be a significant change that
> might break code somewhere, if it relies on the nents/orig_nents value
> after calling sg_free_table(). Christoph, Robin - what is your opinion?

Yes, that makes sense to me: the table->nents etc. fields logically 
describe the list that table->sgl points to, so when it sets that to 
NULL it seems right to also update the corresponding fields accordingly. 
I don't see much good reason for code to poking into an sg_table after 
it's been freed, other that to reinitialise it with sg_alloc_table() 
which would overwrite those fields anyway, so I can't imagine it's a 
particularly risky change.

That said, maybe this is something that's better to catch than to paper 
over? Arguably the real bug here is that spi_unmap_buf() and the new 
sync functions should use the same "{tx,rx}_buf != NULL" condition that 
spi_map_buf() used for the DMA mapping decision in the first place.

Thanks,
Robin.

> 
> 
>>    drivers/spi/spi.c | 109 +++++++++++++++++++++++++++++++++++++---------
>>    1 file changed, 88 insertions(+), 21 deletions(-)
>>
>> ...
> 
> Best regards

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 2/4] spi: Fix cache corruption due to DMA/PIO overlap
  2022-09-30 12:10     ` Robin Murphy
@ 2022-10-03 11:29       ` Vincent Whitchurch
  0 siblings, 0 replies; 13+ messages in thread
From: Vincent Whitchurch @ 2022-10-03 11:29 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Marek Szyprowski, broonie, krzysztof.kozlowski, andi,
	Christoph Hellwig, kernel, alim.akhtar, linux-spi, linux-kernel,
	linux-samsung-soc, linux-arm-kernel, iommu

On Fri, Sep 30, 2022 at 02:10:28PM +0200, Robin Murphy wrote:
> That said, maybe this is something that's better to catch than to paper 
> over? Arguably the real bug here is that spi_unmap_buf() and the new 
> sync functions should use the same "{tx,rx}_buf != NULL" condition that 
> spi_map_buf() used for the DMA mapping decision in the first place.

The "{tx,rx}_buf != NULL" condition would not sufficient on its own; the
call to ->can_dma() is also part of the condition.  __spi_unmap_msg()
already does the ->can_dma() call even though it checks for the
orig_nents != 0 condition instead of the tx,rx_buf != NULL, but I
omitted that call in the new sync functions, incorrectly believing it to
be redundant.

It looks like __spi_unmap_msg() would have triggered a similar crash
even before this patch, if a client had reused an xfer with both rx and
tx the first time, and only one of them enabled the next time around
(and with ->can_dma() returning true both times).  Testing the
{tx,rx}_buf instead of sgt->orig_nents would have avoided that, as you
say.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 3/4] spi: Split transfers larger than max size
  2022-09-27 11:21 ` [PATCH v2 3/4] spi: Split transfers larger than max size Vincent Whitchurch
@ 2023-06-22 19:48   ` Eddie James
  2023-06-22 21:16     ` Mark Brown
  0 siblings, 1 reply; 13+ messages in thread
From: Eddie James @ 2023-06-22 19:48 UTC (permalink / raw)
  To: Vincent Whitchurch, broonie, krzysztof.kozlowski, andi
  Cc: kernel, alim.akhtar, linux-spi, linux-kernel, linux-samsung-soc,
	linux-arm-kernel


On 9/27/22 06:21, Vincent Whitchurch wrote:
> A couple of drivers call spi_split_transfers_maxsize() from their
> ->prepare_message() callbacks to split transfers which are too big for
> them to handle.  Add support in the core to do this based on
> ->max_transfer_size() to avoid code duplication.


Hello,

I've been testing AT25 functionality in linux 6.1 and I believe this 
patch is breaking the AT25 protocol. It will split a write command up 
such that some of the data is in a different transfer than  the write 
enable and address. According to my understanding of the AT25 spec, that 
doesn't work... Someone correct me if I'm wrong though. Do we need a 
flag to enable/disable this behavior depending on the client perhaps?


Thanks,

Eddie


>
> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
> ---
>   drivers/spi/spi.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
>
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index f41a8c2752b8..44e4352d948b 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -1649,6 +1649,15 @@ static int __spi_pump_transfer_message(struct spi_controller *ctlr,
>   
>   	trace_spi_message_start(msg);
>   
> +	ret = spi_split_transfers_maxsize(ctlr, msg,
> +					  spi_max_transfer_size(msg->spi),
> +					  GFP_KERNEL | GFP_DMA);
> +	if (ret) {
> +		msg->status = ret;
> +		spi_finalize_current_message(ctlr);
> +		return ret;
> +	}
> +
>   	if (ctlr->prepare_message) {
>   		ret = ctlr->prepare_message(ctlr, msg);
>   		if (ret) {

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 3/4] spi: Split transfers larger than max size
  2023-06-22 19:48   ` Eddie James
@ 2023-06-22 21:16     ` Mark Brown
  2023-06-23 16:45       ` Eddie James
  0 siblings, 1 reply; 13+ messages in thread
From: Mark Brown @ 2023-06-22 21:16 UTC (permalink / raw)
  To: Eddie James
  Cc: Vincent Whitchurch, krzysztof.kozlowski, andi, kernel,
	alim.akhtar, linux-spi, linux-kernel, linux-samsung-soc,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 1657 bytes --]

On Thu, Jun 22, 2023 at 02:48:36PM -0500, Eddie James wrote:
> On 9/27/22 06:21, Vincent Whitchurch wrote:
> > A couple of drivers call spi_split_transfers_maxsize() from their
> > ->prepare_message() callbacks to split transfers which are too big for
> > them to handle.  Add support in the core to do this based on
> > ->max_transfer_size() to avoid code duplication.

> I've been testing AT25 functionality in linux 6.1 and I believe this patch
> is breaking the AT25 protocol. It will split a write command up such that
> some of the data is in a different transfer than  the write enable and
> address. According to my understanding of the AT25 spec, that doesn't
> work... Someone correct me if I'm wrong though. Do we need a flag to
> enable/disable this behavior depending on the client perhaps?

Could you be more specific about the manner in which you think this is
breaking things?  The size of transfer is immaterial to the client
device on SPI, the client will be counting clocks while the chip select
is asserted.  How the controller chooses to split things up is really
not particularly visible or relevant, it might bitbang things out one
bit at a time, transfer a single word at a time or batch things up
further.  So long as the chip select is asserted it's all the same to
the client device.

In any case this is all based on the maximum transfer size advertised by
the conteroller driver, if the device can physically handle larger
transfers then there's no reason for it to set a limit.  If the driver
can't physically handle larger transfers and it does make a difference
then the system simply won't work.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 3/4] spi: Split transfers larger than max size
  2023-06-22 21:16     ` Mark Brown
@ 2023-06-23 16:45       ` Eddie James
  2023-06-23 17:16         ` Mark Brown
  0 siblings, 1 reply; 13+ messages in thread
From: Eddie James @ 2023-06-23 16:45 UTC (permalink / raw)
  To: Mark Brown
  Cc: Vincent Whitchurch, krzysztof.kozlowski, andi, kernel,
	alim.akhtar, linux-spi, linux-kernel, linux-samsung-soc,
	linux-arm-kernel


On 6/22/23 16:16, Mark Brown wrote:
> On Thu, Jun 22, 2023 at 02:48:36PM -0500, Eddie James wrote:
>> On 9/27/22 06:21, Vincent Whitchurch wrote:
>>> A couple of drivers call spi_split_transfers_maxsize() from their
>>> ->prepare_message() callbacks to split transfers which are too big for
>>> them to handle.  Add support in the core to do this based on
>>> ->max_transfer_size() to avoid code duplication.
>> I've been testing AT25 functionality in linux 6.1 and I believe this patch
>> is breaking the AT25 protocol. It will split a write command up such that
>> some of the data is in a different transfer than  the write enable and
>> address. According to my understanding of the AT25 spec, that doesn't
>> work... Someone correct me if I'm wrong though. Do we need a flag to
>> enable/disable this behavior depending on the client perhaps?
> Could you be more specific about the manner in which you think this is
> breaking things?  The size of transfer is immaterial to the client
> device on SPI, the client will be counting clocks while the chip select
> is asserted.  How the controller chooses to split things up is really
> not particularly visible or relevant, it might bitbang things out one
> bit at a time, transfer a single word at a time or batch things up
> further.  So long as the chip select is asserted it's all the same to
> the client device.


Ok, I understand better now. Agreed it shouldn't make a difference, but 
this is actually a limitation of the spi controller I'm using (spi-fsi). 
The controller cannot handle multiple transfers keeping the chip select 
enabled... I guess the driver can batch transfers in the message to get 
around this, unless you want to add a flag for that behavior.


>
> In any case this is all based on the maximum transfer size advertised by
> the conteroller driver, if the device can physically handle larger
> transfers then there's no reason for it to set a limit.  If the driver
> can't physically handle larger transfers and it does make a difference
> then the system simply won't work.


Yep, this is also an artifact of the spi-fsi driver having different 
transfer size limits for writes and reads. Funnily enough the at25 
driver doesn't truly respect the max transfer size (it doesn't include 
the write command and address bytes in the calculation against the max 
transfer size) so that's how this worked previously.

Thanks!

Eddie



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH v2 3/4] spi: Split transfers larger than max size
  2023-06-23 16:45       ` Eddie James
@ 2023-06-23 17:16         ` Mark Brown
  0 siblings, 0 replies; 13+ messages in thread
From: Mark Brown @ 2023-06-23 17:16 UTC (permalink / raw)
  To: Eddie James
  Cc: Vincent Whitchurch, krzysztof.kozlowski, andi, kernel,
	alim.akhtar, linux-spi, linux-kernel, linux-samsung-soc,
	linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 2907 bytes --]

On Fri, Jun 23, 2023 at 11:45:19AM -0500, Eddie James wrote:
> On 6/22/23 16:16, Mark Brown wrote:
> > On Thu, Jun 22, 2023 at 02:48:36PM -0500, Eddie James wrote:
> > > On 9/27/22 06:21, Vincent Whitchurch wrote:

> > > > A couple of drivers call spi_split_transfers_maxsize() from their
> > > > ->prepare_message() callbacks to split transfers which are too big for
> > > > them to handle.  Add support in the core to do this based on
> > > > ->max_transfer_size() to avoid code duplication.

> > > I've been testing AT25 functionality in linux 6.1 and I believe this patch
> > > is breaking the AT25 protocol. It will split a write command up such that
> > > some of the data is in a different transfer than  the write enable and

> > Could you be more specific about the manner in which you think this is
> > breaking things?  The size of transfer is immaterial to the client

> Ok, I understand better now. Agreed it shouldn't make a difference, but this
> is actually a limitation of the spi controller I'm using (spi-fsi). The
> controller cannot handle multiple transfers keeping the chip select
> enabled... I guess the driver can batch transfers in the message to get
> around this, unless you want to add a flag for that behavior.

Client drivers should in general just generate messages corresponding to
the desired result visible to the device and let the controller worry
about how to actually accomplish that, splitting transfers needlessly is
just going to create overheads.  If there's scatter/gather going on
that does complicate things a bit though so it's not always going to
happen.  If the controller driver needs to rewrite the message to
combine transfers then it should do that (or tell the core to do so on
it's behalf), just like with splitting transfers due to length limits.

> > In any case this is all based on the maximum transfer size advertised by
> > the conteroller driver, if the device can physically handle larger
> > transfers then there's no reason for it to set a limit.  If the driver
> > can't physically handle larger transfers and it does make a difference
> > then the system simply won't work.

> Yep, this is also an artifact of the spi-fsi driver having different
> transfer size limits for writes and reads. Funnily enough the at25 driver
> doesn't truly respect the max transfer size (it doesn't include the write
> command and address bytes in the calculation against the max transfer size)
> so that's how this worked previously.

Yes, the logic there looks incorrect.  As well as the issue you've
identified the driver should really be using spi_max_message_size(),
with a controller that can't control chip select effectivley like the
FSI driver that'll be the same a the transfer size but other drivers
will be able to chain multiple transfers together even if there's limits
on the transfer length.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2023-06-23 17:17 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-27 11:21 [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx Vincent Whitchurch
2022-09-27 11:21 ` [PATCH v2 1/4] spi: Save current RX and TX DMA devices Vincent Whitchurch
2022-09-27 11:21 ` [PATCH v2 2/4] spi: Fix cache corruption due to DMA/PIO overlap Vincent Whitchurch
2022-09-30 11:20   ` Marek Szyprowski
2022-09-30 12:10     ` Robin Murphy
2022-10-03 11:29       ` Vincent Whitchurch
2022-09-27 11:21 ` [PATCH v2 3/4] spi: Split transfers larger than max size Vincent Whitchurch
2023-06-22 19:48   ` Eddie James
2023-06-22 21:16     ` Mark Brown
2023-06-23 16:45       ` Eddie James
2023-06-23 17:16         ` Mark Brown
2022-09-27 11:21 ` [PATCH v2 4/4] spi: s3c64xx: Fix large transfers with DMA Vincent Whitchurch
2022-09-28 17:27 ` [PATCH v2 0/4] spi: Fix DMA bugs in (not only) spi-s3c64xx Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).