All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Packham <chris.packham@alliedtelesis.co.nz>
To: broonie@kernel.org, npiggin@gmail.com, hkallweit1@gmail.com
Cc: linux-spi@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-kernel@vger.kernel.org,
	Chris Packham <chris.packham@alliedtelesis.co.nz>,
	stable@vger.kernel.org
Subject: [PATCH] spi: fsl-espi: Only process interrupts for expected events
Date: Fri,  4 Sep 2020 12:28:12 +1200	[thread overview]
Message-ID: <20200904002812.7300-1-chris.packham@alliedtelesis.co.nz> (raw)

The SPIE register contains counts for the TX FIFO so any time the irq
handler was invoked we would attempt to process the RX/TX fifos. Use the
SPIM value to mask the events so that we only process interrupts that
were expected.

This was a latent issue exposed by commit 3282a3da25bd ("powerpc/64:
Implement soft interrupt replay in C").

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: stable@vger.kernel.org
---

Notes:
    I've tested this on a T2080RDB and a custom board using the T2081 SoC. With
    this change I don't see any spurious instances of the "Transfer done but
    SPIE_DON isn't set!" or "Transfer done but rx/tx fifo's aren't empty!" messages
    and the updates to spi flash are successful.
    
    I think this should go into the stable trees that contain 3282a3da25bd but I
    haven't added a Fixes: tag because I think 3282a3da25bd exposed the issue as
    opposed to causing it.

 drivers/spi/spi-fsl-espi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
index 7e7c92cafdbb..cb120b68c0e2 100644
--- a/drivers/spi/spi-fsl-espi.c
+++ b/drivers/spi/spi-fsl-espi.c
@@ -574,13 +574,14 @@ static void fsl_espi_cpu_irq(struct fsl_espi *espi, u32 events)
 static irqreturn_t fsl_espi_irq(s32 irq, void *context_data)
 {
 	struct fsl_espi *espi = context_data;
-	u32 events;
+	u32 events, mask;
 
 	spin_lock(&espi->lock);
 
 	/* Get interrupt events(tx/rx) */
 	events = fsl_espi_read_reg(espi, ESPI_SPIE);
-	if (!events) {
+	mask = fsl_espi_read_reg(espi, ESPI_SPIM);
+	if (!(events & mask)) {
 		spin_unlock(&espi->lock);
 		return IRQ_NONE;
 	}
-- 
2.28.0


WARNING: multiple messages have this Message-ID (diff)
From: Chris Packham <chris.packham@alliedtelesis.co.nz>
To: broonie@kernel.org, npiggin@gmail.com, hkallweit1@gmail.com
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org, linux-spi@vger.kernel.org
Subject: [PATCH] spi: fsl-espi: Only process interrupts for expected events
Date: Fri,  4 Sep 2020 12:28:12 +1200	[thread overview]
Message-ID: <20200904002812.7300-1-chris.packham@alliedtelesis.co.nz> (raw)

The SPIE register contains counts for the TX FIFO so any time the irq
handler was invoked we would attempt to process the RX/TX fifos. Use the
SPIM value to mask the events so that we only process interrupts that
were expected.

This was a latent issue exposed by commit 3282a3da25bd ("powerpc/64:
Implement soft interrupt replay in C").

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: stable@vger.kernel.org
---

Notes:
    I've tested this on a T2080RDB and a custom board using the T2081 SoC. With
    this change I don't see any spurious instances of the "Transfer done but
    SPIE_DON isn't set!" or "Transfer done but rx/tx fifo's aren't empty!" messages
    and the updates to spi flash are successful.
    
    I think this should go into the stable trees that contain 3282a3da25bd but I
    haven't added a Fixes: tag because I think 3282a3da25bd exposed the issue as
    opposed to causing it.

 drivers/spi/spi-fsl-espi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c
index 7e7c92cafdbb..cb120b68c0e2 100644
--- a/drivers/spi/spi-fsl-espi.c
+++ b/drivers/spi/spi-fsl-espi.c
@@ -574,13 +574,14 @@ static void fsl_espi_cpu_irq(struct fsl_espi *espi, u32 events)
 static irqreturn_t fsl_espi_irq(s32 irq, void *context_data)
 {
 	struct fsl_espi *espi = context_data;
-	u32 events;
+	u32 events, mask;
 
 	spin_lock(&espi->lock);
 
 	/* Get interrupt events(tx/rx) */
 	events = fsl_espi_read_reg(espi, ESPI_SPIE);
-	if (!events) {
+	mask = fsl_espi_read_reg(espi, ESPI_SPIM);
+	if (!(events & mask)) {
 		spin_unlock(&espi->lock);
 		return IRQ_NONE;
 	}
-- 
2.28.0


             reply	other threads:[~2020-09-04  0:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-04  0:28 Chris Packham [this message]
2020-09-04  0:28 ` [PATCH] spi: fsl-espi: Only process interrupts for expected events Chris Packham
2020-09-13 22:03 ` Chris Packham
2020-09-13 22:03   ` Chris Packham
2020-09-14  2:28   ` Nicholas Piggin
2020-09-14  2:28     ` Nicholas Piggin
2020-09-14  9:06     ` Joakim Tjernlund
2020-09-14  9:06       ` Joakim Tjernlund
2020-09-21 21:40 ` Mark Brown
2020-09-21 21:40   ` Mark Brown
2020-09-23 20:27 ` Heiner Kallweit
2020-09-23 20:27   ` Heiner Kallweit
2020-09-23 21:01   ` Chris Packham
2020-09-23 21:01     ` Chris Packham

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=20200904002812.7300-1-chris.packham@alliedtelesis.co.nz \
    --to=chris.packham@alliedtelesis.co.nz \
    --cc=broonie@kernel.org \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=npiggin@gmail.com \
    --cc=stable@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.