From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: James Clark <james.clark@linaro.org>
Cc: Vladimir Oltean <olteanv@gmail.com>,
Mark Brown <broonie@kernel.org>,
linux-spi@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 4/4] spi: spi-fsl-dspi: Report FIFO overflows as errors
Date: Wed, 11 Jun 2025 00:52:33 +0300 [thread overview]
Message-ID: <20250610215233.35ikv4sslkyukgwr@skbuf> (raw)
In-Reply-To: <20250609-james-nxp-spi-dma-v1-4-2b831e714be2@linaro.org>
On Mon, Jun 09, 2025 at 04:32:41PM +0100, James Clark wrote:
> In target mode, the host sending more data than can be consumed would be
> a common problem for any message exceeding the FIFO or DMA buffer size.
> Cancel the whole message as soon as this condition is hit as the message
> will be corrupted.
>
> Only do this for target mode in a DMA transfer because we need to add a
> register read. In IRQ and polling modes always do it because SPI_SR was
> already read and it might catch some host mode programming/buffer
> management errors too.
>
> Signed-off-by: James Clark <james.clark@linaro.org>
> ---
> drivers/spi/spi-fsl-dspi.c | 31 ++++++++++++++++++++++++++++---
> 1 file changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index e211e44e977f..75767d756496 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -228,6 +228,7 @@ struct fsl_dspi {
> const struct fsl_dspi_devtype_data *devtype_data;
>
> struct completion xfer_done;
> + int xfer_status;
This is certainly simple, and simple is not bad.
But based on the fact that you care about the xfer_status only when
there's an associated dspi->cur_msg, have you considered to update
dspi->cur_msg->status directly?
You'd need to reset dspi->cur_msg to NULL at the end of
dspi_transfer_one_message(), and then check for NULL when you update
the transfer status.
>
> struct fsl_dspi_dma *dma;
>
> @@ -504,12 +505,22 @@ static int dspi_next_xfer_dma_submit(struct fsl_dspi *dspi)
>
> static void dspi_setup_accel(struct fsl_dspi *dspi);
>
> +static bool dspi_is_fifo_overflow(struct fsl_dspi *dspi, u32 spi_sr)
Can you name this some way else, like dspi_fifo_error()? It's strange
for a reader for this to return true on an underflow.
> +{
> + if (spi_sr & (SPI_SR_TFUF | SPI_SR_RFOF)) {
> + dev_err(&dspi->pdev->dev, "FIFO under/overflow");
Missing \n.
And you should use dev_err_ratelimited(), as you don't want an external
entity, when in target mode, to DoS you.
Also, could there be individual error messages for TFUF and for RFOF?
If you are concerned about the penalty for the error-free case, make the
check two-level. First for all errors, then for individual errors.
> + return true;
> + }
> + return false;
> +}
> +
> static int dspi_dma_xfer(struct fsl_dspi *dspi)
> {
> struct spi_message *message = dspi->cur_msg;
> int max_words = dspi_dma_max_datawords(dspi);
> struct device *dev = &dspi->pdev->dev;
> int ret = 0;
> + u32 spi_sr;
>
> /*
> * dspi->len gets decremented by dspi_pop_tx_pushr in
> @@ -531,6 +542,12 @@ static int dspi_dma_xfer(struct fsl_dspi *dspi)
> dev_err(dev, "DMA transfer failed\n");
> break;
> }
> +
> + if (spi_controller_is_target(dspi->ctlr)) {
> + regmap_read(dspi->regmap, SPI_SR, &spi_sr);
> + if (dspi_is_fifo_overflow(dspi, spi_sr))
> + return -EIO;
> + }
> }
Can this go within this block from dspi_next_xfer_dma_submit() instead?
if (spi_controller_is_target(dspi->ctlr)) {
wait_for_completion_interruptible(&dspi->dma->cmd_rx_complete);
// here
return 0;
}
>
> return ret;
> @@ -918,6 +935,8 @@ static int dspi_poll(struct fsl_dspi *dspi)
> regmap_read(dspi->regmap, SPI_SR, &spi_sr);
> regmap_write(dspi->regmap, SPI_SR, spi_sr);
>
> + if (dspi_is_fifo_overflow(dspi, spi_sr))
> + return -EIO;
> if (spi_sr & SPI_SR_CMDTCF)
> break;
> } while (--tries);
> @@ -939,8 +958,12 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id)
> if (!(spi_sr & SPI_SR_CMDTCF))
> return IRQ_NONE;
>
> - if (dspi_rxtx(dspi) == 0)
> + if (dspi_is_fifo_overflow(dspi, spi_sr)) {
> + WRITE_ONCE(dspi->xfer_status, -EIO);
> + complete(&dspi->xfer_done);
> + } else if (dspi_rxtx(dspi) == 0) {
> complete(&dspi->xfer_done);
> + }
>
> return IRQ_HANDLED;
> }
> @@ -1032,13 +1055,15 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,
> if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) {
> status = dspi_dma_xfer(dspi);
> } else {
> - if (dspi->irq)
> + if (dspi->irq) {
> + WRITE_ONCE(dspi->xfer_status, 0);
> reinit_completion(&dspi->xfer_done);
> -
Nitpick: The blank line was doing fine here.
> + }
> dspi_fifo_write(dspi);
>
> if (dspi->irq) {
> wait_for_completion(&dspi->xfer_done);
> + status = READ_ONCE(dspi->xfer_status);
> } else {
> do {
> status = dspi_poll(dspi);
>
> --
> 2.34.1
>
next prev parent reply other threads:[~2025-06-10 21:52 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 15:32 [PATCH 0/4] spi: spi-fsl-dspi: Target mode improvements James Clark
2025-06-09 15:32 ` [PATCH 1/4] spi: spi-fsl-dspi: Clear completion counter before initiating transfer James Clark
2025-06-10 11:34 ` Vladimir Oltean
2025-06-10 15:41 ` James Clark
2025-06-10 21:01 ` Vladimir Oltean
2025-06-10 21:31 ` Vladimir Oltean
2025-06-11 9:12 ` James Clark
2025-06-09 15:32 ` [PATCH 2/4] spi: spi-fsl-dspi: Use non-coherent memory for DMA James Clark
2025-06-10 8:26 ` Arnd Bergmann
2025-06-10 9:03 ` James Clark
2025-06-10 15:15 ` Frank Li
2025-06-10 15:46 ` James Clark
2025-06-13 15:56 ` David Laight
2025-06-10 15:48 ` Arnd Bergmann
2025-06-10 15:56 ` Frank Li
2025-06-11 9:01 ` Vladimir Oltean
2025-06-12 11:05 ` James Clark
2025-06-12 11:15 ` Vladimir Oltean
2025-06-12 14:14 ` James Clark
2025-06-12 14:23 ` Vladimir Oltean
2025-06-12 14:28 ` James Clark
2025-06-12 14:31 ` Vladimir Oltean
2025-06-12 14:35 ` James Clark
2025-06-12 14:36 ` Vladimir Oltean
2025-06-12 15:36 ` James Clark
2025-06-12 15:37 ` James Clark
2025-06-12 14:43 ` Mark Brown
2025-06-12 15:47 ` James Clark
2025-06-12 15:51 ` Vladimir Oltean
2025-06-12 15:40 ` Arnd Bergmann
2025-06-12 11:15 ` Arnd Bergmann
2025-06-09 15:32 ` [PATCH 3/4] spi: spi-fsl-dspi: Increase DMA buffer size James Clark
2025-06-09 15:32 ` [PATCH 4/4] spi: spi-fsl-dspi: Report FIFO overflows as errors James Clark
2025-06-10 21:52 ` Vladimir Oltean [this message]
2025-06-11 14:40 ` James Clark
2025-06-11 14:56 ` Vladimir Oltean
2025-06-11 15:00 ` James Clark
2025-06-30 11:40 ` [PATCH 0/4] spi: spi-fsl-dspi: Target mode improvements Mark Brown
2025-06-30 12:23 ` James Clark
2025-06-30 12:25 ` Mark Brown
2025-06-30 12:36 ` James Clark
2025-06-30 12:40 ` Mark Brown
2025-06-30 12:54 ` James Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250610215233.35ikv4sslkyukgwr@skbuf \
--to=vladimir.oltean@nxp.com \
--cc=broonie@kernel.org \
--cc=imx@lists.linux.dev \
--cc=james.clark@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=olteanv@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).