* [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
* 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
* [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
* 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
* [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
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).