| Message ID | 20201005142109.694666032@linuxfoundation.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | None | expand |
Hi! > [ Upstream commit b867eef4cf548cd9541225aadcdcee644669b9e1 ] > > 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"). We don't seem to have commit 3282... in 4.19, so we don't need this one in 4.19-stable according to the changelog. Best regards, Pavel
On 7/10/20 8:36 am, Pavel Machek wrote: > Hi! > >> [ Upstream commit b867eef4cf548cd9541225aadcdcee644669b9e1 ] >> >> 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"). > We don't seem to have commit 3282... in 4.19, so we don't need this > one in 4.19-stable according to the changelog. Technically 3282... exposed the issue by making it more likely to happen so 4.19 might just have a really low probability of seeing the issue (I think I did try reproducing it on kernels of that vintage). Personally I'm not too fussed the kernel versions I care about have the fix. Maybe someone from NXP cares enough to pursue it.
Hi! > >> [ Upstream commit b867eef4cf548cd9541225aadcdcee644669b9e1 ] > >> > >> 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"). > > We don't seem to have commit 3282... in 4.19, so we don't need this > > one in 4.19-stable according to the changelog. > Technically 3282... exposed the issue by making it more likely to happen > so 4.19 might just have a really low probability of seeing the issue (I > think I did try reproducing it on kernels of that vintage). Personally > I'm not too fussed the kernel versions I care about have the fix. Maybe > someone from NXP cares enough to pursue it. Okay, I guess low-probability bugs are still fair game for -stable. The commit was not dropped from 4.19, so nothing needs to be done here. Sorry for the noise, Pavel
diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c index 1e8ff6256079f..b8dd75b8518b5 100644 --- a/drivers/spi/spi-fsl-espi.c +++ b/drivers/spi/spi-fsl-espi.c @@ -559,13 +559,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; }